Re: xz backdoor
On Di, 02.04.24 19:44, Petr Menšík (pemen...@redhat.com) wrote: > Function pid_notify_with_fds_internal from > ./src/libsystemd/sd-daemon/sd-daemon.c certainly is not just few lines, as > suggested. Should I ask why, if not necessary? The version in sd-daemon.c is a bit more complex because it supports a few things typically not necessary: - In systemd we support sd_notify() also via AF_VSOCK. i.e. PID 1 will send sd_notify() messages itself to a supervisor VMM or similar, to inform it when the system is booted up. It uses the very same protocol as we usually use via AF_UNIX, but over AF_VSOCK. Support for AF_VSOCK should be completely unnecessary for anyone but systemd (i.e. PID1) itself, hence we didn't add it to the copy/paste version version. The AF_VSOCK thing is awesome btw, because it allows you to properly schedule activation of a bunch of VMs in order, with correct waiting until they are ready to respond. - The code allows overriding the sender struct ucred (i.e. the SCM_CREDS control message te service manager will see). This exists to implement the "systemd-notify" tool, which is always going to the be a child process of the shell script it is invoked off, and which wants to patch the sender PID hence to its own PPID. Nothing should need that except of that tool. - The code allows sending along fds to the service manager, to make use of the "fdstore" concept in systemd (i.e. the service manager can keep copies of a service's active fds in escrow, so that the service can implement seamless restrats without losing any resources). So yes, most folks won#t need any of these three things, hence the copy version of the code doesn't mention it. > I think they preferred having fast fix over having long-term sustainable > solution. I haven't seen offer to provide libsystemd-notify library with > minimal dependencies, which they kindly refused. They preferred bundled code > over systemd bloat in comment #13. I haven't seen bloat-less library > considered in the bug, but might have missed it? uff, "bloat", "bloat", "bloat". I mean, libsystemd in git main doesn't pull in the compression libs anymore, it doesnt pull in gcrypt either. It pulls in libc and libcap only. Do you have a problem with these libraries? Or are you concerned about the extra space in memory? Well, libsystemd is going to be in memory anyway, you might as well use it. After all, if Linux is smart enough to load it into memory only once, and just give each consumer their own immutable memory map. Or in other words, having yet another shared lib in the mix just makes things worse: more of the same code, not less... The way I see it, there are two options from my systemd perspective: 1. Use libsystemd.so, it doesn't pull in any other deps anymore (except for libc and libcap), and is installed everywhere anyway. Use this when: - Your project is in C - You don't care about an extra dep - You use the other stuff libsystemd offers anyway (i.e. sd-bus, sd-event or so) 1. Roll your own sd_notify(). [In case you hack is a C project: you can start with the copylib the man pages now include (i.e. https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes) and adjust it to your framework of choice, coding style and so on. i.e. adjust the error handling, logging to your choice.] Use this when: - Your project is not in C or - You really don't want an extra dep Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote: > I am not convinced dlopen will it make secure in the end. I am not sure this > is a good solution. dlopen makes those dependencies non-obvious from > packaging side and non-visible from ldd or similar checking programs. > > I think it should be considered to offer more than one dynamic > library. It was considered. To the point that a decade ago, libsystemd originally was split up. But it was awful to maintain. But let's not repeat this discussion here. Read up here: https://github.com/systemd/systemd/issues/32028 > For example most services I maintain links to libsystemd just > because it wants sd_notify calls in their services. Without any > proof I would expect quite many services would have similar > problem. Could be perhaps libsystemd broken into few more dynamic > linked libraries? I somehow doubt any kind of compression is needed > for sd_notify calls. > > Could be even smaller library libsystemd-notify linked from libsystemd, > which would allow end applications to explicitly declare they need more > limited set of functions? Why link? I'd really just suggest people to implement the trivial client on their own. It's a trivial protocol for a reason: so that people can implement it natively in their language and framwork without bothering with our upstream libsystemd. use libsystemd if you link against it anways and hack in C, or if you really don't are about the extra dep for a single function, but otherwise, why would you use the lib? It *literally* is just sending a text string "READY=1" in an AF_UNIX datagram to a socket whose path is provided to you in the $NOTIFY_SOCKET env var. Anyone with a moderate understanding of UNIX APIs should be able to hack that up in a a few lines of code. It's a protocol I can summarize and explain in *one* frickin' sentence. sshd upstream understood this btw: https://bugzilla.mindrot.org/show_bug.cgi?id=2641 Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sa, 30.03.24 13:18, Gordon Messmer (gordon.mess...@gmail.com) wrote: > On 2024-03-30 02:37, Richard W.M. Jones wrote: > > (3) We should have a "security path", like "critical path". > > > > sshd is linked to a lot of libraries: > > > I really don't want to start a systemd thread, but... the xz, lz4, and zstd > libraries are pulled in by libsystemd, merely so that sshd can call > "sd_notify" > (https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch), > which raises a couple of questions. > > The first one that comes to mind is: Is the increased attack surface > incurred by linking to these additional libraries worth the value provided > by calling "sd_notify", or should that patch be dropped to improve sshd > security? As discussed elsewhere: these deps are now dlopen() in systemd git main. So they are basically gone, unless you actually use one of the API calls that need the code. > The second is: Is libsystemd too large? I could very easily be misreading > it, but it looks like at least some of src/libsystemd/sd-journal is used by > journald, including the compression bits. Do those really belong in > libsystemd? There are various programs that use sd-journal to read journal files. It's after all *the* place to you get your logs from these days. And journal files can be compressed. We only use one compressor when writing, but we have changed the compression library (i.e. nowadays use zstd), and need to provide read compatibility. Hence the other compression libs. > If they need to be shared components, could the journald > components be split out to reduce the size of libsystemd? (That is, to > avoid linking to the compression libs?) This creates many other problems. For an explanation see the various comments here: https://github.com/systemd/systemd/issues/32028 Also, I don't think we should get hung up too much on the libsystemd thing. I know people like to hit on systemd, but the attacker could have used various other vehicle libs for their goal, too. I mean, sshd uses PAM, and that pull in variety of things through its modules, and that's just very hard to properly review even when one just focusses on the default PAM config on Fedora. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sa, 30.03.24 18:56, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > > In systemd git main, libsystemd is only linked to libc, libcap, > > and libgcrypt + libgpg-error. A pull request to convert that that last > > pair to dlopen is under review. > > That helps somewhat (it would have prevented this backdoor from working), > but it also makes things even less transparent: How do we know whether some > random sd_foobarify() function or some random foobard linked against > libsystemd will (always or ever (and when?)) end up dlopening liblzma or > not? > > Distribution packagers tend to dislike dlopen due to the hidden dependencies > it introduces. Well, this is certainly a valid point, but the solution is not to make all deps hard ones. Instead, in order to just make these deps visible I see multiple better alternatives: 1. teach Linux/ELF something inspired by MacOS's weak deps. i.e. allow ELF programs declare that some symbols shall be backed by some lib, but make it a weak dep that is only resolved on demand, and gracefully is set to NULL if the library cannot be found. If we had that, we'd stop using dlopen() for systemd's deps, since all we do is basically reimplement this concept manually. 2. without Linux/ELF supporting the above we could still teach systemd and other tools in similar situations to declare the dlopen deps they have in some ELF note or section, so that it can be processed by initrd generators, automatic dep generators in dpkg/rpm, ldd-like tools and everything else that wants this info. This would require some C macro magic, but could be added in probably just a few lines of codes added to relevant projects. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mounting USB Storage devices with "sync" option ?
On Fr, 02.02.24 10:10, Roberto Ragusa (m...@robertoragusa.it) wrote: > On 1/31/24 09:41, Lennart Poettering wrote: > > > This tanks performance when writing to the device though. There's a > > much better approach however: use an automount in between with a very > > short timeout (2s or so). This means the mount appears continously > > available from application PoV but the backing fs is only mounted for > > a brief time around accesses. This allows caching and asynchronous > > behaviour to work, but after 2s everything is forced out to disk > > anyway and it is guaranteed the superblock of the disk is put back > > into a clean state. > > > > systemd supports this natively, for example with a simple > > "systemd-mount -A /dev/sda1". > > > > Another possible approach: run "sync -f" every 3 seconds. While that should make sure the unwritten data hits the disk it doesn't put the superblock in order to mark it as "this fs has been cleanly unmounted". That's quite limiting. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mounting USB Storage devices with "sync" option ?
On Mi, 31.01.24 06:43, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > I created a simple PoC udev rule to mount USB Storage devices with the "sync > option. > Available here : > https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage.rules > > Currently, USB Storage devices are mounted without the "sync" > option, causing their writes to be cached. This causes an issue, > especially with GUI file managers like GNOME Files, where after a > file copy operation, it would notify the user that the operation has > been completed. If the user then tries to unmount the USB Storage > device, they get notified that data is still being written to disk > and that they should not remove the USB Storage device from their > PC/Laptop/device. > > This can take a more severe form if the user is using a CLI/GUI > utility that DOES NOT inform the user that data is still being > written, like the 'cp' CLI utility, the user might be misled into > thinking that all writes have finished and plug the USB drive out, > at which point data corruption due to unfinished writes occur. > > This is why, I think functionality should be included in Fedora > Linux (or atleast in Fedora Workstation and other desktop spins) > such that USB Storage devices are mounted with the "sync" options by > default. This tanks performance when writing to the device though. There's a much better approach however: use an automount in between with a very short timeout (2s or so). This means the mount appears continously available from application PoV but the backing fs is only mounted for a brief time around accesses. This allows caching and asynchronous behaviour to work, but after 2s everything is forced out to disk anyway and it is guaranteed the superblock of the disk is put back into a clean state. systemd supports this natively, for example with a simple "systemd-mount -A /dev/sda1". I wished the desktop UIs would use this, or that udisks would learn such a mode too, and in fact default to it. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: goal: booting with an empty /etc
On Mo, 11.12.23 11:10, DJ Delorie (d...@redhat.com) wrote: > Lennart Poettering writes: > > Well, as you might be aware many distributions these days do more than > > "files dns" for "hosts", and similar for the other databases, and > > hence a built-in default in glibc is great, but most distributions and > > image builders probably want to pick different defaults without having > > to patch glibc for this. > > I agree. My point was that (1) glibc has a built-in default, and (2) > most distros/users/installers customize it anyway, so storing a > "default" version anywhere other than /etc is not needed. This doesn't work though. Take Fedora for example. It supports a systemd feature called "DynamicUser=". If you turn that on for some service it will get a transient UID assigned the moment it is started and it's released again when it is stopped. It's a resonably popular feature. It requires that the "nss-systemd" modules is listed in nsswitch.conf. The glibc built-in default does not list "systemd" in its nsswitch.conf line though. On Fedora, the module is patched in via /etc/nsswitch.conf. But then you already lost, because now the distro default and the configuration the user made are all mixed up in a hairy ball and cannot be separated anymore. I don't think it's realistic to ask the glibc maintainers to change their built-in version of nsswitch.conf to always list systemd though (as that doesn't even make sense in many cases, i.e. when you run glibc inside a docker container without any systemd). Hence it makes sense to isolate this cleanly: 0. have upstream defaults built-in to the binaries, where this applies 1. have distro/OS image defaults in /usr/ 2. have user's own configuration in /etc/ That's a very clear separation of ownership, and means you can always very clearly trace back where a change comes from, and combine things flexibly in a multitude of ways without ever losing this concept of provenance. In systemd we have a tool "systemd-delta" which makes use of this separation of ownership, and allows you to diff local settings vs. distro/OS defaults. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: goal: booting with an empty /etc
On Fr, 08.12.23 20:20, DJ Delorie (d...@redhat.com) wrote: > Lennart Poettering writes: > > That said, I would certainly enjoy more if glibc would natively > > fallback to /usr/lib/glibc/nsswitch.conf or something like that if > > /etc/nsswitch.conf does not exist. > > glibc has an internal default for nsswitch.conf if one isn't found. > Putting a custom nsswitch.conf in yet another non-standard directory is > not needed. Well, as you might be aware many distributions these days do more than "files dns" for "hosts", and similar for the other databases, and hence a built-in default in glibc is great, but most distributions and image builders probably want to pick different defaults without having to patch glibc for this. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: goal: booting with an empty /etc
On Fr, 08.12.23 10:25, Stephen Gallagher (sgall...@redhat.com) wrote: > That being said, there are files like /etc/nsswitch.conf, > /etc/pam.d/* So for /etc/nsswitch.conf (and some degree of /etc/pam.d/) a short-term half-way fix is this I guess: https://github.com/authselect/authselect/issues/355 (hopefully @pbrezina merges my two PRs soon). With that if you boot up with an empty /etc/, you'll get a proper /etc/nsswitch.conf set up automatically, like you would on a regular Fedora install. That said, I would certainly enjoy more if glibc would natively fallback to /usr/lib/glibc/nsswitch.conf or something like that if /etc/nsswitch.conf does not exist. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: goal: booting with an empty /etc
On Fr, 08.12.23 17:23, Florian Weimer (fwei...@redhat.com) wrote: > * Stephen Gallagher: > > > That being said, there are files like /etc/nsswitch.conf, /etc/pam.d/* > > and /etc/fstab which are both API *and* sometimes see manual updates. > > These are some of the cases that are going to make getting to an empty > > /etc very hard to finish off. There's a lot of low-hanging fruit we > > can take care of in the meantime, but getting the last 1% of packages > > done is going to take a lot of inter-distro conversations. > > We could add some sort of :include: processing to glibc, but that's > going to impact much more than just glibc in the end (Go has its own > parser for /etc/passwd, I believe others have their own for > /etc/nsswitch.conf). I'd always suggest going for .d/ style drop-in dirs (i.e. /etc/services.d/*.conf, /usr/share/services.d/*.conf, /etc/protocols.d/*.conf, /usr/share/protocols.d/*.conf and similar) rather than include logic, for the simple reason that ensuring includes don't result in potentially endless recursion is a bit nasty. Moreover, it's kinda nice if the conceptual logic that allows users to split things up doesn't leak into the contents of the files, but remains in the structure of the file system. That said, if you give me an "include" style logic in glibc's database handling I'd also be happy. Beggars can't be choosers, after all. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dropping of sshd.socket unit
On Mo, 21.08.23 11:07, Lennart Poettering (mzerq...@0pointer.de) wrote: > On Do, 17.08.23 08:25, Chris Adams (li...@cmadams.net) wrote: > > > Once upon a time, Lennart Poettering said: > > > Yes, and if this is not what you want, then disable the > > > ratelimit. That's what I am saying? > > > > It would be useful for systemd to have "cooldown periods" for things, > > similar to inetd and classic init, where misbehaving things (whether > > services or sockets) were paused for a time (configurable even) and then > > returned to service. AFAIK this is a flaw in general in systemd's > > limits; if something exceeds them, it takes manual intervention to reset > > them. > > There's a TODO list item for that upstream already. > > https://github.com/systemd/systemd/blob/main/TODO#L153 > > Definitely makes sense, and should be very easy to add, the underlying > concepts are all implemented, it's just a matter of exposing this > under new options. I started working on this now: https://github.com/systemd/systemd/pull/29159 Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dropping of sshd.socket unit
On Do, 17.08.23 08:25, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Lennart Poettering said: > > Yes, and if this is not what you want, then disable the > > ratelimit. That's what I am saying? > > It would be useful for systemd to have "cooldown periods" for things, > similar to inetd and classic init, where misbehaving things (whether > services or sockets) were paused for a time (configurable even) and then > returned to service. AFAIK this is a flaw in general in systemd's > limits; if something exceeds them, it takes manual intervention to reset > them. There's a TODO list item for that upstream already. https://github.com/systemd/systemd/blob/main/TODO#L153 Definitely makes sense, and should be very easy to add, the underlying concepts are all implemented, it's just a matter of exposing this under new options. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dropping of sshd.socket unit
On Di, 15.08.23 18:17, Dmitry Belyavskiy (dbely...@redhat.com) wrote:
> Dear Lennart,
>
> I'm sorry, I don't get.
>
> Quoting the
> https://www.freedesktop.org/software/systemd/man/systemd.socket.html#TriggerLimitIntervalSec=
>
> Configures a limit on how often this socket unit may be activated
> within a specific time interval. The TriggerLimitIntervalSec= may be
> used to configure the length of the time interval in the usual time
> units "us", "ms", "s", "min", "h", … and defaults to 2s (See
> systemd.time(7) for details on the various time units understood). The
> TriggerLimitBurst= setting takes a positive integer value and
> specifies the number of permitted activations per time interval, and
> defaults to 200 for Accept=yes sockets (thus by default permitting 200
> activations per 2s), and 20 otherwise (20 activations per 2s). Set
> either to 0 to disable any form of trigger rate limiting. If the limit
> is hit, the socket unit is placed into a failure mode, and will not be
> connectible anymore until restarted. Note that this limit is enforced
> before the service activation is enqueued.
>
> But this behavior (the last sentence) exactly matches the DoS
> described here: https://bugs.archlinux.org/task/62248
> Too many connections to an sshd server, configured using socket
> activation can cause the socket to be disabled permanently
> ("sshd.socket: Trigger limit hit, refusing further activation.").
Yes, and if this is not what you want, then disable the
ratelimit. That's what I am saying?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Sa, 22.07.23 07:01, Matthew Garrett (mj...@srcf.ucam.org) wrote:
> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
> filesystems are resilient against deliberately malformed filesystems so
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against
> adverse input in the real world and so are more likely to contain
> exploitable bugs
>
> There are various cases where people do need to make use of uncommon
> filesystems, but the majority of them aren't related to removable media.
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
>
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"
I am not convinced that the udev db is really a great place for such
configuration that is not really related to devices itself, but more
about local policy decisions.
What I think is important to keep in mind is that /bin/mount doesn't
check the udev db (and probably shouldn't) when determining the fstype
to mount when using "-t auto" (which is implied if -t is omitted). I
think it would make sense to devise a mechanism that automatic
mounting for removable disks is covered the same way as "mount -t
auto" by such an allowlist of fstypes.
My preferred mechanism to implement what you are asking for is what
I proposed here:
https://github.com/util-linux/util-linux/issues/1969
And as it turns out Karel actually implemented this recently, see
https://github.com/util-linux/util-linux/commit/1592425a0a1472db3168cd9247f001d7c5dd84b6.
I think it would be a good idea to build on that, i.e. make udisks
just set that mount option to a useful allowlist, and then be done
with it?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Dropping of sshd.socket unit
On Do, 03.08.23 11:29, Dmitry Belyavskiy (dbely...@redhat.com) wrote: > Dear colleagues, > > I've pushed a fresh build of OpenSSH to rawhide. > We decided to drop the sshd.socket unit from rawhide. We don't think > it's worth going through the changes process, but would like to > provide a heads-up. Hmm, why drop it? For many setups, it makes not sense to continously run sshd, so socket activation should be fine. I don't understand the reasoning behind this change. You claim a DoS. Which DoS is that supposed to be? That we enforce a trigger time limit on socket units by default? If you don't want this, turn it off, that's what TriggerLimitIntervalSec=/TriggerLimitBurst= is for, see docs. The discussion makes this sound as if there was a bug in systemd or so, but there really isn't, it's literally a safety feature you ran into. It might not make sense to have the trigger rate limit in place for all usecases, ssh might be one where it is not advisable, but then the right approach is to just turn that part off, as documented, via the aforementioned options. See for details: https://www.freedesktop.org/software/systemd/man/systemd.socket.html#TriggerLimitIntervalSec= I don't care too much whether you make ssh socket-activated by default or not. But at least the option should exist, already for compat with existing setups. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Towards enabling rpm sysusers integration
On Di, 27.06.23 12:04, Panu Matilainen (pmati...@redhat.com) wrote: > On 6/22/23 19:55, Steve Grubb wrote: > > > > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format > > > > I would caution against this whole proposal. Not that I'm against it, but > > just saying be careful doing it. People often forget about our security > > concerns. Currently, shadow-utils has about 400 places which generate audit > > events during the managing of system and user accounts. libuser (I saw the > > deprecation email) has 55 places where it sends audit events managing > > accounts. > > > > There is a 10 year old (or more) standard published here: > > https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Account-Lifecycle-Events > > > > If %pre getent, useradd, and groupadd are being replaced by something, that > > something needs to conform to the expected security safeguards that > > currently > > exist. It needs to match the kind of events and the format that currently > > exists. > > Looking at the systemd-sysusers source [1], it seems to do exactly zero > audit logging. So there's a bit of work to do on that front... last time I looked auditd is started later than systemd-sysusers. Hence not sure if sysusers would actually generate audit messages that auditd could pick them up. In general though: people who care about audit need to send us patches for this, if this matters to them. I don't think anyone in systemd upstream wil work on this on their own. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
On Do, 22.06.23 12:24, Jeremy Linton (jeremy.lin...@arm.com) wrote: > But, IMHO the largest change is moving the boot kernel/initrd to the ESP, > rather than the use of systemd-boot itself. Given the filesystem layout > remains the same outside of those two items and the BLS entries, all the > common tools (dracut/etc) seem to be able to deal with it, and random other > packages not manipulating kernel/initrd images are behavior should not be > affected anymore than putting reFind/whatever in the boot path. While putting kernle/initrd (UKIs) into the ESP is a good thing systemd-boot actually is fine with loading them from a separate boot partition to, i.e. the XBOOTLDR partition, which in many ways is similar to traditional /boot/, but must be marked via recognized XBOOTLDR partition type uuid. (also it must be a firmware recognizable fs, i.e. vfat) Such an XBOOTLDR partition is supposed to be the escape hatch if the ESP is pre-existing and too small to contain multiple full sized UKIs. But you could also make it an escape hatch for simplifying transitions from the status quo ante. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Towards enabling rpm sysusers integration
On Do, 22.06.23 10:25, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > I was hoping we would be make the dependency on setup optional.
> > It is a fairly heavyweight package (700+ kb) and with lots of
> > not-that-useful-on-a-typical-modern-installation stuff (mail alias support,
> > csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it
> > clutters /etc, which ideally would be empty, and also /etc/services is 700
> > kb.
>
> /etc/services and /etc/protocols are AFAIK mandatory if you want to have
> network services (either client or server). I don't think there's
> anything else providing that information.
getservbyname() always and getaddrinfo() under certain circumstances
(i.e. if 2nd argument actually uses a textual service name) use these
files.
But I think in the year 2023 programs actively using this should
probably be fixed not do so, and just use literal port numbers.
The service database in /etc/ is a really weird concept since it
suggests this mapping was configurable. But it really isn't, because
it's of course generally the *server* of an IP service that picks the
port number, not the *client*. Hence if a client configures the
mapping between service name and port at will this is generally
useless since it's unlikely going to match what servers bound its
sockets to.
hence, I think it would be wise to fix programs across the
distribution to just use port numbers literally, and avoid the service
database. it's probably what most admin folks assume anyway.
And for programs that cannot easily bit fixed to work like this, it
would make sense to provide a split out package
("socket-databases.rpm"?), and then require those consuming packages
to depend on that.
"tcpdump" can also uses these databases as well, but at least I
personally always found that very much confusing and hindering, since
the data in the database is sometimes a bit too historical to be
useful. For example it thinks port 5355 is "hostmon", even though it
almost certainly is llmnr if see in the wild... And what's even worse:
local client sockets on Linux get auto-assigned port numbers from the
range 32768-60999 by default (see
/proc/sys/net/ipv4/ip_local_port_range), but /etc/services assigns a
ton of names to various ports from that range. For all these cases the
service info is just complete garbage.
Side note: because the service db is such a broken concept the socket
activation feature in systemd explicitly never supported it btw. And
while people complain about various of our "political" choices like
that, noone so far has noticed or complained this omission... So I
have serious doubts anyone cares about the concept at all...
(If such a split off "socket-databases.rpm" would be created I'd like
to suggest moving the database to /usr/ somehwere at the same time,
and then create a symlink from /etc/services to it, including via
tmpfiles.d/, to at least push people away from assuming that this was
actually configurable config file, and not just a dump of some
outdated IANA data).
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Do, 11.05.23 03:59, Neal Gompa (ngomp...@gmail.com) wrote: > On Thu, May 11, 2023 at 3:33 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, May 10, 2023 at 05:54:45PM -0400, Chris Murphy wrote: > > > I don't know what question you asked them. Any modifications > > > (writes) performed outside kernel code is not supported, since > > > forever. > > > > > Read-only drivers, which are the only drivers under discussion here, > > > aren't a per se problem because they can't modify the file > > > system. So they have no complaints about that. > > > > Just read-only is not enough: a user must be able to configure things in > > the boot loader: the default boot entry, or screen resolution, etc. > > Also we want boot counting, which means writing the number of boot > > attempts somewhere. A solution which makes those things impossible > > is not very attractive. > > > > We already don't do boot counting from the bootloader side. That > happens in the operating system. If that was the case you could only count good boots, i.e. the ones where you actually boot far enough into the OS. But that's useless information. What you really care about for the purpose of automatic fallback on failure is to count *bad* boots, and that means you have to start counting *before* you hand off control to the OS, i.e. as early as you can and then see if for that count you actually manage to reach the OS. Hence, if you care about realibility, automatic fallback and such things, you need a writable boot partition. And that doesn't leave many options, but VFAT. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Mi, 10.05.23 17:54, Chris Murphy (li...@colorremedies.com) wrote: > > > On Wed, May 10, 2023, at 5:21 PM, Lennart Poettering wrote: > > So to add to this. I happen to be at LFSMMBPF at the moment, the Linux > > File System summit (among other things) where all the Linux FS people > > meet. I spoke to a couple of FS maintainers here, and well, let me > > make this very clear: using any of the major Linux file systems with > > drivers that are not the ones in the Linux kernel is a very bad idea, > > and expressly not supported by them. [They actually used much harsher > > words, that I'll not repeat here – this is the "friendly" version of > > their take on your idea.] > > > > So, unless you want to go against what the people who actually > > maintain the file systems expressly say please just get this idea out > > of your head that porting Linux file systems into EFI fs drivers was a > > good, supportable idea. > > > > And Neal, Chris, if you don't believe the above, then hey, I am happy > > to open a thread with them in CC where they can tell you in person how > > bad an idea that is. > > I don't know what question you asked them. Any modifications > (writes) performed outside kernel code is not supported, since > forever. No, reading isn't fine either. You might remember the issue with a sync()ed XFS not being properly readable by grub because linux xfs semantics meant that sync() returns after data hit the journal but grub never checked the journal? this mess even intermittendly landed on my doorstep because people wanted us to freeze/thaw the disk during shutdown to escape this mess... The Linux FS people simply dont want to be bound by fucked up semantics of alternative implementations that do not how to deal with the situation on disk the same way as Linux. Hence: get this idea out of your head please. btrfs, xfs, ext4 are not a sensible option to read from EFI or grub, it's not sustainable. (Moreover, read-only access doesn't cut it. If you want boot counting you want write access.) > Read-only drivers, which are the only drivers under discussion here, > aren't a per se problem because they can't modify the file > system. So they have no complaints about that. No. Not true. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Mi, 10.05.23 14:32, Neal Gompa (ngomp...@gmail.com) wrote: > On Wed, May 10, 2023 at 2:24 PM Owen Taylor wrote: > >> As soon as you throw UKIs in the mix, you've completely broken that > >> because now the absolutely most valuable code for your system is in a > >> "hostile" environment. At least we can make /boot authenticated and > >> tamper resistant as a Btrfs subvolume. > > > > > > As other people have mentioned, we have a solution for the ESP being > > untrusted - secure boot. As far as I understand, there's no tamper > > resistance for /boot on btrfs unless it's encrypted, and that would be a > > whole other barrel of snakes :-) > > fsverity is separate from fscrypt. We can apply filesystem > authentication today. No that's just wrong. fsverity is *not* filesystem authentication. It's authentication of the content of a single file, and not more. And that's just too little, because a complex file system such as btrfs is simply not considered robust against rogue offline modification. (Again, I am at LFSMMBPF and if you want I can get you a quote from the btrfs maintainer about this). Thus you must authenticate btrfs *before* you mount it, and fsverity is only available after. Sorry, fsverity has some usecases, but your usecase here is absolutely not it. Seriously, forget about this whole btrfs idea. It's wrong on many many levels. > No. It initializes the whole operating system, and then pivots the > user-space later. That's why we have to everything in initramfs. > UKIs attempt to standardize the early-stage image without attempting > to solve this problem, because a two-stage boot process requires > changing how we think about operating system initialization. So the initrd is supposed to contain exactly what is necssary to get access to the root fs, not more. Thing is that Linux is very very flexible, and people put their root fs on crazy stuff. Now I personally don't even care much about the crazy storage options people want to back the rootfs, I only care about the non-crazy part (in my eyes), i.e. encryption, fido2, tpm stuff, which possibly requires interactivity so it probably also means a graphical session to some point. While that generally ends up being a lot, it still is certainly not *everything*. You can stick your head in the sand and pretend that nothing of this mattered, and you don't have to authenticate and things, but then you simply didn't solve the problem at hand. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Mi, 10.05.23 12:00, Neal Gompa (ngomp...@gmail.com) wrote: > This proposal isn't better. Neither Windows nor macOS put critical > operating system code in the ESP, and we shouldn't either. This is nonsense. I am not sure what definition of "critical" you have, but the ESP is the entrypoint to the OS, of course it contains "critical" stuff in there, if you delete what windows places there you cannot boot anymore. > As soon as you throw UKIs in the mix, you've completely broken that > because now the absolutely most valuable code for your system is in a > "hostile" environment. At least we can make /boot authenticated and "most valueable code"? what is that even supposed to mean? > tamper resistant as a Btrfs subvolume. What is a tamper resistent btrfs subvolume? I have not heard of such a thing. And don't say "fsverity" now. Because that's really not it. "fsverity" is not some secret sauce that you attach to an fs and then it cannot be tempered with. It has a much more limited usecase and requires userspace to first validate the file's metadata and it's hash manually before using it. Seriously, fsverity is not an answer for this. And you know what, the person behind fsverity will tell you the same. (also here at lfsmmbpf, and I can connect you if you want) Moreover, you need to validate a complex file system before you access it, it's too late if you do it the other way round. Hence, unless you established trust in your btrfs fs *before* you go into and and look for kernel you are not doing security, you are just doing nonsense. > I would rather have a multi-stage boot process, where the first stage > does just enough to unlock and load the OS volume to load the real > boot environment. And I'd like a pony! Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Mi, 10.05.23 15:13, Lennart Poettering (mzerq...@0pointer.de) wrote: > > We're generally looking toward encrypting subvolumes individually > > using the upcoming Btrfs native encryption capability rather than > > using LUKS. That allows us to > > How do you establish trust in the underlying file system? The thing > that kernel fs maintainers made very clear is that they do not > consider Linux file systems safe regarding rogue offline > modification. Hence you must establish trust somehow *before* you > mount the fs, which pretty much means LUKS. > > Linux fs maintainers also made very clear that they generally consider > alternative implementations of their file systems as unsupported, and > a problem. The big relevant Linux file systems consider only the > implementation in the Linux kernel as defining the format. Which means > that anything like an alternative implementation of btrfs or xfs or > ext4 in things like grub or EFI is expressly against the wishes of the > people who maintain the file systems. > > Or in other words: what you are proposing appears like a very bad > idea, and in fact even upstream Grub wants to get away from > maintaining thei own fs drivers for Linux fs as I hear, because it's > so untenable to them, too. > > Seriously, bury this idea. So to add to this. I happen to be at LFSMMBPF at the moment, the Linux File System summit (among other things) where all the Linux FS people meet. I spoke to a couple of FS maintainers here, and well, let me make this very clear: using any of the major Linux file systems with drivers that are not the ones in the Linux kernel is a very bad idea, and expressly not supported by them. [They actually used much harsher words, that I'll not repeat here – this is the "friendly" version of their take on your idea.] So, unless you want to go against what the people who actually maintain the file systems expressly say please just get this idea out of your head that porting Linux file systems into EFI fs drivers was a good, supportable idea. And Neal, Chris, if you don't believe the above, then hey, I am happy to open a thread with them in CC where they can tell you in person how bad an idea that is. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Mi, 10.05.23 11:20, Simo Sorce (s...@redhat.com) wrote: > It sounds reasonable for sure. > The only concern is, given Microsoft creates at most 500MB ESP > partitions, are we sure all UEFI systems out there will not choke on a > 1GB one? Well, I don't really think we have a reason to believe that a 1G ESP was any more problematic than a 0.1G ESP. I am not aware of any reports, and given that FAT32 is mandated by UEFI since basically always, I think there's no immediate reason to believe we are in trouble. I think the only reasonable approach here is to pick a larger default in a development distro, and collect feedback. > Can't we reduce the number of kernels by having *only* one UKI and a > rescue one that can be used to restore the previous working UKI from > /root if the active one fails? I'd kill the rescue concept as a separate kernel. Pre-compiled UKIs provided by Fedora should be comprehensive and suitable enough to be rescue images, I don't see why we need a second version of that. The only difference between a rescue boot and a regular boot should be one of parameterization, not of picking different kernel. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Di, 09.05.23 15:22, Chris Murphy (li...@colorremedies.com) wrote: > > > On Tue, May 9, 2023, at 2:47 PM, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, May 09, 2023 at 01:31:01PM -0500, Chris Adams wrote: > >> Once upon a time, Chris Murphy said: > >> > What about the increasing growth in linux-firmware and in particular the > >> > NVIDIA firmware requirements? My reading suggests it's significant and > >> > the future growth also significant. > >> > >> Could we use a dumb framebuffer in initrd and get rid of all the GPU > >> firmware from the image? > > > > Maybe, probably, who knows… But it's not just the video. The pressure > > to add more stuff and more drivers will only grow: bluetooth for keyboards > > and FIDO2, sound support for voice assistance, network for remote > > attestation > > or clevis, etc. We can push this can down the road, but it seems we need > > to be ready to add move stuff before root is available anyway. > > I still think we need less kernel and initramfs in order to get more > by having `/` available faster. Fast enough that the user isn't > looking for or expecting interactivity in the few seconds it should > take to get to `/` being mounted. Aren't you the one who just proposed LinuxBoot, i.e. having one kernel with initrd that includes complex storage, crypto, drivers, auth and things chainload a second kernel with initrd that includes all that? If you want fast boots and minimal disk space usage, then maybe have tiny boot loader and a single UKI element after that and not play games of setting up complex storage to load a secondary kernel that then has to set up complex storage again. You are arguing here into two opposing directions. One one hand you want to chainload multiple kernels+initrd (claiming this was a good idea out of the problem of sizing ESP/XBOOTLDR sufficientlly), and then on the other hand you claim there's too much kernel+initrd in the boot process? What is it now? Pick one: more initrd or less initrd? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Di, 09.05.23 15:04, Chris Murphy (li...@colorremedies.com) wrote: > > This makese no sense. If you want /boot to just be a subvolume of the > > rootfs btrfs, then this would imply it's also covered by the same > > security choices, i.e. encryption. We want to bind that sooner or > > later to things like TPM2, FIDO2, PKCS11. And that's simply not > > feasible from a boot loader environment. > > Windows and macOS do this, so it is feasible, the question is what > are the consequences of this and are we willing to live with them? They focus on a much more limited set of functionality. Also, are you volunteering to implement and maintain a full LUKS2, TPM2, FIDO2 and PKCS11 stack in UEFI mode? Good luck, man! And it's not getting any simpler. Next thing coming up is probably PassKey support, which means networking support. That's going to be fun in UEFI to support! I mean, these things tend to grow and become more complicated over time, and if you avoid Linux userspace then you make your life impossibly hard. And I really don't see Chris Murphy stepping up and maintaining that mess. Or are you? As someone who actually occasionally writes UEFI code: ffs, give up on the idea to reimplement complex auth protocols in UEFI mode! You want to do *less* stuff in UEFI, not pile on and pile on. Grub's reputation suffered because they are basically reimplementing a crappy version of Linux in their boot loader. Get yourself out of that Grub mindset, man! This idea appears so "out there" to me, I am sorry, but I somehow can't believe you seriously are proposing this. > One obvious consequence, it further creates dependency on a single > bootloader, GRUB. Or we need an independent project that provides an > EFI program for unlocking LUKS volumes within the pre-boot > environment, thus making plaintext view available to any bootloader. Sorry, this is *such* *a* *bad* *idea*. > > Hence, the place the kernel is loaded from (regardless if you call > > it /efi or /boot or /boot/efi, and regardless what fs it is) must > > be accessible from the boot loader easily, without requiring > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. > > I understand that might be difficult and something we don't want to > do for resource reasons, but there isn't a technical impediment for > it. Well, that's true, you can hack anything up that a Turing machine can execute and also run it in UEFI mode, but I seriously hope that you are not actually suggesting this. > FAT isn't resizable. The growth requirement for /boot is greater for > some use cases more than others, so there is pressure building > because it will create waste for some use cases and > underprovisioning in other use cases. Those unverprovisioned being > told they can't upgrade but need to reprovision to solve this is > kindof annoying. If you don't want to resize VFAT and XBOOTLDR is not enough to address this problem we can relatively easily extend XBOOTLDR to allow more than one additional such partition we can search through. The code in the boot loader is relatively straightforward. The limiting factor is more figuring out where to mount those. But seriously, you are making up synthetic probems. If ESP is too small add a large XBOOTLDR and I am pretty sure we'll be fine for a long long time before this comes an issue again. So long in fact it might never become. > Right. Hence Linux Boot. Dump all the toy drivers in favor of real > ones. And a real user space. I mean you understand that this just adds another chain to the boot process? if you do what you are proposing then you need to build a kernel that supports all that, i.e. all the complex storage, graphics and so on that you want to boot from, and thus you'll also have alrge images, and then what did you gain? You ave to put that in the ESP too, and the size limits still apply. It's illusionary to believe that the size constraints for a kernel + drivers + complex storage stack + crypto stack + auth stack would not apply to kernel that just runs in uefi mode instead of native mode... Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Di, 09.05.23 12:37, Neal Gompa (ngomp...@gmail.com) wrote: > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering > wrote: > > > > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > I've been asked to consider converting /boot to a Btrfs subvolume so > > > that it no longer has a fixed space allocation to deal with the ever > > > increasing amount of firmware required for NVIDIA GPUs[1]. This is > > > currently incompatible with how systemd views the world, because the > > > "discoverable partition spec" is wired to partitions, and there is no > > > equivalent spec for subvolumes of a volume. And I imagine that > > > XBOOTLDR (whatever that is) also would have a problem with this. > > > > This makese no sense. If you want /boot to just be a subvolume of the > > rootfs btrfs, then this would imply it's also covered by the same > > security choices, i.e. encryption. We want to bind that sooner or > > later to things like TPM2, FIDO2, PKCS11. And that's simply not > > feasible from a boot loader environment. > > > > Hence, the place the kernel is loaded from (regardless if you call it > > /efi or /boot or /boot/efi, and regardless what fs it is) must be > > accessible from the boot loader easily, without requiring > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. > > > > Hence: btrfs subvols won't work for this > > If we're not using LUKS for encryption, then this is not a problem. So you basically want to rebuild Fedora so that FDE is not available? > We're generally looking toward encrypting subvolumes individually > using the upcoming Btrfs native encryption capability rather than > using LUKS. That allows us to How do you establish trust in the underlying file system? The thing that kernel fs maintainers made very clear is that they do not consider Linux file systems safe regarding rogue offline modification. Hence you must establish trust somehow *before* you mount the fs, which pretty much means LUKS. Linux fs maintainers also made very clear that they generally consider alternative implementations of their file systems as unsupported, and a problem. The big relevant Linux file systems consider only the implementation in the Linux kernel as defining the format. Which means that anything like an alternative implementation of btrfs or xfs or ext4 in things like grub or EFI is expressly against the wishes of the people who maintain the file systems. Or in other words: what you are proposing appears like a very bad idea, and in fact even upstream Grub wants to get away from maintaining thei own fs drivers for Linux fs as I hear, because it's so untenable to them, too. Seriously, bury this idea. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Di, 09.05.23 12:08, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > the ESP. It could be mounted on /boot or on /efi or maybe even /boot/efi (*). > The kernels would then go to /boot/EFI/Linux, /efi/EFI/Linux, or > /boot/efi/EFI/Linux, > respectively. (When you write /boot/efi, it's not clear what exactly you > mean. The duplication of "efi" and "EFI" on on case-insensitive system > is confusing.) > > (*) This is actually something that'd need to be figure out. > /boot/efi is the worst choice; either /boot or /efi would be OK, > but something needs to be chosen. I'd strongly advise not to nest them, because that makes mounting them via autofs (i.e. systemd .automount units) nasty. i.e. /boot/ and /efi/ are the way to go in my humble opinion. Given that ESP/XBOOTLDR are likely vfat it's kind crucial to reduce the time where the partitions are mounted to a minimum, and autofs makes that very simple and natural, as it means the file systems are only mounted for a very short period of time when actually accessed, and unmounted a seconds later. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Di, 09.05.23 09:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > == Summary == > > > > This change will increase the minimum size of the ESP to be 500MB, > > which is also the same value used by Microsoft for Windows 10 and > > newer. > > This is both too much and not enough. Essentially, this grows the ESP, > but also leaves the XBOOTLDR partition large. Overall, the users pays > twice, and on some systems 1.5GB is not insignificant. OTOH, 500 or > 512 MB seems not enough: three big UKIs and a rescue kernel and and > some Windows blobs and a firmware update would likely overflow. > > If we want to change the default here, let's do some proper cleanup: > 1. the split between ESP and XBOOTLDR is only useful in the case where >ESP already existed and was small. If the installer is *creating* >an ESP, it should just make it large enough. > 2. having a second partition with a second (different) file system >implementation just increases the footprint and attack surface for >no gain. If we create XBOOTLDR, make it like the ESP (i.e. VFAT >in almost all realistic scenarios). > 3. if there are bootloaders that don't read one or the other partition >as they should, fix them. > > Then we can make the ESP 1 GB *and* save space compared to current > defaults. > > (Point 2. is not really *necessary* for the size changes, but it'd be > nice to get rid of this anachronism if this area is being touched.) I guess this might not be surprising, but this proposal makes a ton of sense to me and has my full support, FWTW Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote: > I've been asked to consider converting /boot to a Btrfs subvolume so > that it no longer has a fixed space allocation to deal with the ever > increasing amount of firmware required for NVIDIA GPUs[1]. This is > currently incompatible with how systemd views the world, because the > "discoverable partition spec" is wired to partitions, and there is no > equivalent spec for subvolumes of a volume. And I imagine that > XBOOTLDR (whatever that is) also would have a problem with this. This makese no sense. If you want /boot to just be a subvolume of the rootfs btrfs, then this would imply it's also covered by the same security choices, i.e. encryption. We want to bind that sooner or later to things like TPM2, FIDO2, PKCS11. And that's simply not feasible from a boot loader environment. Hence, the place the kernel is loaded from (regardless if you call it /efi or /boot or /boot/efi, and regardless what fs it is) must be accessible from the boot loader easily, without requiring implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. Hence: btrfs subvols won't work for this A simple vfat partition however will. > Also, as an aside, there is now a "from-scratch" Btrfs EFI driver in > development[2] (and for your personal horror, an NTFS one too[3]). Not sufficient. You'd also have to implement a LUKS EFI driver, and a TPM2 EFI driver, and a FIDO2 EFI driver, and so on and so on. Basically, you have to reimplement a good chunk of the Linux kernel, of Linux userspace, systemd and so on in EFI mode. Good luck with that. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Fr, 20.01.23 14:04, Colin Walters (walt...@verbum.org) wrote: > > > On Thu, Jan 19, 2023, at 11:53 AM, Gordon Messmer wrote: > > On 2023-01-19 00:55, Lennart Poettering wrote: > >> > >> What you could do is split up the problem: have iscsi-starter.service > >> or so, that is separate from the iscsi.service main service. The > >> former's job would be to scan if iscsi volumes are configured. If it > >> finds configured ones, it would then issue "systemctl start --no-block > >> iscsi.service" to enqueue a start job for the real thing. > > > > > > Something like that was suggested last year, and Colin Walters objected, > > for what that's worth. > > > > If the PR to allow installing only the "core" storage drivers is > > rejected, then I'll work on a PR to implement this change instead. > > Heh well, I'm obviously going to defer to Lennart if he has an > opinion on how you should do something with systemd. Just to say this clearly: I am actually with Colin on this too: needlessly adding in dynamic transactions during boot is not a great approach generally, since it reduces what we can parallelize, and makes behaviour less predictable and efficeint. Thus, people should not use what I proposed as a model for anything. It's a passable solution to an immediate problem, not more. So, what should the actual model to follow be in my opinion? Well, iscsid should just arrive in 2023 and watch rtnetlink on its own, and not rely on any "wait-online" services to delay boot processes. It should start early, not delay anything and make iscsi block devices pop up locally the instant connectivity allows it. And it should watch connectivity on its own, and retry contacting its severs whenever a new local network interface pops up and gets configured. And vice versa: if connectivity is lost (and policy dictates) remove block devices again. Or in other words, its 2022, and hotplug hardware is a thing, since 25 years now. iscsi devices should really feel like any other hotplugged hw, and be robust to network configuration changes. In such a model, iscsid would be a daemon you could start at any time in the boot process, and it would just work and make the devices it is configured for popup the moment that's possible, without any external scheduling and very very robustly. I am aware though that storage folks are not typically on the forefront of how device management is supposed to work these days (we still have some storage stuff pulling in systemd-udev-settle.service, don't we?), so I have no illusion that iscsi maintainers would even accept existance of rtnetlink as a thing. Maybe 25y from now, we'll see movement on that. > It wouldn't even be the first thing calling `systemctl start` in the > boot process...sadly there's NetworkManager dispatcher scripts that > *also* `try-restart iscsid` =/ That's much worse actually, and just another artifact of the fact that iscsid is too dumb to just watch the network state on its own, the one major thing it really depends on. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Do, 19.01.23 08:53, Gordon Messmer (gordon.mess...@gmail.com) wrote: > On 2023-01-19 00:55, Lennart Poettering wrote: > > > > What you could do is split up the problem: have iscsi-starter.service > > or so, that is separate from the iscsi.service main service. The > > former's job would be to scan if iscsi volumes are configured. If it > > finds configured ones, it would then issue "systemctl start --no-block > > iscsi.service" to enqueue a start job for the real thing. > > Something like that was suggested last year, and Colin Walters objected, for > what that's worth. have a link? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Mi, 18.01.23 10:19, Gordon Messmer (gordon.mess...@gmail.com) wrote: > There was also discussion of disabling the service by default and using a > generator to enable the service, and Lennart thought this was the best > solution. I started work to add a simple generator, but the documentation > for systemd.generator states "Non-essential file systems like /var/ and > /home/ are mounted after generators have run," and the purpose of the > generator would be to enable the service when there are files in > /var/lib/iscsi/nodes. So yeah, this is a mess, indeed. We have been thinking in systemd if we shouldn't tighten the requirements a bit and dictate that in future /var/ has to be mounted at the moment of the initrd → host transition. That would make the problem go away. We currently require that the root fs and /usr/ are already mounted during the transition. It's not *that* much more to require /var/, too. But I guess that is more a long term thing. What you could do is split up the problem: have iscsi-starter.service or so, that is separate from the iscsi.service main service. The former's job would be to scan if iscsi volumes are configured. If it finds configured ones, it would then issue "systemctl start --no-block iscsi.service" to enqueue a start job for the real thing. Then, the starter unit would not be ordered after the wait-online service, but the real iscsi one would be. Finally, iscsi.service's [Install] section would not carry any WantedBy= lines or so, i.e. would not hook itself into anything if enabled. Instead it would only carry Also=iscsi-starter.service there, which would basically "redirect" enablement to the starter service. And the starter service would then do WantedBy=sysinit.target to hook itself into the early boot. Both services would use DefaultDependencies=no, and the starter service would use RequiresMountsFor=/var/lib/iscsi/nodes so that it waits exactly until its /var/ dir is up, but not more. The starter service could probably look roughly like this btw: [Unit] DefaultDependencies=no Before=sysinit.target iscsi.service RequiresMountsFor=/var/lib/iscsi/nodes ConditionDirectoryNotEmpty=/var/lib/iscsi/nodes [Service] Type=oneshot RemainAfterExit=true ExecStart=/usr/bin/systemctl start --no-block --job-mode=fail iscsi.service Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Mi, 11.01.23 16:35, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > We have thousands of systemd services in Fedora. To "just add timeouts > to things that take too long" would mean updating them individually. > (Or maybe only some, but we don't really know which ones.) > This is never going to happen, it's just too much work, and there is > no clear clear understanding if it is "safe" for any specific service. > > Instead, the idea is to attack the problem from the other end: reduce > the timeout for everyone. Once this happens, we should start getting > feedback about what services where this doesn't work. Some services > legitimately need a long timeout (databases, etc), and for those the > maintainers would usually have a good idea and can extend the timeout > easily. Some services are just buggy, and with the additional visibility > and tracebacks, it should be much easier to diagnose why they are slow. > > Approaching the problem from this side is much more feasible. We'll > probably have to touch a dozen files instead of thousands. Just to say this cleary btw: when we introduced the time-out initially we were coming from sysvinit where no such time-out existed at all. Hence we picked a conservative (i.e. overly long) value to not upset things too badly. And yes, some people were very much upset we now defaulted to a time-out. If we'd start from scratch without sysvinit heritage, I think we would have started with something much much lower right-away. It appears to me fedora is considering switch to that now, and I certainly think that would make a lot of sense. Anyway, if fedora now wants to lower the default setup, then I certainly sympathize. I think a policy of "aggressive time-out by default, individual opt-outs per-service" is a better policy for a stable OS than the current "conservative time-out by default, individual opt-in per-service for something more aggressive". So yes, lowering the time-outs by default would make sense to me, but of course, people will be upset... Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: static USERMODEHELPER_PATH
On Mo, 09.01.23 15:18, Simo Sorce (s...@redhat.com) wrote: > If I remember correctly the claim was that umh is robust if the user > space fails and just terminates. As then the kernel know user space is > gone, whether it got the data it needed or not and can stop waiting. > > While messages may never get replied to and require handling timeouts > and then handling the case a user space process was slow and ignoring > late replies. > > Not sure this is really a good point given waiting indefinitely for a > user space program that hangs for some reason seems worse to me. > > When I had to code a call from knfsd to user space for GSS-Proxy I used > unix sockets. I think that is better than netlink in some cases as > sockets are simpler to handle from user space programs and are also > easily namespaced... Well, the requests would come from the kernel, and the kernel typically speaks netlink, not AF_UNIX. But quite frankly, I really don't care what transport would be used. I'd just be happy if we could get rid of the kernel forking its own stuff. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Fr, 06.01.23 11:06, Michael Catanzaro (mcatanz...@redhat.com) wrote: > Maybe instead of SIGKILL, we should send SIGQUIT instead. That way abrt > should complain next time you boot and users will have an opportunity to > report bugs to the package maintainer, instead of the problem being forever > ignored. Killing things silently makes it real hard to report bugs. And as a > bonus, the core dump should actually show what the process was doing at the > time it got killed. The more I think about it, the better this sounds. > Currently this can be configured using FinalKillSignal=SIGQUIT, so we'd just > need to figure out the right place to put that. > > systemd already has a configuration option for this so we'd just have to > turn it on. Don't use FinalKillSignal=SIGQUIT. Use TimeoutStopFailureMode=abort instead. (which covers more ground, and sends SIGABRT rather than SIGQUIT on failure, which has the same effect: coredumping). That said: dumping core is potentially extremely expensive (web browsers have gigabytes of virtual memory that we might end up processing and compressing). Quite often the stuff that is slow when exiting is also the stuff that is expensive to dump. Hence, I am not sure you'll gain that much via this mechanism: you cut a long operation short and then execute long operation as result. You might end delaying things more than you hope shortening them. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: static USERMODEHELPER_PATH
On Fr, 06.01.23 10:10, Steve Grubb (sgr...@redhat.com) wrote: > Hello, > > On Friday, January 6, 2023 9:33:12 AM EST Lennart Poettering wrote: > > On Do, 05.01.23 20:17, Steve Grubb (sgr...@redhat.com) wrote: > > > I work on RHEL security problems. I have been looking into a number of > > > exploits and I think we have a problem that has an easy fix. We are not > > > using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There > > > are a number of exploits that overwrite the path to modprobe and then > > > pass something weird that causes modprobe to be invoked. But instead of > > > modprobe, it's their reverse shell. > > > > umh is such a problematic interface. The processes forked off that way > > live in a weird netherworld besides the init system, in the root > > cgroup (and that even though inner cgroups in cgroupsv2 are not > > supposed to have processes in them) without any of the resource or > > security restrictions we otherwise make on all of userspace. > > One approach to solving this is to use selinux policy. selinux cannot apply resource controls, not can it arrange processes properly in the cgroup tree, nor can it apply seccomp filters, namespacing and so on. selinux can do some things, sure, but an init system is not a MAC, it does a lot more (and also a lot less). > Yeah, that's another approach that may have merit. But with the asynchronous > nature of that approach, I don't know how the kernel would know it can now > make calls into the module it needed to have loaded. Well, umh is async too in a way, kernel must wait for the userspace process to finish. There's not much of a difference to say "fork off + wait for process exit" and "send netlink message to userspace + wait for reply". Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: static USERMODEHELPER_PATH
On Do, 05.01.23 20:17, Steve Grubb (sgr...@redhat.com) wrote: > Hello, > > I work on RHEL security problems. I have been looking into a number of > exploits and I think we have a problem that has an easy fix. We are not using > the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There are a number > of exploits that overwrite the path to modprobe and then pass something weird > that causes modprobe to be invoked. But instead of modprobe, it's their > reverse shell. umh is such a problematic interface. The processes forked off that way live in a weird netherworld besides the init system, in the root cgroup (and that even though inner cgroups in cgroupsv2 are not supposed to have processes in them) without any of the resource or security restrictions we otherwise make on all of userspace. It's stuff that runs in userspace but is entirely unmanaged by userspace security and resource wise. (And it's also frickin slow) I wished we could get rid of umh entirely. For example, by having some maybe netlink based protocol or so that userspace could use to subscribe to umh events somehow and then gets the chance to fork off the processes itself. The init system could then hook into that and dispatch things in proper services with sandboxing, resource controls and everything applied, in a sensible cgroup. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Do, 22.12.22 11:00, Neal Gompa (ngomp...@gmail.com) wrote: > > OK, so what's left is exactly one issue you had: you tried to enroll 3 > > UEFI certs via mokutil and what exactly happened then? machine > > bricked how precisely? > > The UEFI environment failed to import without reporting failure and > the system failed to boot, showing garbage instead. By "uefi environment" you mean shim? Sounds like something to report to the shim project then. > > link for a bug report? > > Sorry, I can't. That makes it very hard to do anything about this. To fix a situation one needs actionable reports. > No one helped anyway, even back when I could provide more information. > They're even less likely now that I can't provide that information. You do realise that you are are complaining but not giving anyone the chance to do anything about your complaints. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Fr, 23.12.22 08:51, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > On 22/12/2022 21:29, Chris Murphy wrote: > > This is a rare but real problem. > > I don't think so. Power outage is a very common problem in some countries. > > I still remember how unreliable FAT32 was in the Windows 9x era. You needed > to run a scandisk check after every power failure or pressing the reset > button. And sometimes your documents or other files disappeared. I really > don't want a repeat of this. Nobody is proposing to run the full Linux OS from FAT. I mean, yeah, in /var and /home people usually do complex write patterns, and the files there basically are pinned all the time thus cannot be unmounted during runtime to ensure the file system stays clean most of the time. But this is different for XBOOTLDR: the autofs logic in systemd ensures it remains unmounted almost all of the time, and is only very briefly mounted whenever something actually accesses it. And the write patterns on XBOOTLDR are comparatively simple: drop in whole file, erase whole file, plus single-sector writes for some corner cases. This is *massively* different from the write patterns Windows 9x did on its file systems. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Fr, 23.12.22 09:01, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > On 22/12/2022 21:18, Chris Murphy wrote: > > XBOOTLDR in practice needs to be FAT. I don't like it. But I like > > it better than choosing batshit as the alternative, and having a > > bunch of signed efifs drivers on the ESP per distro sounds like > > batshit to me. And not in the good way. > > I don't think so. XBOOTLDR on FAT32 should be rejected as a defective by > design due to a FAT32 unreliability. It's not the best file system if you intend to do random access writes all the time. But if you don't do that, restrict your write patterns to a certain reasonably safe subset, and ensure that you keep the file system unmounted most of the time then it should be OK. I mean, UEFI effectively mandates FAT for one partition (i.e. the ESP), you can't avoid it. And at the bare minimum the boot loader is stored in the ESP, and you need to update that as regularly as any other software package, hence it's illusionary that you could avoid regular write patterns onto FAT if you just make XBOOTLDR something non-FAT. > I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot mode > and vice versa. After enrolling the Ubuntu key via mokutil that should be fine. Sure, if you have the shim belonging to distro X then this means only kernels of distro X can be just booted, since only X' certificate will be built-in. But once you enroll other certs things should be fine. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Do, 22.12.22 10:52, Neal Gompa (ngomp...@gmail.com) wrote: 65;6800;1c > > BTW, you keep talking of "these" problems, and are extremely vague > > about those. I think I understood that you hit the NVRAM size limits > > before, by enrolling private certs? > > Yes. Specifically for dealing with the NVIDIA driver, backports of > Intel network card drivers, OpenZFS, ELRepo modules, etc. > > > What are those issues precisely? Did you file bugs? How many certs did > > you try to enroll? Or did you try to enroll hashes? Were was this > > dicussed? > > Anywhere between 1 to 3 UEFI certs, representing different vendors > (machine-local, ELRepo, and OpenZFS). OK, so what's left is exactly one issue you had: you tried to enroll 3 UEFI certs via mokutil and what exactly happened then? machine bricked how precisely? link for a bug report? Please be specific, otherwise noone will be able to help you! Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Do, 22.12.22 10:43, Neal Gompa (ngomp...@gmail.com) wrote: > On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering > wrote: > > > > On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > > I understand the big issue you have is that the certificate store for > > > > Linux (i.e. the mokutil db) is limited in size because EFI variable > > > > NVRAM is limited in size? If that's the big issue you are having then > > > > that's absolutely something the Linux community can fix, and can > > > > address. Specifically, shim could allow storing the cert store on > > > > disk, and authenticate it at boot via the TPM. Not trivial, but > > > > doable. And certainly not the firmware's fault... > > > > > > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if > > > > the way Linux/shim/mokutil implement the cert db is done the way it is > > > > currently done. > > > > > > Frankly, I'm aggravated by the increased reliance on UEFI features > > > without fixing Linux's problems with UEFI features. If we stopped > > > relying on UEFI for the cert store, a lot of my issues would go away, > > > because then we can design better workflows for managing > > > certificates. > > > > Well, the thing is: a chain of trust is a *chain*, hence you must > > ultimately hook validation to what the firmware provides you with as > > root. And that ultimately is the SecureBoot db on commodity hardware. > > > > If I buy a boring laptop at a store it will come with a UEFI cert > > store, and nothing else. Linux cannot really ignore that. If it did, > > then you'd not have a trusted boot chain, hence the whole excercsie > > would be pointless. > > > > Shim trusts MS and the main distro cert, grub is trusted from there, > then the OS trusts those and anything else the admin adds. That's how > It should work. Trust chains are sensible as long as they're > extensible. Hmm, that chain is partly backwards? it's the firmware that has to trust the msft cert which trusts shim, which trusts the distro cert, which trusts grub and the kernel. The thing that comes first at boot must trust the next, otherwise we'd have to boot into untrusted stuff first, which really misses the point? not grokking what you are trying tosay? > > > You *need* to think about these problems when designing this stuff. > > > You can't take a myopic x86-only view to this. I have not heard of > > > anything about UKI security for non-x86 because it seems to all be > > > tied up in UEFI stuff. > > > > I work for a company that is working on ARM UEFI systems booting UKIs > > in massive scale. > > One company is one company. It's not a variety of people and users. > Scale means nothing if it's not distributed. Well, you said you have not "heard" of anyone doing UKI security on non-x86. Now you have. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Do, 22.12.22 06:38, Neal Gompa (ngomp...@gmail.com) wrote: > I have to think about what happens when the cat is out of the bag. > What I want is not necessarily a solution to this now, but a > commitment that someone will actively work on fixing these problems > *before* proposing the next phase and have it ready *before* making > any future proposals on UKIs. If you can't do that, I can't in good > faith consider incrementally supporting UKIs, because there's > effectively no plan to make them work as a future default way of > shipping the Linux kernel. BTW, you keep talking of "these" problems, and are extremely vague about those. I think I understood that you hit the NVRAM size limits before, by enrolling private certs? What are those issues precisely? Did you file bugs? How many certs did you try to enroll? Or did you try to enroll hashes? Were was this dicussed? Without any of that the vagueness just constitutes FUD... Hence, please be more specific! Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote: > > I understand the big issue you have is that the certificate store for > > Linux (i.e. the mokutil db) is limited in size because EFI variable > > NVRAM is limited in size? If that's the big issue you are having then > > that's absolutely something the Linux community can fix, and can > > address. Specifically, shim could allow storing the cert store on > > disk, and authenticate it at boot via the TPM. Not trivial, but > > doable. And certainly not the firmware's fault... > > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if > > the way Linux/shim/mokutil implement the cert db is done the way it is > > currently done. > > Frankly, I'm aggravated by the increased reliance on UEFI features > without fixing Linux's problems with UEFI features. If we stopped > relying on UEFI for the cert store, a lot of my issues would go away, > because then we can design better workflows for managing > certificates. Well, the thing is: a chain of trust is a *chain*, hence you must ultimately hook validation to what the firmware provides you with as root. And that ultimately is the SecureBoot db on commodity hardware. If I buy a boring laptop at a store it will come with a UEFI cert store, and nothing else. Linux cannot really ignore that. If it did, then you'd not have a trusted boot chain, hence the whole excercsie would be pointless. > It makes automation possible, it makes management possible, and it > opens the doors to experiment with how to do layered images for boot > (e.g. UKIs + system extension images) without bricking people's > computers. As mentioned before: note that the Fedora signing keys are only built into shim and the kernel, not stored in NVRAM. But anyway, I think it would be great if shim could manage a cert store on disk, I already said that. But that's truly orthogonal to UKIs and sysext really. You keep trying to change topics away from UKI/sysext towards your general discontent with UEFI. > That also has the side effect of us having half a chance of being able > to port this security capability to non-UEFI platforms where we use > fake UEFI implementations to bootstrap our boot process, because the > amount of coverage required for fake UEFI implementations is > considerably lower now. > > More generally, relying on UEFI-specific security features when most > platforms are not being brought up with UEFI is foolish. ARM is almost > entirely non-UEFI (except the tiny proportion of servers that almost > no one has) and RISC-V is not a UEFI platform either. POWER uses > OpenFirmware instead of UEFI, and IBM Z does something else entirely > different. Well, "foolish", eyh? The thing is that chain of trust works quite differently on each such system (if it exists at all). UEFI is a standardizing and unifying force that simplifies things greatly, since while not universal it's still the most widely adopted mechanism (and one of the more advanced). Generally, I am very sure we should focus on making the more limited stuff work like the modern stuff, and not the other way round. For example, there has already been work on making UKIs boot on grub/MBR, as mentioned, which is exactly how I think it should be done: move the old/legacy/simple stuff work more like the new/modern/featureful/standardized stuff, rather than the other way round. > You *need* to think about these problems when designing this stuff. > You can't take a myopic x86-only view to this. I have not heard of > anything about UKI security for non-x86 because it seems to all be > tied up in UEFI stuff. I work for a company that is working on ARM UEFI systems booting UKIs in massive scale. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Do, 22.12.22 14:49, Daniel P. Berrangé (berra...@redhat.com) wrote: > When you say it dooesn't get the offsets right, can you elaborate ? dracut uses fixed offsets for the sections to be placed in memory in. The values are simply hardcoded, literally specified address offsets, that worked for the original authors. This typically works – as long as your sections are not much larger than they were for the people wo came up with these offsets initially. But as it turns out this doesn't work for some cases. In such cases the sections will be loaded into memory overlapped and bad things happen. ukify hence calculates the offsets manually (by adding up the section sizes so that this cannot happen. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote: > > SecureBoot may not be to your liking but is what is installed on 99% of > > modern hardware sold, so it is a good idea to first show you can > > support it. Then if you have interested you can propose "something > > better". > > We have supported Secure Boot for over a decade now. In that timeframe, > literally nobody did anything to make all the workflows you talk about > easier and friendlier. > > In fact, everyone I talk to seems to think it's basically impossible > because of how it works at the firmware level. > > It's telling that neither Windows nor macOS use Secure Boot like Linux > does. And they don't precisely for the reasons I outlined. Yes, Linux never solved the initrd hole so far, but that's not really the fault of SecureBoot, it's the fault of Linux if you so will. And this proposal is an attempt to finally do something about this, and get things in order to actually deliver what the other OSes all are delivering. I understand the big issue you have is that the certificate store for Linux (i.e. the mokutil db) is limited in size because EFI variable NVRAM is limited in size? If that's the big issue you are having then that's absolutely something the Linux community can fix, and can address. Specifically, shim could allow storing the cert store on disk, and authenticate it at boot via the TPM. Not trivial, but doable. And certainly not the firmware's fault... I mean, UEFI has its warts, but I don't see that it's UEFI's fault if the way Linux/shim/mokutil implement the cert db is done the way it is currently done. > > Finally, unless this proposal harms Fedora I do not see why oppose it. > > If, as you fear, it won't work ... then it won't and we'll try > > something else. However, having some knowledge of the (security side of > > the) matter I do not see why it wouldn't work, once all the pieces fall > > in place. > > This adds significant complexity to the Fedora kernel package and it > effectively increases what we need to test for virtualized Fedora Linux > environments. Nah. UKIs + sysext are ultimately something that is simpler and much better to test than the current mess. Yeah, for a while we'll have to add complexity because to mechanisms will have to be supported, but eventually things are going to be simple and easier to test. > I assert that the proposal has not yet met the bar to overcome those > issues. If the "those issues" is supposed to be that you hit the size of the mokutil cert store once, then I fail to see the relationship to UKI/sysext. After all, the fedora signing keys for sysexts would be built into the kernel and hence not be charged against NVRAM. And the fedora UKI is signed with the same key as our current kernels, which are also not charged against NVRAM but are built into fedora shim. And the shim signature key is the msft key. Yeah, if you want to build your own UKIs + sysext, then you have to use mokutil to enroll a cert, but it would be entirely sufficient to enroll one for that, and sign UKIS, kmods, sysext with them. (or, maybe you actually hit the NVRAM size limits because you enrolled hashes, not certs? if so, then maybe address that?) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Di, 20.12.22 21:32, Neal Gompa (ngomp...@gmail.com) wrote: > As someone whose day job involves working with teams who develop both > Windows and Linux drivers (and in the past, even macOS drivers!), I > can categorically say that Windows driver engineering processes are > way friendlier than Linux ones, precisely because Windows drivers are > deliberately not exposed to Secure Boot *at all*. Running development > versions of drivers just requires installing a development certificate > into the NT kernel certificate store. The equivalent process for Linux > is to load a custom secure boot certificate into firmware, which is > fraught with peril and potentially not even possible. This is a bit of a misrepresentation how this currently works. The Linux kernel populates its keyrings these days from both built-in keys and from those imported from uefi vars (both uefi db and mokutil stuff). So, yes, SecureBoot keys are imported into the kernel keyring, but they aren't the only thing. You can enroll your own via mokutil and the OS vendor can enroll by building them into the kernel. Neither of those two has much to do with firmware, i.e. there's no need to update the UEFI db, updating the mokutil efi vars is enough. > I cannot tell you how many times I've bricked a system by attempting > to load another cert only to find out there's not enough space and > the firmware didn't handle that well. Well, sure, space in the efi vars is limited. But christ, how many certs did you actually enroll via mokutil? (if you are working with local throw-away certs, then I guess it's just not build for that) I mean, sure, it would make sense of shim would be able to manage a keyring on a file in the ESP instead of purely via an efi var, but this massively raises the question of authenticating that. i.e. would require some TPM protection usually, but TPM from UEFI mode is not fun, since (except for PCR measurements) you have to roll the TPM communication yourself (or embedd a fill TPM stack, but thta's going to make shim even larger than it already is). I mean, file an RFE against shim. But this really has nothing to do with UKIs/sysext, we just use the same authentication mechanisms as before pretty much: UKIs are authenticated like any kernels, just as before, and sysext are authenticated via the same keyring as kmods basically. Hence there's nothing really new here when it comes to key management. If you have beef with how Linux manages the keys for authenticating kmods then bring that up with the kernel community, it has nothing to do with the way UKIs/sysext works. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Di, 20.12.22 11:28, Neal Gompa (ngomp...@gmail.com) wrote: > I think UKIs are fundamentally flawed and are an idea that came out of > a group that doesn't really interact with real users enough to > understand how much of a problem they actually are. I presume this is supposed to be a comment on systemd upstream, which includes me? Dunno, I think I have quite a good idea how people use systemd, and how general purpose distros like Fedora use it. Because I get the firehose of feedback on it. From *all* distros, and from all ways how peole use it. > In the Fedora case, things are simpler right up until we hit graphics > drivers. This is also a problem for VMs too, because GPU passthrough > is a common case for scientific and gaming workloads. As long as the > NVIDIA driver remains dominant in Linux, UKIs cannot work because by > design you cannot load anything that isn't part of the kernel image. That's simply not true. Along with UKIs we developed the "sysext" concept, to make them extensible. Primary usecase: extend the basic initrd with drivers/subsystems that you want on some systems but not all. > For bare metal, we *need* these drivers in early boot, though. And > that's another problem: no third-party early boot drivers. Even if you > solve the signing issue, you need to introduce some kind of two-stage > OS boot process so we can bring up the bare minimum to load a second > image containing all the remaining drivers. In the UKI model the UEFI stub (i.e. systemd-stub) actually loads the sysext images from UEFI mode still, via UEFI fs APIs. i.e. they area already in memory when the initrd initializes, and can be used instantly. They are validated via verity/kernel certification keyring. > And at that point, you've > defeated the purpose of UKIs. I've heard from some people that system > extensions (sysexts) would be a way to solve this, and maybe it is. > But again, we've eliminated the value of UKIs by doing so. I don't see any value being "eliminated". > Speaking more broadly, there are also problems that will be introduced > as this trickles down from Fedora into prominent downstreams (assuming > this is accepted). In the RHEL case, you've basically broken driver > disks completely. In the UKI model, there's no way to incorporate > early boot storage, network, and graphics drivers. There is, sysext. > The crux of the problem here is *signing*. All of this is tied up in > Secure Boot and TPM, which is the wrong place to actually handle > this. sysext authentication is tied to kernel keyring authentication actually, exactly like kernel modules. The kernel keyring can be populated via mokutil. > In other operating systems (notably Windows), Secure Boot certificates > are not used for blocking or enabling kernel-level drivers. Instead, > there's a kernel-level certificate store that is used to validate and > enable drivers, allowing everything to be managed in a hardware > platform agnostic way. I think people currently accept that mokutil is the certificate store for Linux. If you don't like that, I might even agree to some point with that, but this isn't new in the context of UKIs or sysext, we just use the very same infrastructure kmods use. > I've also yet to hear of a decent reason for > TPM measurements too. Block or filesystem verity provides similar > guarantees to provide tamper resistance and are both much easier to > debug than TPM interfaces. Unlocking secrets via TPM is usually what you want for write acccess. Verity is read-only only. > With my FESCo hat on, I'm uneasy about this change. With my "Fedora > user and advocate" hat on, I think that the UAPI group has failed to > provide something useful to the Linux world here and I would be > extremely apprehensive about Fedora adopting any portion of this > stuff. Umpfh. This is FUD. Please read up before writing scathing comments like that. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 12:38, Neal Gompa (ngomp...@gmail.com) wrote: > > sd-boot implements boot counting by stashing the counter inside the > > UKI (or bootspec type #1 conf file) file name, so that the counter is > > impossible to ever get lost, pile up or so. > > Because the ESP is intended to be shared, and these days /boot is not. > Unshared boot content should not be in a shared space. This is wrong on two levels: 1. The boot loader should process all UKIs from all installed OSes, hence the UKIs should be dropped in in a *shared* directory, not a private directory. It's the idea of the boot loader spec to make the drop-in dir shared between Linux OSes. 2. The UEFI spec defines clearly where OSes should put private stuff in the ESP if they have any (see https://uefi.org/registry for example, fedora is listed there btw). The ESP is very clearly defined both in terms for shared resources and for private resources. I am not sure what you intend to put in /boot? If it's UKIs then please notice that these are a single file per kernel/initrd combo, and that is inherently placed in a shared dir, you need nothing else really. > We can only really have one boot manager, especially with how broken > multiple ESPs on a system are. Why would you have multiple ESPs? I don't follow? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 12:35, Neal Gompa (ngomp...@gmail.com) wrote: > > And similar for server/embedded stuff. If fedora wants to be deployed > > in such worlds, it's kinda nice if we can automatically recover from > > hosed updates. > > None of those things require us to write data to /boot. Even in your > model, if you *must* write to a filesystem, the counters can live on > the ESP even if all the system-installed content exists in /boot. I'm > sure you could envision a simple file in the ESP for that. None of > that is permanent configuration, just transient stuff. I don't follow your thinking at all. On one hand you want /boot/ to be ext4, supposedly for data safety reasons. But you don't want writes from pre-boot environment to go there. You are fine if pre-boot writes to ESP (i.e. VFAT) however for boot counting. So, ESP is more important for booting than /boot/ (simply because a hosed kernel doesn't matter, if you have another — a hosed boot loader is much more problematic however since you typically have no other), hence if anything you should be more concerned about writes there than on /boot. If you accept that writes to the ESP/VFAT are actually OK, then I think it's just a minor step to say that /boot/ as VFAT is also OK given these writes are more seldom, are done from the safer OS environment, and can be tightly controlled. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 07:40, Neal Gompa (ngomp...@gmail.com) wrote: > > And journaling actually is more a problem than a solution due to > > firmware (or grub) filesystem drivers often not having full support for > > the journal. Luckily this is rarely a problem in practice because /boot > > is rarely written to. > > We could just make those read-only from the bootloader side then. I > have /boot on btrfs, which grub/efifs doesn't support writing to at > all anyway. Write grubenv settings into the BIOS boot partition or ESP > rather than /boot. The ESP is more important for booting than /boot. It's a bit weird you are fun with writes to the former, but have issues with the latter. Generally: boot counting/assement/fallback data is best attached to the resources it's supposed to cover, to make rotating/vacuuming of that data obvious and robust. Otherwise if you remove a boot entry you need to find the matching data at a completely different place and remove that too, which is quite fragile. sd-boot implements boot counting by stashing the counter inside the UKI (or bootspec type #1 conf file) file name, so that the counter is impossible to ever get lost, pile up or so. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 12:21, Neal Gompa (ngomp...@gmail.com) wrote: > > > > Why shouldn't FAT be used for /boot. In an EFI world, /boot > > > > is used for the same functional pupose as the ESP, which is > > > > already going to use FAT. > > > > > > Doesn't support links, lournaling and ACLs. > > > > What you want in a boot loader: native read access, write access. > > Actually no, I don't want the boot loader / boot manager writing > anything. Well, good for you. But I think it would be wise for Fedora to implement automatic fallback for hosed kernels, and that requires counting boot attempts, and that requires storing the counters somewhere. And that means we need to store something somewhere. Hence write access from pre-boot is typically desirable. Basically, there are too places a boot loader can write stuff: file system and NVRAM. The latter is problematic to write to since cheap hw supposedly doesn't allow too many write cycles before breaking. Hence file system it must be. If Fedora every intends to be useful for people who cannot recover a hosed system on their own because they are Linux guru themselves, I am pretty sure we want automatic boot assessment/fallback logic in place. And similar for server/embedded stuff. If fedora wants to be deployed in such worlds, it's kinda nice if we can automatically recover from hosed updates. I am sure Neal Gompa can recover his own machines, but not every Fedora system comes with a Neal Gompa deployment included. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 14:00, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > > And journaling actually is more a problem than a solution due to > > firmware (or grub) filesystem drivers often not having full support for > > the journal. Luckily this is rarely a problem in practice because /boot > > is rarely written to. > > The journal is very useful when writing kernels there. how so? iirc grub's fs drivers can't even replay the journal? if you drop single files into vfat by creating a file under a random name, then writing the file linearly in full, then syncing, and then renaming it to the final name (and syncing again) you should get equal/better guarantees from the fs, in a way actually compatible with the pre-boot env. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote: > > At least for the systemd stuff, we carefully made sure that our access > > patterns to the ESP both from sd-boot/sd-stub and from userspace are > > by default as minimal and robust as we can make them, to minimize > > chance of corruption, given that vfat is not particularly good with > > that. (i.e. we sync a lot, and the whole ESP mount is by default an > > autofs instance with an extremely short idle timeout so that it > > basically remains unmounted — and thus — clean during almost all > > times). > > > > Anyway, if you want to know more about choice of the fs for /boot/, > > see my ideas here: > > > > https://0pointer.net/blog/linux-boot-partitions.html > > > > Lennart > > Does vfat support atomic rename? Is it possible to atomically upgrade > a bootloader/UKI/etc? Depends on the fs driver. But yeah, the filename is stored at exactly one place, and hence typically a single-sector update is possible. (well, within bounds: for example if you rename a file from a short filename to a long one, fs driver might need to allocate a bunch of separate long file name dir entries, which might then span multiple sectors) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 12:53, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > On 21/12/2022 12:38, Daniel P. Berrangé wrote: > > Why shouldn't FAT be used for /boot. In an EFI world, /boot > > is used for the same functional pupose as the ESP, which is > > already going to use FAT. > > Doesn't support links, lournaling and ACLs. What you want in a boot loader: native read access, write access. What UEFI doesn't have any understanding of and just ignores: symlinks, ACLs. What grub's fs drivers doesn't even implement: journalling, write access. hence, ext4 via efis might be OK as a compat solution, but it delivers only stuff one doesn't want, and lacks everything one does want. > Everyone can do whatever they want with the files, and a trivial power > outage can easily wipe out all of its contents. As mentioned elsewhere, write access to the ESP are generally done at a very limited set of operations: 1. new kernel installed/old one removed 2. boot loader updates 3. random seed refreshes 4. boot counter updates All of these are extremely simple operations, that either are single sector writes, or implemented via whole file replacement, which typically can be implemented robustly even on vfat. i.e there's no long-running access, no random access, nothing like that. systemd's autofs logic for the ESP (and the write patterns bootctl implements) are designed to give you data safety for the ESP to the level this could be possible. Sure, it's still no journalling, but it's as close as it can get. -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 06:27, Neal Gompa (ngomp...@gmail.com) wrote: > On Wed, Dec 21, 2022 at 6:23 AM Vitaly Zaitsev via devel > wrote: > > > > On 20/12/2022 19:56, Chris Murphy wrote: > > > Great. The gotcha though is this in effect requires a change in the file > > > system currently mounted at /boot, which is ext4. And ext4 isn't > > > supported by sd-boot or UEFI firmware. So if you're going to support > > > sd-boot, the installer needs to be aware that either the ESP is big > > > enough to be used as /boot, or if it's not big enough then it will be > > > mounted on /efi*and* a new partition XBOOTLDR formatted as FAT will be > > > used as /boot. > > > > Nobody should use FAT for /boot. efifs[1] should be used instead. > > > > systemd-boot can load these drivers from ESP out of the box[2]. > > > > [1]: https://github.com/pbatard/efifs > > [2]: https://github.com/systemd/systemd/issues/15617 > > Indeed. We should not endeavor to create more problems by putting more > stuff in the ESP. By doing so, we lose features and capabilities from > our own native filesystem. No matter what boot manager we use, we > should not be required to give that up. We already have efifs[1] > packaged in Fedora, let's use that. That's such a weird logic. /boot is supposed to contain data consumed by the boot loader, not so much by the OS. What do you think a boot laoder is going to do with access modes, file ownership, selinux labels? I am pretty sure we should reduce problems and simplify things by just using VFAT for boot loader stuff, and put everything at the least number of places possible. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 12:22, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > On 20/12/2022 19:56, Chris Murphy wrote: > Great. The gotcha though > is this in effect requires a change in the file system currently > mounted at /boot, which is ext4. And ext4 isn't supported by sd-boot > or UEFI firmware. So if you're going to support sd-boot, the > installer needs to be aware that either the ESP is big enough to be > used as /boot, or if it's not big enough then it will be mounted on > /efi*and* a new partition XBOOTLDR formatted as FAT will be used as > /boot. > > Nobody should use FAT for /boot. efifs[1] should be used instead. I vehemently disagree. VFAT is the way to go. It's simply a pointless excercise to use anything else. https://0pointer.net/blog/linux-boot-partitions.html I think it might be OK to stick to ext4 for upgrades, but outside of that, for new installs it's something that really should be avoided I am sure. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote: > For the general case we need some other option. Could be just stick to > grub2 for those cases (we'll continue to need grub2 anyway for bios boot > and ppc64le). Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers, > for example this one: > https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg I am pretty strongly against the idea of ext4 for /boot/. First of all, the firmware can't read it natively, but what's worse, uefi cannot even make sense of any of the features it provides above vfat. i.e. file ownership, access modes, ACLs, selinux labels, xattrs, symlinks, … are all complete nonsense to the UEFI fs layer (and to boot loaders that natively implement the fs drivers, the same). The UEFI fs API has no concepts for *any* of these features. Hence, if this is supposed to carry data intended for consumption by the boot loader, why the f**k would you use a file system it cannot even remotely take benefit of? Also, I am pretty sure boot loaders should have the ability to make changes to the file systems they read UKIs from, to implement boot counting and random seed management. grub fs drivers and the stuff derived thereof (i.e. efifs stuff) typically is read-only though. At least for the systemd stuff, we carefully made sure that our access patterns to the ESP both from sd-boot/sd-stub and from userspace are by default as minimal and robust as we can make them, to minimize chance of corruption, given that vfat is not particularly good with that. (i.e. we sync a lot, and the whole ESP mount is by default an autofs instance with an extremely short idle timeout so that it basically remains unmounted — and thus — clean during almost all times). Anyway, if you want to know more about choice of the fs for /boot/, see my ideas here: https://0pointer.net/blog/linux-boot-partitions.html Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Mi, 21.12.22 10:16, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > Without an initrd we immediately have the following limitations: > > - all kernel modules needed to mount root must be compiled in > > - all that code is always loaded and remains in unswappable memory > > - root= syntax is limited to what the kernel understands, i.e. > > no root=UUID=… o root=/dev/disk/by-path/… or other udev links, > > no encryption or dm-verity. > > - no bluetooth keyboards or other fancy peripherals > > - recovery is pretty hard > > Also, the security lock-down for the kernel command line means: > - no network root filesystem > - no boot-time-only kernel/module configuration > > The idea of switching from grub2 to sd-boot would also drop network boot > and BIOS support. Supporting boot loaders seems to be a bit of a issue > sometimes, so trying to support multiple boot loaders seems like a bad > idea to me. I am not sure why you think that kernel command line lockdown would mean no network root fs anymore? I mean, sure, if you use the Fedora supplied vanilla signed UKI without anything else then it won't boot from a network, because that would be a security hole. But I see no reason why a network boot UKI couldn't be build that maybe be booted via PXE and derives root fs info from DHCP alone. (I mean, this is going to be as secure or insecure as your DHCP leases are protected, but the security is definitely not going to be worse than in the status quo ante that way) (you could also build/sign your own UKIs with the network boot info baked in. Or you could use TPM-bound systemd "credentials" to provide the network server info to the booted kernel securely) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Di, 20.12.22 13:56, Chris Murphy (li...@colorremedies.com) wrote: > > * Better secure boot support (specifically the initrd is covered by > > the signature). > > We need to solve the glaring hole that is the initrd. There's no > question about it. I can't really assess if this feature is the best > way to do that. Or if it would be adequate for dracut to self-sign > every locally generated initrd with a unique key pair and throw away > the private key after each initrd is generated. Or if we could do > enough strict standardization in the boot chain with a possibly > larger kernel to avoid needing an initrd, i.e. get to sysroot mount > faster thereby obviating the need for a large initrd. Systems without initrd are unrealistic outside of corner cases. I am pretty sure that if you care about SecureBoot then you must care about protecting the root fs somehow, too. Otherwise fixing the initrd hole is a pretty pointless excercise. Protecting the root fs means encryption/LUKS, Verity or dm-integrity in some way. But that implies an initrd, in particular if you want to hook that up with TPM or FIDO2 or so, which I am pretty sure should be considered a pretty common case sooner or later. I think initrd-less systems only make sense as a corner case for certain low-security systems, but certainly not as a default. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Di, 20.12.22 20:42, Björn Persson (Bjorn@rombobjörn.se) wrote: > The root filesystem is also relevant for troubleshooting, when I take a > storage device out of a broken computer and connect it to another > computer to inspect it. Suddenly there are two "discoverable" root > partitions, and the kernel parameter is necessary to specify which one > is the root filesystem, as stated under "Doesn’t this break multi-boot > scenarios?": > https://uapi-group.org/specifications/specs/discoverable_partitions_specification/#doesnt-this-break-multi-boot-scenarios Nah. When booting without root= so that the root partition is auto-discovered then this is done on the disk the ESP that was used for booting is found on and no other disks. Thus: once you pick a disk for booting in the firmware menu, auto-discovery won't "leave" this disk anymore. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: limiting the (systemd) journal size
On Di, 27.09.22 10:12, Chris Murphy (li...@colorremedies.com) wrote: 65;6800;1c > The obvious bike-shedding questions are: Is 4G is too much or too > little? If so what amount it should be? Is size still the correct > approach? Or should we consider a max retention time? And if so, > what would it be and how granular should it be? > > Also, what's the scope? Is a change needed Fedora-wide, in a manner > that's upstreamable? That could prove difficult because any change > will negatively impact other use cases, not least of which is what > the upgrade behavior should be if it'll involve trimming > journals. Are the current defaults optimal for most use cases most > of the time? There will be a higher burden of persuasion to get a > Fedora-wide change, rather than optimizing for just desktops. > > But that isn't intended to limit the discussion to just the desktop > case. Just to be aware that the broader and grander the change, the > more consideration of the consequences there needs to be, i.e. less > bike shedding. > > More background and discussion upstream and Workstation working > group issues. [1] BTW, if you can make a good case for this, consider submitting this change upstream instead of keeping this specific to Fedora. The values we default to are just some values I came up with which 10y or so and made rough sense to me, but the idea was always to tweak them as we learn how things behave in real life. So, if there's good case to be made to tweak them in some way we can certainly consider making that upstream. (i.e. if you compiled a good list of pros/cons and have some specific values to propose please submit a github issue upstream about this, and we can look into this.) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: future of dual booting Windows and Fedora, redux
On Do, 28.07.22 17:18, Gregory Bartholomew (gregory.lee.bartholo...@gmail.com) wrote: > > One is not really supposed to have multiple ESPs on the same > > medium. ... > > That "on the same medium" is an interesting caveat. I've been trying to do > A/B type configurations where there are two (or more) ESPs on redundant > "system" drives (one per drive). I'm still not sure that it is officially > supported. But it seems like it ought to be. But I guess I'm way off topic > from the purpose of this thread. I look forward to Fedora Linux fixing its > multiboot problems by switching to systemd-boot. :) Having one ESP on each individual medium is fine. The firmware will boot into the ESP that is configured in the EFI boot variables, or if none is configured into the one that is found on the boot medium that is found first according to your firmware's boot medium order. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Fr, 29.07.22 00:21, Peter Boy (p...@uni-bremen.de) wrote: > > One is not really supposed to have multiple ESPs > > I have another question regarding multiple ESPs, maybe a bit > off-topic. For software raid we currently have a kind of „off-label > use“. Anaconda puts the ESP on a raid partition (and the /boot > partition as well) and so the partition is marked as RAID and not as > ESP. I know, there are several alternatives in development to > synchronise ESP partitions, but none is included in Anaconda. And > maybe none of the alternatives is ready for production. How does > this fit into the plans being discussed here? It is an important > issue for Fedora Server. That's a terrible idea. UEFI file system drivers are read/write. sd-boot makes use of that even, to implement boot counting/automatic fallback (which I am sure is stuff you *really* want in attended systems that shall be able to safely come back when rebooted). Given that firmware and uefi programs can and do write through the official sanctioned UEFI APIs to the ESP using RAID on ESP is a really bad idea — unless the firmware also implements your flavour of RAID. But it would be news to me that firmwares exist that support Linux software RAID natively. ESP is defined the way it is, you cannot reinvent its storage underpinnings without breaking the other players that might access the ESP, i.e. firmware, boot loaders, other dual boot OSes. If you want to replicate the ESP, do so by synchronizing contents from userspace maybe. But even that is unreliable, since you can't necessarily trust mtimes there, to figure out what is newer... I mean, my understanding is that you want to increase reliability by having a working ESP around on multiple disks. But by doing such off-label use stuff you just create problems for yourself that decrease realiability. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Do, 28.07.22 15:03, Chris Murphy (li...@colorremedies.com) wrote: > > Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR so > > that the firmware will pick it up properly. The only problem is when using > > the bootctl command to initialize that partition (/boot), it requires that > > I set the SYSTEMD_RELAX_XBOOTLDR_CHECKS variable. I don't think it should > > require setting that environment variable in that case. But maybe I'm using > > the command incorrectly? The command I'm running is: > > > > SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot > > --esp-path=/boot > > omit --boot-path and have only an --esp-path Correct. > > I think you have to set both "--boot-path" and "--esp-path" to the > > same value to get the merged partition. If I leave off > > "--boot-path", then I don't have to set the variable. But I'm not > > sure that it will configure everything correctly in that > > case. Will it? > > It should. BLS envisions two configurations: ESP only, contains all > files; ESP contains bootloaders, XBOOTLDR contains /loader/entries > and everything else. There isn't really a concept of one partition > being both ESP and XBOOTLDR. > > An argument could be made in favor of two ESPs instead of an ESP and > XBOOTLDR, but whatever. I'm not going to make it. One is not really supposed to have multiple ESPs on the same medium. Firmware should use the first one only, and ignore the other, but you know how firmware is, when it finds unexpected stuff... Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Do, 28.07.22 13:05, Gregory Bartholomew (gregory.lee.bartholo...@gmail.com) wrote: > VFAT-formatted version of the partition somewhere and perhaps leave the old > one as a (temporary) failback. Besides the bootloader itself, all that is > really on the /boot partition is the kernel and initramfs right? Pretty much, yes. > Also, this might be a little off-topic, but I've recommend that people use > systemd-boot when trying to dual-boot Windows before: > https://ask.fedoraproject.org/t/dual-booting-windows-10-and-fedora-34/14158/2 > The user reported that they were happy with that solution later on in that > thread, but one annoyance I have is that it requires setting a > "SYSTEMD_RELAX_XBOOTLDR_CHECKS" variable before running "bootctl install". > Is that really necessary? Why does the /boot partition require a distinct > GPT type code? The boot loader needs a way to find the file systems to look into. It does so by scanning the GPT table, to find a suitable partition, and the GPT partition type we use is the indicator for "suitable" partition. Note that the sdboot from UEFI mode has no access to your /etc/fstab, i.e. it doesn't know that you might mount some generic partition to /boot/. Thus it needs another way to recognize the partition. That's why you have to set the GPT partitoin type to XBOOTLDR. > The /boot partition existed long before GPT and its type > codes, so this seems a strange requirement (having a separate /boot was a > common practice decades ago because the older BIOSes couldn't bootloaders > that were placed beyond cylinder 1024 on the disk; it was also common to > format /boot with FAT back then because syslinux liked to use that). I'd > like to request that systemd-boot "automatically" accept/recognize a merged > ESP+XBOOTLDR partition without having to set that special variable. sd-boot looks for menu items in the ESP, as well as the XBOOTLDR partition, if it exists. There's no need to "merge" ESP with XBOOTLR, because everything you could place in XBOOTLDR you can as well put in the ESP *anyway* if space permits it, since sd-boot checks both place. (The reverse is not true however, certain specific things can only be placed on the ESP, and not in XBOOTLDR, most prominently any fs drivers that are needed to access the XBOOTLDR partition should it not be VFAT) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Do, 28.07.22 10:25, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Lennart Poettering said: > > Given the overlap of the Fedora/RH boot loader folks and the shim > > folks, I think there's definitely an avenue to get systemd-boot signed > > as payload for SHIM, as alternative to Grub. If Fedora wants this, and > > has the man power for it, it should be a quite a reachable goal, given > > that sd-boot has only a tiny fraction of the code footprint that Grub has. > > So, I went to look a little more at systemd-boot/sd-boot... and noticed > the packaging is really odd in Fedora. Why is it shoved into the > systemd-udev RPM? It seems that systemd-boot should be its own > subpackage. I think this was mostly done because the rpm split originally done was to separate out parts that you need when booting systemd in a container from those which you do not need there. udev/sd-boot is useless in a container, hence it was split out, and was turned into a seperate new rpm, named after one of the most prominent components. I am not involved in systemd packaging anymore, but I am sure if you make your case on rhbz Zbigniew or so will consider your case. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Do, 28.07.22 16:54, Petr Pisar (ppi...@redhat.com) wrote: > > This sounds pretty awesome, actually. I'd like to see that get > > implemented... > > > Unfortunatelly (complex) file system drivers are not written with safety > on mind. They rather prefer performance over security. If somebody signed a > UEFI driver for ext4, there would be a storm of CVEs "Secure boot bypass with > a contrived file system". efifs just added uefi glue on top of grub's fs drivers. Thus, if grub is fine to sign, then efifs is much much less risk, given it's a fraction of the grub codebase, but actually mostly code from the grub codebase. But anyway, I am actually advocating for sticking to VFAT everywhere. ext4 drivers in the boot loader only are necessary for the upgrade path. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Di, 26.07.22 13:37, Neal Gompa (ngomp...@gmail.com) wrote: > > > As I already mentioned the last time this has come up: Why can we not, > > > instead of chainloading Windows directly, chainload a systemd-boot > > > configured to always bootnext to Windows? > > > > Pretty sure shim still hard codes the name grub$arch.efi as the 2nd > > bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find > > and run it. They can't co-exist right now. Also, there's no current plan by > > anyone to add systemd-boot for Secure Boot signing. > > > > >GRUB would still think it boots > > > Windows directly. (I do not see why it would notice any difference, all > > > that > > > would change is the name of the image that gets chainloaded.) And systemd- > > > boot does not need to know that it is being chainloaded from GRUB. So I do > > > not see why that would not work, without any changes to the software. > > > > Put more directly: Microsoft will revoke our shim if we use > anything but GRUB as the stage-two bootloader. > > Cf. https://github.com/rhboot/shim/issues/472#issuecomment-1118628769 To state this clearly: The people I talked to in MSFT do not know of any such requirement. To me, the above comment appears to be FUD. In fact, the SHIM review guidelines already say this: "Note that we really only have experience with using GRUB2 on Linux, so asking us to endorse anything else for signing is going to require some convincing on your part." (from https://github.com/rhboot/shim-review#readme) Hence, it's the shim people who are not keen on non-grub boot loaders, but even they indicate they can be convinced of other boot loaders. Given the overlap of the Fedora/RH boot loader folks and the shim folks, I think there's definitely an avenue to get systemd-boot signed as payload for SHIM, as alternative to Grub. If Fedora wants this, and has the man power for it, it should be a quite a reachable goal, given that sd-boot has only a tiny fraction of the code footprint that Grub has. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Mi, 27.07.22 17:35, Chris Murphy (li...@colorremedies.com) wrote: > >> If the additional barrier to adoption that Fedora imposes is that > >> every distro needs to also include signed efifs ext4 in order to > >> read $BOOT, I think it's too much. > > > > I do not follow that logic. First of all, if they can sign grub or > > sd-boot they should be able to sign efifs too. Secondly, they could > > just embedd the relevant efifs driver in the sd-boot binary, and sign > > the result (see other mail). Hence, you build two binaries. Make one > > of them. Sign one binary. > > Sure. But all the distros need to support and build efifs drivers in > order to support at least common $BOOT file systems across all of > Linux, if they're really truly committed to BLS, if not arbitrary > file systems. > > There's at least ext4, XFS, Btrfs widely used as $BOOT by default > these days. But more when looking at what distro installers allow > /boot to be: f2fs, ZFS, LUKS, LVM... Well, if distributions choose to put boot loader spec drop-ins onto such weird file systems they either didn't understand that the spec is about defining a *shared*, *common* resource, because that way they made it inaccessible to everyone else. Or they did understand it, but simply didn't care. Whether sd-boot is used to read it, or grub doesn't really matter at that point... Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Mi, 27.07.22 17:15, Chris Murphy (li...@colorremedies.com) wrote: > > > On Wed, Jul 27, 2022, at 4:47 PM, Lennart Poettering wrote: > > On Mi, 27.07.22 16:19, Chris Murphy (li...@colorremedies.com) wrote: > > > >> >> Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or > >> >> Extended Boot Loader Partition (XBOOTLDR), and in effect they need to > >> >> be FAT in order to fulfill the interoperability intent of the spec, > >> >> because it is a shared $BOOT across all distros. > >> > > >> > You can use any FS you want with efifs[1]. > >> > >> Yeah, but it's impractical: > >> > >> * $BOOT is supposed to be readable by all distros that share $BOOT > > > > Hmm, afaik fedora installs /boot/ currently as ext4, no? *Every* Linux > > OS should be able to mount that... > > I'm talking about distro bootloaders being able to read $BOOT in the pre-boot > environment. > > If Fedora decides $BOOT Is ext4, that binds other distros looking to > adopt BLS into shipping signed efifs ext4 too, in order to use the > same $BOOT format we are. Or else, ignore our XBOOTLDR and create > their own, in which case we're right back to square one, which is > mutually exclusive /boot, no sharing or cooperation between distros. Well, boot loader spec is *already* used by fedora on ext4. So you are describing the status quo? I mean, I for one would always suggest people to use the spec on vfat only, and not bother with ext4, so that it is truly universally accessible. But that is simply not what Fedora chose to do, and instead put it on ext4. Not we need to find reasonable compatible ways to support that for existing installations, but not more. For future installations we can all just do boot loader spec on vfat and all distros will be jolly. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Mi, 27.07.22 17:01, Chris Murphy (li...@colorremedies.com) wrote: 65;6800;1c > > > On Wed, Jul 27, 2022, at 4:30 PM, Lennart Poettering wrote: > > > So, let's say you want to make sd-boot be able to access a legacy ext4 > > /boot/ fs. First, fix the GPT partition type of that /boot/ partition > > to be the XBOOTLDR one (so that sd-boot can recognize it; currently > > fedora for some reason marks it as "generic Linux partition"). Then > > take the ext4 uefi driver from the project above, sign it as you sign > > every EFI binary, and drop it into the /EFI/systemd/drivers/ directory > > on the ESP. This is all you need to do, as sd-boot looks into that > > dir, and automatically loads all drivers found there. > > Works for single distro installation, sure. But the intent and > promise of BLS is distro interoperability with a shared $BOOT among > multiple distros. > > If the additional barrier to adoption that Fedora imposes is that > every distro needs to also include signed efifs ext4 in order to > read $BOOT, I think it's too much. I do not follow that logic. First of all, if they can sign grub or sd-boot they should be able to sign efifs too. Secondly, they could just embedd the relevant efifs driver in the sd-boot binary, and sign the result (see other mail). Hence, you build two binaries. Make one of them. Sign one binary. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Mi, 27.07.22 16:50, Chris Murphy (li...@colorremedies.com) wrote: > > I prefer no shim in my computers. I'm using systemd-boot signed by my > > own CA. > > That is not a generic solution we can ship in Fedora. Since each > distro ships their own shim, they'd each have to ship their own > signed fsfs in order to read the shared a non-FAT $BOOT. It's too > high a barrier to adoption. Something we could add relatively easily to sd-boot is that it could look for drivers to load in one of its own PE sections (let's say a new section ".drivers"). Then Fedora could do something like this: 1. build ext4 efifs as UEFI PE binary (→ ext2_x64.efi) 2. build systemd-boot as UEFI PE binary (→ systemd-bootx64.efi) 3. use "objcopy --add-section .drivers=ext2_x64.efi systemd-bootx64.efi systemd-bootx64.withext4.efi" to embedd the ext4 driver inside systemd-boot 4. sign the resulting systemd-bootx64.withext4.efi via shim/… 5. profitt! now you have an sd-boot binary that can do ext4. yay. 6. ask relevant other distros to do the same. They are probably in a very similar situation as fedora is, given they typically all use Grub right now. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Mi, 27.07.22 16:19, Chris Murphy (li...@colorremedies.com) wrote: > >> Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or > >> Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be > >> FAT in order to fulfill the interoperability intent of the spec, because > >> it is a shared $BOOT across all distros. > > > > You can use any FS you want with efifs[1]. > > Yeah, but it's impractical: > > * $BOOT is supposed to be readable by all distros that share $BOOT Hmm, afaik fedora installs /boot/ currently as ext4, no? *Every* Linux OS should be able to mount that... > * efifs drivers must be signed in order to be loaded on UEFI Secure > Boot enabled systems Well, if fedora can sign a kernel PE image it can also sign an efifs PE image. The efifs code stems from Grub fs drivers. It's not new code. It's a small part of Grub code that has been considered to be good enough in the Grub status quo hence should not require major re-review when loaded as EFI module instead. > * shim is distro specific, and is what provides the key for efifs as > well as the 2nd stage bootloader > > There are already enough barriers to Boot Loader Spec adoption. But > this would be too big a barrier. Dunno. The fedora EFI signing infra shouldn't care if you give it a PE kernel image to sign or a PE efifs driver. I mean, the devil is certainly in the detail, but conceptionally these are not new codepaths, but new payloads used in existing codepaths. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual booting Windows and Fedora, redux
On Mi, 27.07.22 10:13, Chris Murphy (li...@colorremedies.com) wrote: > > Since you say systemd-boot can already do what we want in this regard: > > > > e. Replace grub for EFI systems with systemd-boot ? > > I wish it were possible. I'm pretty sure the Red Hat bootloader team > has no time or interest in it. And there's no upgrade path, because > systemd-boot requires a FAT /boot volume. That's only half the truth. sd-boot searches for kernels on the ESP (which has to be VFAT effectively, since that is the only thing UEFI requires firmwares to support), or on an optional, second partition we call XBOOTLDR which is more like fedora's /boot/ – and that one can be basically any file system, the only requirement is that it must be readable via UEFI file system APIs. VFAT qualifies for that out of the box, hence is a good choice. That said, it's not the only option, there are multiple projects supporting other file systems in UEFI, for example this one: https://efi.akeo.ie/ So, let's say you want to make sd-boot be able to access a legacy ext4 /boot/ fs. First, fix the GPT partition type of that /boot/ partition to be the XBOOTLDR one (so that sd-boot can recognize it; currently fedora for some reason marks it as "generic Linux partition"). Then take the ext4 uefi driver from the project above, sign it as you sign every EFI binary, and drop it into the /EFI/systemd/drivers/ directory on the ESP. This is all you need to do, as sd-boot looks into that dir, and automatically loads all drivers found there. Net effect: "bootctl install" (the tool that installs sd-boot for you) installs two EFI binaries instead of just one. Given that the project above simply uses the Grub file system implementations and adds a bit of uefi glue on top, you would actually use the exact same code to access the file systems as before in the Grub case. That all said: I am pretty sure using non-vfat for XBOOTLDR should be a legacy thing. New installations should use vfat for ESP + XBOOTLDR, to minimize complexity. Given that fedora already generates Boot Loader Spec entries sd-boot should otherwise be ready to just read what is already there. > The lack of an upgrade path, I think, is a bigger issue than a > system-wide change proposal to: switch to systemd-boot on UEFI, > including FAT /boot partition, for new clean installs. I don't think the upgrade path would be so bad. Takes some careful work to get into place, but we went through worse migrations in Fedora I am sure. > There's quite a lot of GRUB upstream work related to TPM stuff, > including measured boot. I have no idea if we're going to use any of > that at some point, but it's not something in systemd-boot's realm. Frankly, the TPM and grub situation is a giant mess. The PCR measurements it generates measure chosen code execution paths, not static code, and hence are entirely useless if you want to reliably precalulate PCR values, and bind policy to that. It's one of the reasons why outside of fixed-purpose systems with a limited scope noone does TPM on Linux. With systemd-boot/systemd-stub we have more reliable measurements already (we measure code, not chosen code execution paths), which means there are some projects (such as ubuntu core, which currently chainload sd-boot from grub, just to be able to get the realiable TPM measurements we provide you with...). Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pre-change: lower printk setting after switching to real root
On Do, 21.07.22 05:56, Colin Walters (walt...@verbum.org) wrote: > >> We recently did > >> https://github.com/coreos/fedora-coreos-config/pull/1840 for Fedora > >> CoreOS (more background: > >> https://github.com/coreos/fedora-coreos-tracker/issues/1244 ) and > >> I'd like to consider applying this to all Fedora editions. > >> > >> There'd be no impact on desktop systems (commonly installed via > >> Anaconda and hence using `quiet`). > >> > >> The benefit is for server systems where we *do* want some kernel > >> output at boot, but once we've successfully booted we don't want to > >> emit a message every time podman/docker creates a bridge device for > >> example. > >> > >> Concretely today, I noticed that the RHEL 8.6 Cloud Guest image also > >> does not include `quiet` and so the kernel console log is full of > >> the same spam at runtime, and I think it makes sense to do this > >> change across all Fedora derivatives. > > > > I am note entirely sure if this feature has merit or not, > > Definitely interested in your opinion, because...a bikeshed here is > where to put this unit if it's not systemd. The thing is that serial console output from the kernel is really slow and slows down the kernel (because it's synchronous, in some way). And this slowness is not just minor issue you can ignore, it's actually massive, if you do that across your fleet. OTOH I am also not sure that this kinda of cosmetics really matter on servers. They are usually not interacted with on their console, except for debugging. But in that case, wouldn't it be better to just allow the whole logs to go through? So there are reasons not to log to the console needlessly, and there are reasons to always log to the console to improve debugging. Hence, it doesn't appear to me that it is clear that doing what you are proposing is universially a good idea. It kinda feels as if in 30% of uses it might be beneficial, in 30% people would hate it, and in 30% people might not care... That's why I don't really want to agree or disagree with the proposal, it's not clear at all to me that what you are doing there is a good idea across the board. It might be in the coreos case, if you say so, but universally, i am not sure. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mi, 20.07.22 20:48, Demi Marie Obenour (demioben...@gmail.com) wrote: > > So, in my view of the world, the kernel command line is fixated in the > > unified kernel image (if you use systemd-stub, this already happens if > > a .cmdline PE section exists, and SecureBoot is on). If you want to > > override it, then turn off SecureBoot. > This is not a sufficient solution, as it creates an unnecessary > security risk. I have had more than one occasion where my system was > unbootable and I had to rescue it, either by using an installation > image or by editing the kernel command line. Disabling secure > boot would allow this, but it also means that *any* code might run, > which is not wanted. What I want is to be able to authenticate as > an authorized superuser, and know that the only code that will be > able to run is code that would have run anyway, code involved in > the recovery mechanism, and code that I have specifically entered or > caused to be run. There is a huge difference between “anything at > all can run” and “an authenticated and authorized superuser can > provide additional code to be run”. The thing is: if you want to allow making the kernel command line controllable by the user but still protect it cryptographically, then you need to authenticate it before passing control to the kernel. For example in sd-stub, i.e. the UEFI stub code that runs in UEFI mode, before ExitBootServices() is called. But authenticating that is messy, because you need to authenticate it against something, i.e. user password (i.e. interactivity at each boot), or TPM. Both is very messy (because it either takes non-interactive boot away, or means embeddeding a TPM stack of some form into sd-stub, because UEFI will only give you access to the TPM in a bytestream, not with high-level commands). Hence, I am not convinved the benefit really outweighs the effort here. Modifying your kernel command line is invasive, and hackish, and hence I think it's OK to leave it out of the model. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki (marma...@invisiblethingslab.com) wrote: > > I wonder if Qubes OS could use any of this work. It seems that it > > would be incredibly useful, at least if it supported systems using > > the Xen hypervisor. > > That's probably going to be useful for Qubes OS too, indeed. > > It would be even better, if kernel cmdline could be pre-measured too, as > many kernel parameters may affect overall system security (like > disabling iommu). There is currently one major issue with this: finding > root filesystem. If the "initrd cmdline" could be separate from > "kernel cmdline", then one could include pre-measured safe kernel > cmdline (perhaps even hardcoded into kernel binary), while still being > able to instruct initrd where to look for the root fs. Of course, initrd > would need to be careful about parsing this piece of information > (probably having some allowlist of options allowed in this case), but > that's a huge improvement already. There were few other ideas for this > problem in this very thread too. So, in my view of the world, the kernel command line is fixated in the unified kernel image (if you use systemd-stub, this already happens if a .cmdline PE section exists, and SecureBoot is on). If you want to override it, then turn off SecureBoot. I think finding the root fs is something that should be solved without a dynamic kernel command line. I see three options: 1. Don't specify the root fs at all, let systemd-gpt-auto-generator find it for you. It does that by default: it looks for a properly tagged root partition in the GPT partition table the ESP used to boot was found on. 2. If you use a Verity-enabled root fs, then pin the root fs via its top-level hash on the kernel cmdline, and build that one into the unified kernel image. systemd-gpt-auto-generator helps you with that, if you use roothash= on the kernel cmdline, then this is entirely enough for it to find the partitions, and configure them as dm-verity. 3. Use the new credentials logic in systemd, that allows encrypted/authenticated credentials, bound to the TPM2. "Credentials" are just data blobs that you can pass from external sources into a system and from a system into services. These credentials can be optionally encrypted+authenticated against a symmetric key in the TPM. (for details see: https://systemd.io/CREDENTIALS). One data source for these credentials is *.cred files in the directory you put the kernel image in, if you use systemd-stub. The idea would then be: wrap information where to find the root fs in a credential, encrypt/sign it with the key from the TPM, place the result int the ESP. sd-stub then picks it up, passes it to the booted kernel/initrd. The initrd then reads it, decrypts/authenticates it, and then uses the info to mount the rootfs. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Di, 19.07.22 21:16, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > Would pre-building the initrds mean all users have to use the same > partition layout. If that happened, than many people dual boot > setups will not work No, it dos not mean that. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pre-change: lower printk setting after switching to real root
On Fr, 15.07.22 10:03, Colin Walters (walt...@verbum.org) wrote: > We recently did > https://github.com/coreos/fedora-coreos-config/pull/1840 for Fedora > CoreOS (more background: > https://github.com/coreos/fedora-coreos-tracker/issues/1244 ) and > I'd like to consider applying this to all Fedora editions. > > There'd be no impact on desktop systems (commonly installed via > Anaconda and hence using `quiet`). > > The benefit is for server systems where we *do* want some kernel > output at boot, but once we've successfully booted we don't want to > emit a message every time podman/docker creates a bridge device for > example. > > Concretely today, I noticed that the RHEL 8.6 Cloud Guest image also > does not include `quiet` and so the kernel console log is full of > the same spam at runtime, and I think it makes sense to do this > change across all Fedora derivatives. I am note entirely sure if this feature has merit or not, but I don't want to comment on that. However, I'd like to suggest that if you do this, please consider replacing this line: ExecStart=/bin/bash -euo pipefail -c 'mkdir -p /run/sysctl.d && chcon --reference=/etc/sysctl.d /run/sysctl.d && echo "kernel.printk = 4" > /run/sysctl.d/01-coreos-printk.conf' by something like this: ExecStart=/usr/bin/systemd-tmpfiles --create - StandardInputText=f /run/sysctl.d/01-coreos-printk.conf - - - - kernel.printk 4 Benefits: no shell, single process forked, no explicit selinux stuff, or explicit mkdir, and other MACs will be honoured too if they exist. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Di, 19.07.22 16:15, Gerd Hoffmann (kra...@redhat.com) wrote: > > Moreover, this allows us to implemented TPM policies that bind to > > signatures of PCR hashes, instead of the literal hash values. That > > makes the measurements a *million* times more useful, since we loose > > the brittleness on updates: if the expected PCR values can be > > pre-calculated by the vendor, and then be signed, then an update won't > > invalidate the policies anymore. > > Another case which requires creating initrds at build time. Yupp. Zbigniew and I are working on making pre-built initrds for general purpose distros a reality, i.e. finding a way between keeping things reasonably modular but also pre-generated, immutable, pre-measurable, and thus have a tight trust chain at boot. We'll do two talks about that at Linux Plumbers Conference later this year. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mo, 18.07.22 14:52, Gerd Hoffmann (kra...@redhat.com) wrote: > On Fri, Jul 15, 2022 at 10:33:03AM -, Francois Rigault wrote: > > Another idea is to measure the initrd and the boot configuration, for > > example taking a hash of the grub configuration and initrd and > > extending a PCR register. > > That is already happening. > > Problem with measuring the initrd is that we don't have fixed hashes for > a given kernel version (due to generating the initrd on the installed > system). > > Problem with grub config measurements is that grub measures every config > file line it processes, which is quite messy: The very newest kernels measure all initrds on their own into PCR 9 these days. It should be the only thing measured into PCR 9, hence you can pre-calculate what you are going to see in the PCR easily if you have the initrds. I also intend to change sd-stub to measure the kernel it is prefixed to and the other stuff it makes use of from the PE image into a separate PCR, that is otherwise not used so far. i.e. PCR 11 or so. This stuff could then also be easily pre-calculated: if you have the kernel image you know what the PCR value will be. Once we have that, we can relatively easily express policies for TPM resources that bind to kernel + initrd, and pre-calculate those easily at build time (or at install time in case of dynamic initrds), without any need for rebooting into the new setup and then looking at the measured hsah values. Moreover, this allows us to implemented TPM policies that bind to signatures of PCR hashes, instead of the literal hash values. That makes the measurements a *million* times more useful, since we loose the brittleness on updates: if the expected PCR values can be pre-calculated by the vendor, and then be signed, then an update won't invalidate the policies anymore. The next step is then to extend the kernel PE images, to also contain the PCR hsah signatures appropriate for the kernel. That would make it nice and simple to deploy new kernels in a robust fashion so that they always carry enough metainfo so that TPM policies can be written that match the vendor. (the model isn't perfect yet though: tpm policies built that way need some rollback protection, i.e. some counter kept in tpm nvram that can only increase, and whose cutoff value is also signed along with the PCR hashes, so that one can invalidate old kernels if needed, without having to invalidate signatures as a whole) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: proposal idea: EOL notifications
On Mi, 06.07.22 21:05, Gary Buhrmaster (gary.buhrmas...@gmail.com) wrote: > On Wed, Jul 6, 2022 at 3:45 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > https://github.com/systemd/systemd/pull/23924 proposes adding > > SUPPORT_END=-MM-DD to /usr/lib/os-release. > > I like the concept, but > > (warning, taxonomy discussion) > > The announcement for os-release included > the following statement: > >Please prefix your keys with your distribution's >name however. Or even better: talk to us and >we might be able update the documentation and >make your field standard, if you convince us that >it makes sense. > > And while I would prefer the effort to get > the field standardized (perhaps END_OF_SUPPORT=?) > any name in Fedora should be something of > the form REDHAT_ or FEDORA_ I would > probably also prefer the stanza be differently > named (I prefer the term EOL or EOS) but the > important point (to me) is the prefix. It's an *upstream* PR, and the os-release format is defined by the systemd project, so because this has been merged now it as as "standard" as it can get now, across distros. Still up to each distro individually if they actually want to implement it though. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: proposal idea: EOL notifications
On Mi, 06.07.22 18:15, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > I'm aware of the release schedule ;) > The date would only need to be set (at most) twice: > - once before the release of Fn > - after Fn+2 is released and Fn has 1 month left > (only if Fn+2 slipped) > > And it's true that you will not get the update of the date if no > updates are installed… But if you don't update ever, does it really > matter that you have the EOL date off by a week or two? This date is > meaningful for systems that are _maintained_, i.e. at least get > updates every few weeks. Maybe our os-release docs should mention that this is the latest *known* support date, and suggest that people refresh the OS to newest set of relevant package to get newer info. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mi, 06.07.22 16:13, Gerd Hoffmann (kra...@redhat.com) wrote:
> grub2 doesn't find it. Support not implemented?
afics grub2 upstream has no native support for boot loader spec
stuff. (or has that changed?)
The fedora version of grub2 implements a flavour of type #1 boot loader spec
entries (i.e. .conf entries), but not type #2 (i.e. unified kernels), iirc.
> Ok, lets try systemd-boot instead. Install.
> Chainload from grub for now:
>
> root@fedora ~/mkosi-initrd (main)# cat /boot/grub2/custom.cfg
> if [ "$grub_platform" = "efi" ]; then
> menuentry 'systemd boot loader' {
> chainloader (hd0,gpt1)/efi/systemd/systemd-bootx64.efi
> }
> fi
>
> systemd-boot doesn't find it either. Double-checking. ESP mounted at
> /boot/efi. Directory looks fine to me:
>
> root@fedora ~/mkosi-initrd (main)# ll /boot/efi/EFI/Linux
> total 77832
> -rwx--. 1 root root 79698816 Jul 6 15:36
> unified-5.18.9-200.fc36.x86_64.efi
>
> Any clues?
I am not a grub guy, haven't used it in a long time. But my educated
guess is this: I think grub might load the chainloaded binary into
memory itself, and then execute it from there, instead of invoking it
directly from the ESP file system. This matters because if sd-boot is
invoked from a synthetic file in memory we cannot derive the directory
tree of the ESP from it, and thus not find boot loader entries.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)
On Di, 05.07.22 22:35, Dusty Mabe (du...@dustymabe.com) wrote: > On 6/25/22 15:06, Vipul Siddharth wrote: > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > > > == Summary == > > > > The `systemd-udev` package installs > > `"/usr/lib/systemd/network/99-default.link"`, > > which sets `Link.MACAddressPolicy=persistent`. This proposal is to > > change it to set `Link.MACAddressPolicy=none` to stop changing the MAC > > address. > > This is particularly important for bridge and bond devices. > > > > This change can either only apply to bridge/bond devices, or to > > various software devices. That is to be discussed. > > Based on the feedback here on the list we have modified the scope of this > proposal > to now be limited to changing the MACAddressPolicy=none for bond/bridge/team > devices only. > > New summary: > > ``` > The systemd-udev package installs "/usr/lib/systemd/network/99-default.link", > which sets Link.MACAddressPolicy=persistent for all software NIC devices. > This proposal is to add to the policy so that we use > Link.MACAddressPolicy=none for bond/bridge/team devices. > ``` > > https://fedoraproject.org/wiki/Changes/MAC_Address_Policy_none So, with changing this back you'll also break all those setups where it is assumed the bridge MAC just works and is stable and independent from the devices added to it and the order in which they are added in. What makes you so sure, that changing this *again* is so much better than just leaving it the way it is now? This change isn't precisely new, and changing stuff forth and back comes at quite a price. Generally, if we change behaviour like this, then the pros must seriously outweight the cons. Now you might argue that when the original change was made that wasn't the case, that's a valid opinion, though one I disagree with. But that has no effect on today, on the question whether changing it again is worth it. I am pretty sure that there are *also* numerous scripts that benefit from the predictability and stability you get with the status quo, and which you'll break if you revert to the old state – again. I am not convinced we should flip flop on this all the time. Yes, it's unfortunate that people tripped over this, but you are not really making it better if you then break it *again*, given the benefit is unclear, and the major software creating bridges/bonds/… doesn't care anyway (i.e. NM, networkd, …). I for one do not see where you'd get the crystal ball to look into to know that by changing this *again* you'll make bazillions of people happy, and only very few people sad, because you break their stuff. It might very well be that you'll make more people sad because you break their stuff again, than were happy before. Also, let's not forget that allowing users to set the policy is a good thing, we should let them. Given that the original change was already made a lot of software that cannot work with such changes has already been updated to override the default policy. That's a good thing, since the overall system becomes more robust and people can more safely change the policies locally, with less breakage to expect. if you now revert to the status quo ante, then you basically also say: fuck it, we don't care that software is fixed to work with changed policies, let's keep things brittle that you cannot change policies anymore effectively because we are sticking our head in the sand and don't care that they are fixed. So, I am not convinced. I can accept that this wasn't handled particularly nicely originally. My proposal for addressing this is via documentation, i.e update the udev and iproute docs to explicitly point to the issue and how to deal with it, with an example drop-in to make it easy to deal with it. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Di, 05.07.22 09:49, Gerd Hoffmann (kra...@redhat.com) wrote: > Hi, > > > > > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf > > > > we tried to make rh image builder people inetreested in that, but they > > weren't interested in that at all. > > For initrd building or for cloud image building? initrd building. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Di, 05.07.22 02:34, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > > Like what? > > I know there are some efi implementations that need > pcie_ports=compat. I also know that sometimes you need intel_iommu > or amd_iommu=off. Those are local hacks to get very new or very exotic hw to work without fixing the kernel properly. But it's not the way this *should* work. Instead, the kernel should detect these systems properly on its own, and make this work without adjusting the kernel cmdline. There's plenty infrastructure for that available in the kernel. What you are doing with the above is a hack that should require highest privileges to do, and hence it's OK (not just OK, it's *good*) to disable SecureBoot for that while you make them. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Di, 05.07.22 01:44, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > Also, if users have "special" hardware, shouldn't they also have > security. if you need a special kernel cmdline to get your system to boot, then that's a bug in the kernel, and should be fixed there. Adding a kernel cmdline option is a local hack at best, executable only by the most technically savvy of users, and I think for those it's totally OK if you have to disable SecureBoot if you hack around. Kernels should work universally, and if the don't do that out-of-the-box on some very new or very exotic hardware, then the right fix is not to expect users to be technical enough to set a kernel cmdline, but to fix the kernel to apply the fix automatically where needed. The kernel has plenty infrastructure for that. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: With F36 systemd-nspawn test environment not usable, no login possible
On Di, 05.07.22 14:38, Dominique Martinet (asmad...@codewreck.org) wrote: > Peter Boy wrote on Tue, Jul 05, 2022 at 07:19:28AM +0200: > > […]# dnf --releasever=36 --best --setopt=install_weak_deps=False \ > > --installroot=/var/lib/machines/testf36 install dhcp-client dnf \ > > fedora-release glibc glibc-langpack-en iputils less ncurses passwd \ > > systemd systemd-networkd vim-default-editor > > > > I can set a password using > > > > […]# systemd-nspawn -D /var/lib/machines/testf36 passwd > > > > I create a container with > > > > […]# systemd-nspawn -D /var/lib/machines/testf36 -b > > If you check the syslog of that machine (don't ask me how, I just > straced agetty) Use this on the host journalctl -f -M testf36 This allows you to watch the logs for the running container live. > you'll see it complain that there is no /bin/login: you just need to > install util-linux (or possibly busybox) and you'll get a prompt, > login should work as well. This smells as a bug in in the package providing getty. getty cannot work without /bin/login, hence the package should have a dep on it. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mo, 04.07.22 19:27, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > I think using credentials for the rootfs is not very useful, the > user already enters the LUKS password on boot. I can't parse this. the systemd credentials stuff are not just for passing secrets or so. They can be used for any kind of config option. And they are not just encrypted but also authenticated. That means we can use them to pass root device info (i.e. a string like /dev/disk/by-uuid/…) in. For that the encryption doesn't matter, but the authentication does, as we can use the info safely after authentication, since we know it was encoded by someone who had the permission to do so. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mo, 04.07.22 15:59, Gerd Hoffmann (kra...@redhat.com) wrote: > Hi, > > > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf > > Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like > being at proof-of-concept state. mkosi going fetch stuff from the > internet to generate the initrd is clearly a non-starter (maybe not that > much of a problem when doing it in koji where the next fedora repo is > only one network hop away). Well, we didn't find any better tools, i.e. with all the verity stuff and signing in place. mkosi is just a wrapper around dnf, it's not really that smart... If it is fine building any kind of RPM-based image on fedora infra this shouldn't be any different... we tried to make rh image builder people inetreested in that, but they weren't interested in that at all. > I don't think mkosi is a hard requirement for unified kernel images > though. No, it's not. mkosi is just a python script gluing all the dnf, gpt, fdisk, verity, signing stuff together. You can reimplement that. > Once the local configuration issues are solved it should be > possible to run "dracut --no-hostonly" in koji + ship results instead > of doing it on the installed host, no? We want to build initrds from RPM, to make the reasonably reproducible and follow proper deps. It's a major facet of the project. magic build scripts trying to magically determine deps from ELF and config and whatnot is kind what we want to get away from. > > The credentials logic can also be used to for example pass a root pw > > for the initrd in a safe way. > > Does systemd-cryptenroll use this? Use what precisely? the root pw? no, why would it? or the credentials api? i mean, there's no direct hookup, but we don't really need it: from the service side credentials are just files in the file system, and we do support reading keys from that. > When getting the credentials for the encrypted root filesystem (or > something else) from somewhere else, i.e. some attestation server such > as https://keylime.dev/, how could that be integrated with systemd-creds > best? Simply have the agent write to /run/credentials? I don't know keylime. But note that service credentials can be read from a variety of sources: most prominently regular files on disk you specify via an fs path. Now one tweak here is that if you actually specify an AF_UNIX socket inode in the fs as fs path, then we'll connect to it, and read the credential data from it. This is a flexible way to plug anything you like into the service credential logic: all keylime has to do is bind a socket somewhere, with tight perms, and then whenever a connection comes in just write the credential data into the connection and close it right after. > > My expectation would be that by default we'd just use the GPT auto > > discovery stuff and for "pet" systems maybe also encode the root > > device with a credntial, but for "cattle" systems not bother. > > Yep. > > Is there some fallback mechanism btw? Most cloud images have just four > partitions: bios-boot, efi esp, boot and root. And the root filesystem > is simply the largest partition ... Actually, the implementation of the gpt auto logic (at least on some contexts) is somewhat tolerant: if the partitions are not properly tagged (i.e. use generic type uuids) but there's only a single one that would be a candidate, then it will be used as root fs. We refuse working that way though once you have two entirely generic partitions and we thus have no clue which it could be... But why not just fix the cloud images to just use descriptive type uuids? that has no drawbacks, just benefits. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mo, 04.07.22 19:24, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > > My expectation would be that by default we'd just use the GPT auto > discovery stuff > > Existing Fedora installations do not follow the GPT auto discovery > spec. If it is desirable to automatically switch existing installations from "locally-genrated dracut mode" to "pre-build unified kernels mode", then make sure to encode the root fs uuid in a credential and place it next to the kernel. > Also, I think the existing system for the root device can > still work, it is passed in the command line, not the initrd. Well, we'd have to authenticate that kernel cmdline somehow. Which means doing TPM stuff before we switch to Linux kernel mode. i'd rather avoid that, since afaics this would boil down to linking a static copy of the TSS stack into an UEFI binary. It's OK to modify your kernel cmdline if you really want, but if you want that level of tweaking then it's probably totally OK to just turn of Secureboot, at which point you can change it freely. I am not convinced it must be a priority to allow arbitrary local kernel cmdline options even in the most locked down mode. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mo, 04.07.22 19:18, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > Even if initrds are (somehow) signed, the kernel command line can > still be modified, like adding `init=/usr/bin/bash`. Hmm? sd-stub refused any kernel cmdline passed in manually if SecureBoot is on. The kernel cmdline allows you to do pretty much anything you like with your system, hence in a locked down environment we cannot allow uncontrolled access to that. > Also, if everything is signed by fedora, then the user can not > modify the command line. There is a lot of hardware that needs > command line modifications to boot. Like what? > Also, fedora would have to revoke signatures for every vulnerable > kernel, or there is no real security. If those kernels signatures > are revoked, then they wont boot even when they are the currently > installed kernel and should be able to boot. I think as long as we get rollback protection we should be fine. i.e. after a kernel has been deemed good and working for a bit, we can automatically cut off older kernels via TPM logic after a while. (this requires implementing a TPM policy against a counter stored in the TPM. This is not implemented yet in the TPM policies systemd supports, but can be expression in TPM2 policy language.) > If there is a way for a fedora signed kernel image to > load a locally signed command line, then this would work much > better. Well, we could add that, but this would mean doing more complex TPM interactions from UEFI environment, and I'd rather not do that too much. > > However I think the initrd should be built on fedora infra > > and signed with fedora keys by default. > > What about when the user has a custom kernel module, would there be > a way for the user to use it. You can enroll multiple certificates for validation, if you like. i.e. if you want to sign your own modules, then enroll both the fedora and your own cert. You could use shim for that if you like. Or alternatively, turn off secureboot if you don't want to set up your certs, and want to load hacky modules. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mo, 04.07.22 11:32, Gerd Hoffmann (kra...@redhat.com) wrote: > Hi, > > > We have been working on building tools and filling gaps to make that > > workable reasonably in systemd upstream, and with a focus on > > Fedora. The difficulty is in both being able to prebuild everything > > but also keeping things somewhat modular and parameterizable. Because > > right now those are the primary reasons initrds are built on the > > installed host instead of Fedora: they contain local configuration and > > drivers. If we prebuild everything we must have model to > > replace these parts, without compromising security, and that's not > > rivial. > > Is all this this discussed somewhere in public? We'll have a session about that at Linux Plumbers Conference... There was a talk about it at devconf.cz: https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf > systemd-devel list maybe? That'd probably be the best place, yeah. > For virtual machines we need some way to make sure they actually run > the software we want them run, and it seems the options we have are: > > (1) finally plug that initrd hole, or > (2) use encrypted /boot > > ... where (2) feels more like a workaround for the unsigned initrd > problem and it also opens another can of worms like requiring luks > support in the boot loader. I find 2 very wrong, as it doesn't solve the actual issue (provides confidentiality, not actually authenticity). Moreover, as important as authentication is getting sane TPM measurements out of the whole thing, so that further policies can mapped to all this. > I guess you already have a list of the "local configuration" bits > which must be tackled? Obvious #1 is finding the root filesystem. > Should be solvable with discoverable partitions. A few days back > I've found a 7 (!) year old bug[1] of yours truly asking to support > that in anaconda, still in NEW state :( In a fully trusted environment I'd expect that the immutable root fs is pinned in the kernel image via the root hash. In a semi-trusted environment we should use GPT meta info to find the rootfs. This can either be the discovery partition sspec stuff (which I'd recommend), or if people insist a simple root=PARTLABEL=fedora or so on the kernel cmdline. An alternative is to use the systemd credential logic for this (this stuff: https://systemd.io/CREDENTIALS/). It allows encrypting and signing small blobs of info (so called "credentials") with the local TPM. They can then safely be stored on an untrusted medium (such as a ESP/boot partition), and are verified/decrypted on access. The "systemd-stub" EFI stub can automatically pick up such encrypted credentials from the ESP too, similar to the extension initrd images mentioned earlier in this thread. The credentials logic can also be used to for example pass a root pw for the initrd in a safe way. My expectation would be that by default we'd just use the GPT auto discovery stuff and for "pet" systems maybe also encode the root device with a credntial, but for "cattle" systems not bother. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mo, 04.07.22 09:30, Daniel P. Berrangé (berra...@redhat.com) wrote: > > > When going for multiple initrds the best approach is probably to simply > > > split out the kernel modules into a version-specific initrd and store > > > everything else in another, shared initrd. > > > > In the approach Zbginiew and I are working on we intend to build a > > basic initrd into the kernel itself (i.e. in a unified kernel logic) > > and then optionally load additional initrd images that can be > > placed next to the kernel image and are picked up by the EFI stub > > (i.e. by the EFI code that runs as part of the kernel when it runs in > > EFI mode still, before we transition to Linux mode, i.e. where all the > > EFI file systems are still accessible), and are passed to kernel, > > measured and then very early on overlayed on top of the basic initrd > > image (i.e. in an immutable overlayfs stack). > > > > In such an approach the basic initrd would be able to just boot 90% of > > the systems, and for the other 10% we'd just add a couple of extension > > images next to the kernel image, and that's it. > > That sounds good. Given their pretty homogeneous hardware I would hope > that 90% figure ought to be able to reach near 100% for virtual machines > on the common hypervisors/clouds (KVM, Hyper-V, VMWare, AWS) Yes, that would be the benchmark: the most common systems should be bootable with a single unified kernel images, and that of course includes all popular virtualizers. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mo, 04.07.22 04:19, Demi Marie Obenour (demioben...@gmail.com) wrote: > On 7/4/22 04:13, Lennart Poettering wrote: > > On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote: > > > >>> I do wonder if it's possible to use multiple initrds, and maybe have > >>> the firmware in a separate initrd shared between all installed kernels > >>> if we go down this route. > >> > >> grub supports multiple initrds just fine. According to > >> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub > >> supports multiple initrd files also with bls. That seems to be a > >> derivation from the original boot loader spec though, so not sure this > >> works with systemd-boot too. > >> > >> When going for multiple initrds the best approach is probably to simply > >> split out the kernel modules into a version-specific initrd and store > >> everything else in another, shared initrd. > > > > In the approach Zbginiew and I are working on we intend to build a > > basic initrd into the kernel itself (i.e. in a unified kernel logic) > > and then optionally load additional initrd images that can be > > placed next to the kernel image and are picked up by the EFI stub > > (i.e. by the EFI code that runs as part of the kernel when it runs in > > EFI mode still, before we transition to Linux mode, i.e. where all the > > EFI file systems are still accessible), and are passed to kernel, > > measured and then very early on overlayed on top of the basic initrd > > image (i.e. in an immutable overlayfs stack). > > > > In such an approach the basic initrd would be able to just boot 90% of > > the systems, and for the other 10% we'd just add a couple of extension > > images next to the kernel image, and that's it. > > > > (the extension images would be signed dm-verity squashfs, to ensure > > everything is authenticated) > > Would the extension images also be measured into the TPM? Yes, precisely. Sorted alphabetically, and then measured. (And in fact, picked up by IMA too, because dm-verity is nowadays picked up by it, iirc). Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote: > > I do wonder if it's possible to use multiple initrds, and maybe have > > the firmware in a separate initrd shared between all installed kernels > > if we go down this route. > > grub supports multiple initrds just fine. According to > https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub > supports multiple initrd files also with bls. That seems to be a > derivation from the original boot loader spec though, so not sure this > works with systemd-boot too. > > When going for multiple initrds the best approach is probably to simply > split out the kernel modules into a version-specific initrd and store > everything else in another, shared initrd. In the approach Zbginiew and I are working on we intend to build a basic initrd into the kernel itself (i.e. in a unified kernel logic) and then optionally load additional initrd images that can be placed next to the kernel image and are picked up by the EFI stub (i.e. by the EFI code that runs as part of the kernel when it runs in EFI mode still, before we transition to Linux mode, i.e. where all the EFI file systems are still accessible), and are passed to kernel, measured and then very early on overlayed on top of the basic initrd image (i.e. in an immutable overlayfs stack). In such an approach the basic initrd would be able to just boot 90% of the systems, and for the other 10% we'd just add a couple of extension images next to the kernel image, and that's it. (the extension images would be signed dm-verity squashfs, to ensure everything is authenticated) Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.
On Sa, 02.07.22 00:15, Marius Schwarz (fedora...@cloud-foo.de) wrote: > Hi, > > I have some bug reports for PA opening BZ and only one ever got a response. > > Is it possible that this is the cause: > > You can't ask /Lennart Poettering / because that > account is disabled. > > I tried a needinfo request after a month long silence. > > Short: PAVU shows the input meter at the app output tab since the upgrade > from f34 to f35. > https://bugzilla.redhat.com/show_bug.cgi?id=2092513 I haven't done audio stuff for a long time now. I should probably be honest and orphan that stuff in Fedora. Anyone wants to take this over? That said, I have now created a personal rhbz account, and moved the FAS stuff over. I am told that should fix the bugzilla mess. Let's see. That said, this doesn't mean I will look into your bug reports, audio is not my focus of work anymore, systemd is. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
