Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Thu, Oct 31, 2019, at 12:26 PM, Lennart Poettering wrote: > Well, what I proposed is a file. OSTree can cover files on disk, no? Yes...we can try to figure out an extension to version them. > I doubt on AWS you want to configure keymaps though, do you? No, but there are similar server cases: - iSCSI which apparently has quite nontrivial configuration files (things you wouldn't ergonomically do in the kernel cmdline) so they end up requiring regenerating the initramfs. - Tang/NBDE https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Network-Bound_Disk_Encryption.html And for OpenShift 4 we are aiming to support NBDE even in clouds like AWS for a few reasons; some customers don't want to 100% rely on EBS encryption, and supporting it everywhere makes our story for bare metal installation more consistent. Finally another case just came up, which is enabling some real-time kernel tuning: https://bugzilla.redhat.com/show_bug.cgi?id=1775917 Today tuned injects some bits into the initramfs for this - specifically we need to configure systemd in the initramfs for the `CPUAffinity`. I've lately been thinking maybe we should just generalize this and introduce: /boot/etc The initramfs then can mount /boot and read files from it (or just copy in over its own /etc). One downside of this though is that it doesn't apply to PXE/NFS-root (diskless) scenarios. Those need either an overlay initramfs or kernel cmdline. Though, I guess for CPUAffinity we really need this set up and readable before systemd even starts. Hmm. So maybe we really need systemd.cpuaffinity= as a kernel argument - and in general, anything necessary for the kernel or systemd in the initramfs need to be kernel arguments. Anything after that could be /boot/etc or an overlay initramfs. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Di, 01.10.19 15:33, Colin Walters (walt...@verbum.org) wrote: > On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote: > > > i.e maybe write down a spec, that declares how to store settings > > shared between host OS, boot loader and early-boot kernel environment > > on systems that have no EFI NVRAM, and then we can make use of > > that. i.e. come up with semantics inspired by the boot loader spec for > > finding the boot partition to use, then define a couple of files in > > there for these params. > > I like the idea in general but it would mean there's no mechanism to > "roll back" to a previous configuration by default, which is a quite > important part of OSTree (and other similar systems). (Relatedly > this is also why ostree extends the BLS spec with an > atomically-swappable /boot/loader symlink, though I want to get away > from that eventually) Well, what I proposed is a file. OSTree can cover files on disk, no? > That said, maybe one thing we want regardless is a "safe mode" boot > that skips any OS customization and will get one booted enough to be > able to fix/retry for configuration like this. > > BTW related to EFI - as you know AWS doesn't support it, and we're > making a general purpose OS. Fedora isn't just about desktops, and > we need to be careful about doing anything in the OS that diverges > from the server side. (That said I only recently discovered that > GCP supports it as well as vTPMs, working on "blessing" our Fedora > CoreOS images to note they support it > https://github.com/coreos/mantle/pull/1060 ) I doubt on AWS you want to configure keymaps though, do you? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Mo, 07.10.19 10:32, Colin Guthrie (gm...@colin.guthr.ie) wrote: > Colin Walters wrote on 01/10/2019 20:33: > > On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote: > > > >> i.e maybe write down a spec, that declares how to store settings > >> shared between host OS, boot loader and early-boot kernel environment > >> on systems that have no EFI NVRAM, and then we can make use of > >> that. i.e. come up with semantics inspired by the boot loader spec for > >> finding the boot partition to use, then define a couple of files in > >> there for these params. > > > > I like the idea in general but it would mean there's no mechanism to "roll > > back" to a previous configuration by default, which is a quite important > > part of OSTree (and other similar systems). (Relatedly this is also why > > ostree extends the BLS spec with an atomically-swappable /boot/loader > > symlink, though I want to get away from that eventually) > > Just out of curiosity, when /boot is the EFI (as is recommended in the > BLS) how do you deal with symlinks when the FS is FAT based? Fedora doesn't do that. Fedora doesn't implement the boot loader spec. They implemented their own thing that is an interpreted macro language (!?), they just call it "BLS". It's why I myself never use the acronym "BLS", to avoid unnecessary confusion. Really, the Fedora thing is just a bad idea. The Fedora thing totally missed the idea that boot loader drop-ins are supposed to be dead-simple, trivially parsable and generatable static drop-in files, and just replicated the bad bad idea inherent to GRUB which is that everything needs to be an (ideally Turing-complete) programming language again. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Mo, 30.09.19 16:07, Hans de Goede (hdego...@redhat.com) wrote: > > So what you are arguing for is replacing the overlay initramfs > > with a key-value config file which gets used by both the bootloader > > and the OS. > > > > That is an interesting concept, esp. since it limits (as you advocate) > > what can be done in the overlay from "everything" to "set specific > > config variables to a value". > > > > So yes I can get behind this. > > While discussing this with Alberto an interesting problem came up. > > If we put this file in /boot/loader as you suggest, then the boot-loader > can get to it and use it to set its keymap (and in the future probably also > other stuff) but how does the localed in the initrd get to this > file? Boot loader could append it to the kernel cmdline for example. > I agree with you that having a generic mechanism to share config > between the OS and early-boot (so bootloader + initrd) is useful, > but are we then going to make the initrd mount /boot (or the ESP) ? I wouldn't no. Given that this is configuration that the boot loader is supposed to grok and parse it could just pass it on on the kernel cmdline. This would also allow boot loaders to provide a menu-drive scheme for changing kbd layouts, which they then can sanely pass on to the initrd and OS. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Mo, 30.09.19 13:23, Hans de Goede (hdego...@redhat.com) wrote: > > i.e. generating initrd images with cpio and so on is hacky, gluey, > > Linux-specific. If you just use plain simple, standardized config > > files at clearly defined locations, then reading and writing them is > > simple, they can be shared between all players, are not Linux specific > > and so on. I think systemd could certainly commit to updating those > > files then. > > This sounds interesting, although I'm not sure I like the one file > per setting approach why not have a $BOOT/loader/config file which > has key=value pairs and kbdmap would be a key in that file? Currently there's $BOOT/loader/loader.conf which is read by sd-boot and private property of it, if you so will. We could probably open that up a bit, and make it part of the boot loader spec too. The format after all is pretty mich the same semantically as the boot loader spec. > I'm afraid that will not work, some countries have multiple variants, > we actually have a bunch of Fedora bugs open about the disk unlock > support in plymouth and the "de-neo" keymap and there also are the > somewhat popular dvorak variants. Well, I am not sure we need to support more than /etc/vconsole.conf supports. Not in the initrd... > So we could do this as say a base setting but then we would need to add > a kbdmap_variant setting which when sets makes the keymap loaded > $kbdmap-$variant.map (in Linux Console terms) I guess we could specify > that setting a variant this way is allowed, but that variant settings > are OS / bootloader specific and may be ignored? I am not sure we really need to configure a 100% fully featured keymap there. as long as the basics work in initrd/boot loader we are fine... mmkeys and per-machine tweaks can happily happen in later boot. I'd go as far as /etc/vconsole.conf, but not further really. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Colin Walters wrote on 01/10/2019 20:33: > On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote: > >> i.e maybe write down a spec, that declares how to store settings >> shared between host OS, boot loader and early-boot kernel environment >> on systems that have no EFI NVRAM, and then we can make use of >> that. i.e. come up with semantics inspired by the boot loader spec for >> finding the boot partition to use, then define a couple of files in >> there for these params. > > I like the idea in general but it would mean there's no mechanism to "roll > back" to a previous configuration by default, which is a quite important part > of OSTree (and other similar systems). (Relatedly this is also why ostree > extends the BLS spec with an atomically-swappable /boot/loader symlink, > though I want to get away from that eventually) Just out of curiosity, when /boot is the EFI (as is recommended in the BLS) how do you deal with symlinks when the FS is FAT based? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote: > i.e maybe write down a spec, that declares how to store settings > shared between host OS, boot loader and early-boot kernel environment > on systems that have no EFI NVRAM, and then we can make use of > that. i.e. come up with semantics inspired by the boot loader spec for > finding the boot partition to use, then define a couple of files in > there for these params. I like the idea in general but it would mean there's no mechanism to "roll back" to a previous configuration by default, which is a quite important part of OSTree (and other similar systems). (Relatedly this is also why ostree extends the BLS spec with an atomically-swappable /boot/loader symlink, though I want to get away from that eventually) That said, maybe one thing we want regardless is a "safe mode" boot that skips any OS customization and will get one booted enough to be able to fix/retry for configuration like this. BTW related to EFI - as you know AWS doesn't support it, and we're making a general purpose OS. Fedora isn't just about desktops, and we need to be careful about doing anything in the OS that diverges from the server side. (That said I only recently discovered that GCP supports it as well as vTPMs, working on "blessing" our Fedora CoreOS images to note they support it https://github.com/coreos/mantle/pull/1060 ) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 30-09-2019 13:23, Hans de Goede wrote: Hi, On 29-09-2019 12:08, Lennart Poettering wrote: On Fr, 27.09.19 16:00, Hans de Goede (hdego...@redhat.com) wrote: Anyway, even if you insist that the Fedora desktop should care about non-EFI, which I can accept, isn't the lesson to learn to add some concept like EFI vars to those archs too? i.e. apparently OSes and boot loaders want to communicate, so why not make that happen on those archs too? I mean, the concept of EFI vars is simple and semantically it's not even essential to have NVRAM to store them in — a fact to which the EFI firmware typically used by qemu/kvm is document, as it actually stores those EFI vars in the ESP, so that they are included in the VM image. So what you are arguing for is replacing the overlay initramfs with a key-value config file which gets used by both the bootloader and the OS. That is an interesting concept, esp. since it limits (as you advocate) what can be done in the overlay from "everything" to "set specific config variables to a value". So yes I can get behind this. While discussing this with Alberto an interesting problem came up. If we put this file in /boot/loader as you suggest, then the boot-loader can get to it and use it to set its keymap (and in the future probably also other stuff) but how does the localed in the initrd get to this file? I agree with you that having a generic mechanism to share config between the OS and early-boot (so bootloader + initrd) is useful, but are we then going to make the initrd mount /boot (or the ESP) ? One wild idea I had is to have the bootloader generate an initrd on the fly with just the file in there named as say /bootloader-config and then have the bootloader pass that dynamic initrd as extra initrd to the kernel. This assumes that for TPM stuff the bootloader is the one doing the initrd measurement and that it then will NOT measure this extra initrd. This to me seems the best way to keep this flexible and avoids the pitfalls of having to mount /boot in the initrd, which I'm sure is going to break for some crazy setups (like encrypted /boot which is unlocked from within grub). This will require modifying the bootloaders we care about to do this, but that is doable. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 29-09-2019 12:08, Lennart Poettering wrote: On Fr, 27.09.19 16:00, Hans de Goede (hdego...@redhat.com) wrote: Anyway, even if you insist that the Fedora desktop should care about non-EFI, which I can accept, isn't the lesson to learn to add some concept like EFI vars to those archs too? i.e. apparently OSes and boot loaders want to communicate, so why not make that happen on those archs too? I mean, the concept of EFI vars is simple and semantically it's not even essential to have NVRAM to store them in — a fact to which the EFI firmware typically used by qemu/kvm is document, as it actually stores those EFI vars in the ESP, so that they are included in the VM image. So what you are arguing for is replacing the overlay initramfs with a key-value config file which gets used by both the bootloader and the OS. That is an interesting concept, esp. since it limits (as you advocate) what can be done in the overlay from "everything" to "set specific config variables to a value". So yes I can get behind this. i.e maybe write down a spec, that declares how to store settings shared between host OS, boot loader and early-boot kernel environment on systems that have no EFI NVRAM, and then we can make use of that. i.e. come up with semantics inspired by the boot loader spec for finding the boot partition to use, then define a couple of files in there for these params. In fact, sd-boot nowadays stores the boot-time random seed it manages to initialize the kernel's entropy pool with in $BOOT/loader/random-seed. It would only be natural to build on that, and introduce $BOOT/loader/kbdmap and so on. i.e. generating initrd images with cpio and so on is hacky, gluey, Linux-specific. If you just use plain simple, standardized config files at clearly defined locations, then reading and writing them is simple, they can be shared between all players, are not Linux specific and so on. I think systemd could certainly commit to updating those files then. This sounds interesting, although I'm not sure I like the one file per setting approach why not have a $BOOT/loader/config file which has key=value pairs and kbdmap would be a key in that file? Putting together such a spec isn't difficult even. Could be as short as: "This spec builds on the boot loader spec. The keyboard map is stored in $BOOT/loader/kbdmap, using ISO-3166-1 alpha-2 country codes. We suggest boot loaders use this for their own key maps, and pass it to the OS, for example via the kernel command line." I'm afraid that will not work, some countries have multiple variants, we actually have a bunch of Fedora bugs open about the disk unlock support in plymouth and the "de-neo" keymap and there also are the somewhat popular dvorak variants. So we could do this as say a base setting but then we would need to add a kbdmap_variant setting which when sets makes the keymap loaded $kbdmap-$variant.map (in Linux Console terms) I guess we could specify that setting a variant this way is allowed, but that variant settings are OS / bootloader specific and may be ignored? Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Am 29.09.19 um 12:08 schrieb Lennart Poettering: > Who are you designing this for anyway? I mean, isn't Fedora dropping > i386 support even these days, so that in particular the Fedora > *desktop* becomes an x86-64 only thing (and thus an EFI-only thing) seriously? what has x86_64 only to do with EFI? not a single i386 bit on any machine here for 10 years not a single UEFI machine here at the same time ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Fr, 27.09.19 16:16, Hans de Goede (hdego...@redhat.com) wrote: > > > > Secondly, the boot loader specification (the original one, not the > > weird templating/macro language fedora grub adopted) allows multiple > > initrds to be specified, with any path you like (as long as it's > > relative to $BOOT). > Hence, you can just just use a fixed path there > > pointing to an initrd that is shared between all boot loader entries, > > and then you don't need to regenerate anything, but this one initrd > > file that is shared. > > Right, that is what this is about, regenerating the shared initrd > when localed changes /etc/vconsole.conf. Since localed is the process > modifying /etc/vconsole.conf, it should also trigger the regenerate of > the shared initrd. If you do not like doing this through calling > install-kernel, then I'm open to other suggestions for how localed > can trigger / start the regeneration of the shared initrd. It is made worse by regeneration of a shared initrd. Because if you do that you *must* sign. If you instead define very specific, very focussed one-value config files only, that you can validate easily non-cryptographically, you don't need to sign. i.e. if you know for sure that the worst thing that might happen if you don't sign the kbd map config file is that you boot with a finnish keymap, then maybe people can live with that. > > Then, what about SecureBoot? I mean, do you intend to sign this second > > initrd? Just overlaying an unverified unvalidated initrd above the > > actual one is dangerous as it can be, there needs to be some > > validation beforehand. > > Well ATM we do not verify the initrd at all, nor do we verify > the kernel commandline. The commandline currently contains system > specific info; and with your bootloader appends keymap argument > proposal, would change on a keymap change. IOW it looks like we > need some way to sign (with a local key) locally generated data, > such as a shared config-initrd or the kernel commandline. > > This is a pre-existing problem which is not really made (much) > worse by adding a config initrd. I very much disagree. initrds can contain code. simple, one-value config files or EFI vars do not. > Thinking before sending patches is exactly why I started this discussion, > so thank you for your input, but again please let go of the whole > EFI only mindset it is very unhelpful and unproductive. Well, please at least accept the lessons that EFI teaches you, i.e. why and how people use EFI vars, and then maybe do the minimal work on other systems to provide something remotely similar, using the most appropriate storage technology those platforms support, using the closest semantics and behaviour you can come up with. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Fr, 27.09.19 16:00, Hans de Goede (hdego...@redhat.com) wrote: > Well until we make sure nothing ever writes outside of the user > homedir security conscious users will likely still want to use I am pretty sure the security conscious users should not run an OS that writes user stuff all over the place, but only does so into $HOME. > full-disk encryption and there is also plenty of hw which Fedora > supports which does not have a TPM2 Well, hw with fewer functions gets less functionality, and I am sure this is not surprising to most users. > > Which hence raises the question: isn't this something the boot loader > > should manage initially, and then just pass to the kernel/initrd? > > i.e. on EFI systems, shouldn't this just be an efi var, that the boot > > ldr can read, and then pass on to the kernel (or alternatively, read > > by the initrd?) Alternatively, if you care about non-EFI, isn't this > > also something you want to tell the boot ldr about, and then have the > > boot loader pass to the kernel, maybe via a struct boot_param entry? > > (or simply by appending something to the kernel cmdline if that > > doesn't fly). > > We definitely care about non EFI and we care about a scala on > bootloaders, modifying them all for this really does not scale, > so I believe we really need a solution outside of the bootloader > and parallel to that we can think about also passing this info > to the bootloader somehow. Uhm, so given we lived with this issue for so long, and given it's easy to fix on EFI in a clean and elegant way, don't you thinkg that it wouldn't be acceptable to fix it for EFI only for now? I mean, people who run fedora *desktops* on non-EFI hw are probably a small enough number of people to allow this to remain unfixed a bit longer? Who are you designing this for anyway? I mean, isn't Fedora dropping i386 support even these days, so that in particular the Fedora *desktop* becomes an x86-64 only thing (and thus an EFI-only thing). Anyway, even if you insist that the Fedora desktop should care about non-EFI, which I can accept, isn't the lesson to learn to add some concept like EFI vars to those archs too? i.e. apparently OSes and boot loaders want to communicate, so why not make that happen on those archs too? I mean, the concept of EFI vars is simple and semantically it's not even essential to have NVRAM to store them in — a fact to which the EFI firmware typically used by qemu/kvm is document, as it actually stores those EFI vars in the ESP, so that they are included in the VM image. i.e maybe write down a spec, that declares how to store settings shared between host OS, boot loader and early-boot kernel environment on systems that have no EFI NVRAM, and then we can make use of that. i.e. come up with semantics inspired by the boot loader spec for finding the boot partition to use, then define a couple of files in there for these params. In fact, sd-boot nowadays stores the boot-time random seed it manages to initialize the kernel's entropy pool with in $BOOT/loader/random-seed. It would only be natural to build on that, and introduce $BOOT/loader/kbdmap and so on. i.e. generating initrd images with cpio and so on is hacky, gluey, Linux-specific. If you just use plain simple, standardized config files at clearly defined locations, then reading and writing them is simple, they can be shared between all players, are not Linux specific and so on. I think systemd could certainly commit to updating those files then. Putting together such a spec isn't difficult even. Could be as short as: "This spec builds on the boot loader spec. The keyboard map is stored in $BOOT/loader/kbdmap, using ISO-3166-1 alpha-2 country codes. We suggest boot loaders use this for their own key maps, and pass it to the OS, for example via the kernel command line." Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 9/27/19 1:59 PM, Lennart Poettering wrote: On Fr, 27.09.19 10:20, Hans de Goede (hdego...@redhat.com) wrote: "So my plan for regular Fedora for this is as follows: 1. Have a /boot/initramfs-config.img which for now will just contain /etc/vconsole.conf (chances are this will get more files added over time) 2. Modify mkbls from /usr/lib/kernel/install.d/20-grub.install to add an initrd line for this image to the generated bls .conf file if the image is present 3. Add a new update-config-initramfs command to the install-kernel script, which generates /boot/initramfs-config.img 4. Make systemd-localed call "install-kernel update-config-initramfs: on locale (and keymap) setting changes" Uh wah? Na, let's not hook invocations of install-kernel into localed. that's just a mess. This is not thought to the end. Secondly, the boot loader specification (the original one, not the weird templating/macro language fedora grub adopted) allows multiple initrds to be specified, with any path you like (as long as it's relative to $BOOT). > Hence, you can just just use a fixed path there pointing to an initrd that is shared between all boot loader entries, and then you don't need to regenerate anything, but this one initrd file that is shared. Right, that is what this is about, regenerating the shared initrd when localed changes /etc/vconsole.conf. Since localed is the process modifying /etc/vconsole.conf, it should also trigger the regenerate of the shared initrd. If you do not like doing this through calling install-kernel, then I'm open to other suggestions for how localed can trigger / start the regeneration of the shared initrd. Then, what about SecureBoot? I mean, do you intend to sign this second initrd? Just overlaying an unverified unvalidated initrd above the actual one is dangerous as it can be, there needs to be some validation beforehand. Well ATM we do not verify the initrd at all, nor do we verify the kernel commandline. The commandline currently contains system specific info; and with your bootloader appends keymap argument proposal, would change on a keymap change. IOW it looks like we need some way to sign (with a local key) locally generated data, such as a shared config-initrd or the kernel commandline. This is a pre-existing problem which is not really made (much) worse by adding a config initrd. Doing efi vars for this at least means the various bits and pieces have to validate things explicitly for each, it's not a blanket license to insert anything randomly into the initrd... Anyway, this all sounds like it's not thought to the end. Why care for the initrd only, not the boot loader keymap? Per your own argument of why this would not be necessary for the initrd when used only for debugging, it also is not really necessary for the bootloader cmdline, since normal use-cases do not involve the bootloader cmdline. Is this actually necessary at all? Yes! Why isn't an EFI-specific solution with EFI vars for this enough? How do you handle signing/validation of this? Lennart, please stop with ALWAYS suggesting EFI only solutions, we have had the EFI only discussion a zillion times already and it is NOT productive. Please let it sink in that as long as legacy boot and non EFI architectures are officially supported by Fedora, an EFI only solution is never going to fly (for Fedora), Let's maybe think about all that first, before sending any patches... Thinking before sending patches is exactly why I started this discussion, so thank you for your input, but again please let go of the whole EFI only mindset it is very unhelpful and unproductive. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 9/27/19 1:49 PM, Lennart Poettering wrote: On Mi, 25.09.19 16:50, Hans de Goede (hdego...@redhat.com) wrote: Hi all, Currently, at least in Fedora, but I do not believe that this problem is unique to Fedora, there are 2 problems with keymap handling in the initrd. Hmm, why do you need a correct initrd in the early boot? I can see two reasons: 1. full disk encryption with the user typing in the password on the kbd. Ack that is the main use-case for this. But isn't the answer to this to link the root OS to the tpm instead, and use user-keyed crypto only for $HOME? The OS itself doesn't need to be protected after all, everbody should have the same files there anyway, it's $HOME that needs protection. Well until we make sure nothing ever writes outside of the user homedir security conscious users will likely still want to use full-disk encryption and there is also plenty of hw which Fedora supports which does not have a TPM2 2. debugging in the initrd. Does this really matter though? Aren't people who can usefully debug the initrd also smart enough to load the kbd mappings themselves (or work with american keybindings for a bit)? I agree that this is a non-issue. Aren't you making something here a problem that actually doesn't matter much? We have a bug open for this for a long long time and it is even listed on: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues That said, if it is worth fixing this, I think it is safe to say that the people involved from the Fedora side have decided it is indeed worth fixing this. why stop at the initrd here, shouldn't the bootloader get right keymaps too? After all, most boot loaders I know have a line editor... That is a very interesting point, on one hand using the bootloader line-editor sort of matches your dracut-debug scenario, IOW not so important to fix. OTOH I agree that if we are looking into fixing the kbd layout for the initrd it would be interesting to see if we can also fix it for the bootloader. Which hence raises the question: isn't this something the boot loader should manage initially, and then just pass to the kernel/initrd? i.e. on EFI systems, shouldn't this just be an efi var, that the boot ldr can read, and then pass on to the kernel (or alternatively, read by the initrd?) Alternatively, if you care about non-EFI, isn't this also something you want to tell the boot ldr about, and then have the boot loader pass to the kernel, maybe via a struct boot_param entry? (or simply by appending something to the kernel cmdline if that doesn't fly). We definitely care about non EFI and we care about a scala on bootloaders, modifying them all for this really does not scale, so I believe we really need a solution outside of the bootloader and parallel to that we can think about also passing this info to the bootloader somehow. TL;DR: IMHO regenerating the initrd is not the answer here. Yeah, leave the initrd alone, it should be immutable outside of kernel updates, I am sure. I'm willing to write localed patches implementing this (targetting Fedora 32) but before I spend time on this, it would be good to have consensus that this is the best way to handle this. Note I'm open to other suggestions. I'd be happy to merge patches that just use an EFI variable for this, so that boot loader, initrd and GNOME can all make use of this. I know you love EFI variables and I understand why you do, but unfortunately there are still e.g. a lot of 64 bit core2 duo laptops and desktops which still run fine and are still being used, so we still need to support legacy BIOS for those and there are also other more exotic platforms which do not have EFI. TL;DR: we do not live in an EFI only world, so using EFI is not the answer. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
пт, 27 сент. 2019 г. в 16:50, Lennart Poettering : > > 1. full disk encryption with the user typing in the password on the >kbd. But isn't the answer to this to link the root OS to the tpm >instead, and use user-keyed crypto only for $HOME? The OS itself >doesn't need to be protected after all, everbody should have the >same files there anyway, it's $HOME that needs protection. > It is still hard (due to the old, now expired, self-embargo) to buy any PC with a TPM in Russia. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Am 27.09.19 um 14:33 schrieb Lennart Poettering: > I mean, this sounds like needless complexity, no? As long as you can > still access your $HOME the OS shouldn't need to be saved. I mean, > that's the idea of Atomic OS that it is immutable, and everywhere > identical and thus can be downloaded anytime form the internet without > losing context. frankly, my $HOME can be easily backed up and restored, all my customizations in /etc can't or to say it different: when i lose my system state it takes me days after a fresh install to get it back in details while the normal runtime data can be easily restored that's why i never installed from scratch any of the 50 fedora instances (porudciton servers as well workstations) i am repsonsible for the past decade Atomic OS may have it's usecases but please stop thinking it's the only one, the same applies tu UEFI, here are setups without and they will continue to give you an example: there is a server for a small SOHO office 300 km away from me, it's running since 2012 365/24 and the hardware is identical as 4 other machines which are planned to be replaced next year, they will be the fallback for that server and so this RAID setup will continue running the next decade given that it#s not an UEFI setup a traine dmonkey can move over the hard drives and network cards, connect it and press the power button ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Fri, Sep 27, 2019 at 3:18 PM Alberto Ruiz wrote: > > > On Fri, Sep 27, 2019 at 12:50 PM Lennart Poettering > wrote: > >> On Mi, 25.09.19 16:50, Hans de Goede (hdego...@redhat.com) wrote: >> >> > Hi all, >> > >> > Currently, at least in Fedora, but I do not believe that this problem is >> > unique to Fedora, there are 2 problems with keymap handling in the >> > initrd. >> >> Hmm, why do you need a correct initrd in the early boot? I can see two >> reasons: >> >> 1. full disk encryption with the user typing in the password on the >>kbd. But isn't the answer to this to link the root OS to the tpm >>instead, and use user-keyed crypto only for $HOME? The OS itself >>doesn't need to be protected after all, everbody should have the >>same files there anyway, it's $HOME that needs protection. >> > > Some counterarguments here: > - The TPM does not protect you from someone stealing your entire laptop > and booting from external media, > It does, because one of the PCRs has the entire boot sequence embedded into it. If you seal the key and then boot something else, the TPM will refuse to unseal the key for you. The same can be applied to hash of the kernel image (and initrds, if someone patched systemd-boot to include them in PCR8), and/or to Secure Boot state as done by Windows. > - There are plenty of systems out there without a TPM module that Fedora > cares about > That's the main problem. Only two of my several still-reasonably-modern x64 machines have TPMs, and one of them is TPM 1.2 which requires the completely unmaintained Trousers stack. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Fr, 27.09.19 13:17, Alberto Ruiz (ar...@redhat.com) wrote: > > Hmm, why do you need a correct initrd in the early boot? I can see two > > reasons: > > > > 1. full disk encryption with the user typing in the password on the > >kbd. But isn't the answer to this to link the root OS to the tpm > >instead, and use user-keyed crypto only for $HOME? The OS itself > >doesn't need to be protected after all, everbody should have the > >same files there anyway, it's $HOME that needs protection. > > > > Some counterarguments here: > - The TPM does not protect you from someone stealing your entire laptop and > booting from external media, What's your attack scenario? I mean, what's wrong with the attacker being able to do that, as long as they cannot modify the OS nor can read or modify your $HOME? Not following on this one? > - There are plenty of systems out there without a TPM module that Fedora > cares about Well, sure, but I isn't it OK that platforms with fewer hw features have more minimal functionality? Would anyone expect otherwise? > - A key password entry is still a fallback if your motherboard gets fried > and you move your hardrive to a new laptop. I mean, this sounds like needless complexity, no? As long as you can still access your $HOME the OS shouldn't need to be saved. I mean, that's the idea of Atomic OS that it is immutable, and everywhere identical and thus can be downloaded anytime form the internet without losing context. > - /var may contain pretty sensitive data these days too (SSSD caches, > libvirt system wide vms, docker images...). That can just fine be unlocked during regular boot, if this is desirable, i.e. long after the kbd map is installed. > That said, I am not a big fan of having grub dynamically injecting cmdline > args, this can be a challenge to measure and sign the command line to > implement a trusted boot path using the TPM in the future. (I guess systemd > would need to take care of resealing the cmdline args when localectl > changes the efi var and detects the cmdline is measured). Well, i'd put the EFI outside of any cryptographic validation. I mean, if anyone can write bogus vars, then they could also replace the validation certs in the firmware i guess, so I am not sure we have to be careful with them. Moreover, I think a validity check in the sense of "do we actually have a keymap matching this name" should be sufficient. Sure, an attacker might then be able to pull off giving you a japanese keymap for a bit, but I doubt this is so bad... Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Fri, Sep 27, 2019 at 12:50 PM Lennart Poettering wrote: > On Mi, 25.09.19 16:50, Hans de Goede (hdego...@redhat.com) wrote: > > > Hi all, > > > > Currently, at least in Fedora, but I do not believe that this problem is > > unique to Fedora, there are 2 problems with keymap handling in the > > initrd. > > Hmm, why do you need a correct initrd in the early boot? I can see two > reasons: > > 1. full disk encryption with the user typing in the password on the >kbd. But isn't the answer to this to link the root OS to the tpm >instead, and use user-keyed crypto only for $HOME? The OS itself >doesn't need to be protected after all, everbody should have the >same files there anyway, it's $HOME that needs protection. > Some counterarguments here: - The TPM does not protect you from someone stealing your entire laptop and booting from external media, - There are plenty of systems out there without a TPM module that Fedora cares about - A key password entry is still a fallback if your motherboard gets fried and you move your hardrive to a new laptop. - /var may contain pretty sensitive data these days too (SSSD caches, libvirt system wide vms, docker images...). > 2. debugging in the initrd. Does this really matter though? Aren't >people who can usefully debug the initrd also smart enough to load the >kbd mappings themselves (or work with american keybindings for a bit)? > > Aren't you making something here a problem that actually doesn't > matter much? > I witnessed a user at my current employer's waste an entire morning over this issue. I know this has happened plenty of times. There are plenty of places where non-TPM full disk encryption password entry is a policy and that is not going to change anytime soon. Regardless, there are pretty strong arguments to have a configuration-only initramfs and move to a model where the userland and kernel modules initramfs images are shipped and singed from the distributor rather than dynamically created at the end user host so this is worth pursuing anyway. > > That said, if it is worth fixing this, why stop at the initrd here, > shouldn't the bootloader get right keymaps too? After all, most boot > loaders I know have a line editor... > > Which hence raises the question: isn't this something the boot loader > should manage initially, and then just pass to the kernel/initrd? > i.e. on EFI systems, shouldn't this just be an efi var, that the boot > ldr can read, and then pass on to the kernel (or alternatively, read > by the initrd?) Alternatively, if you care about non-EFI, isn't this > also something you want to tell the boot ldr about, and then have the > boot loader pass to the kernel, maybe via a struct boot_param entry? > (or simply by appending something to the kernel cmdline if that > doesn't fly). > This idea has merits, I am not sure what the situation is with keyboard layouts in GRUB, we will do some digging and come back with a status update on what's possible there. That said, I am not a big fan of having grub dynamically injecting cmdline args, this can be a challenge to measure and sign the command line to implement a trusted boot path using the TPM in the future. (I guess systemd would need to take care of resealing the cmdline args when localectl changes the efi var and detects the cmdline is measured). > TL;DR: IMHO regenerating the initrd is not the answer here. > > Yeah, leave the initrd alone, it should be immutable outside of kernel > updates, I am sure. > > > I'm willing to write localed patches implementing this (targetting > Fedora 32) > > but before I spend time on this, it would be good to have consensus that > > this is the best way to handle this. Note I'm open to other suggestions. > > I'd be happy to merge patches that just use an EFI variable for this, > so that boot loader, initrd and GNOME can all make use of this. > Thanks for the input. We need to take into account the mismatch between available keymaps in all those environments, but it is an idea worth exploring though we need to consider the mentioned shortcomings. > > Lennart > > -- > Lennart Poettering, Berlin > -- Alberto Ruiz Engineering Manager - Desktop Hardware Enablement Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Am 27.09.19 um 13:49 schrieb Lennart Poettering: > 1. full disk encryption with the user typing in the password on the >kbd. But isn't the answer to this to link the root OS to the tpm >instead, and use user-keyed crypto only for $HOME? The OS itself >doesn't need to be protected after all, everbody should have the >same files there anyway, it's $HOME that needs protection. outside a desktop machine wrong /var/lib /etc besides that there are runtime data and configs with sensible informations it's also about prevent manipulation and not only about to read something ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Fr, 27.09.19 10:20, Hans de Goede (hdego...@redhat.com) wrote: > Hi, > > On 26-09-2019 14:13, Alberto Ruiz wrote: > > Hello Hans, > > > > Thanks for starting this discussion. > > > > Looking at this from a Fedora/Dracut POV, I think we should look at this as > > the start of implementing a configuration-only initramfs, (something > > Matthew Garret has been advocating for a while) rather than making this a > > vconsole.conf/plymouth specific solution. > > Yes there seems to be consensus that the best way to handle this is using an > overlay initramfs. > > Let me copy and paste my comment on the silverblue issue about this here: > > "So my plan for regular Fedora for this is as follows: > > 1. Have a /boot/initramfs-config.img which for now will just contain > /etc/vconsole.conf (chances are this will get more files added over time) > 2. Modify mkbls from /usr/lib/kernel/install.d/20-grub.install to add an > initrd line for this image to the generated bls .conf file if the image is > present > 3. Add a new update-config-initramfs command to the install-kernel script, > which generates /boot/initramfs-config.img > 4. Make systemd-localed call "install-kernel update-config-initramfs: on > locale (and keymap) setting changes" Uh wah? Na, let's not hook invocations of install-kernel into localed. that's just a mess. This is not thought to the end. First of all: why not just use an EFI var (as suggested in another mail). Secondly, the boot loader specification (the original one, not the weird templating/macro language fedora grub adopted) allows multiple initrds to be specified, with any path you like (as long as it's relative to $BOOT). Hence, you can just just use a fixed path there pointing to an initrd that is shared between all boot loader entries, and then you don't need to regenerate anything, but this one initrd file that is shared. Then, what about SecureBoot? I mean, do you intend to sign this second initrd? Just overlaying an unverified unvalidated initrd above the actual one is dangerous as it can be, there needs to be some validation beforehand. Doing efi vars for this at least means the various bits and pieces have to validate things explicitly for each, it's not a blanket license to insert anything randomly into the initrd... Anyway, this all sounds like it's not thought to the end. Why care for the initrd only, not the boot loader keymap? Is this actually necessary at all? Why isn't an EFI-specific solution with EFI vars for this enough? How do you handle signing/validation of this? Let's maybe think about all that first, before sending any patches... Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Mi, 25.09.19 16:50, Hans de Goede (hdego...@redhat.com) wrote: > Hi all, > > Currently, at least in Fedora, but I do not believe that this problem is > unique to Fedora, there are 2 problems with keymap handling in the > initrd. Hmm, why do you need a correct initrd in the early boot? I can see two reasons: 1. full disk encryption with the user typing in the password on the kbd. But isn't the answer to this to link the root OS to the tpm instead, and use user-keyed crypto only for $HOME? The OS itself doesn't need to be protected after all, everbody should have the same files there anyway, it's $HOME that needs protection. 2. debugging in the initrd. Does this really matter though? Aren't people who can usefully debug the initrd also smart enough to load the kbd mappings themselves (or work with american keybindings for a bit)? Aren't you making something here a problem that actually doesn't matter much? That said, if it is worth fixing this, why stop at the initrd here, shouldn't the bootloader get right keymaps too? After all, most boot loaders I know have a line editor... Which hence raises the question: isn't this something the boot loader should manage initially, and then just pass to the kernel/initrd? i.e. on EFI systems, shouldn't this just be an efi var, that the boot ldr can read, and then pass on to the kernel (or alternatively, read by the initrd?) Alternatively, if you care about non-EFI, isn't this also something you want to tell the boot ldr about, and then have the boot loader pass to the kernel, maybe via a struct boot_param entry? (or simply by appending something to the kernel cmdline if that doesn't fly). > TL;DR: IMHO regenerating the initrd is not the answer here. Yeah, leave the initrd alone, it should be immutable outside of kernel updates, I am sure. > I'm willing to write localed patches implementing this (targetting Fedora 32) > but before I spend time on this, it would be good to have consensus that > this is the best way to handle this. Note I'm open to other suggestions. I'd be happy to merge patches that just use an EFI variable for this, so that boot loader, initrd and GNOME can all make use of this. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hello Hans, On 9/27/19 10:20 AM, Hans de Goede wrote: > Hi, > > On 26-09-2019 14:13, Alberto Ruiz wrote: >> Hello Hans, >> >> Thanks for starting this discussion. >> >> Looking at this from a Fedora/Dracut POV, I think we should look at this as >> the start of implementing a configuration-only initramfs, (something Matthew >> Garret has been advocating for a while) rather than making this a >> vconsole.conf/plymouth specific solution. > > Yes there seems to be consensus that the best way to handle this is using an > overlay initramfs. > > Let me copy and paste my comment on the silverblue issue about this here: > > "So my plan for regular Fedora for this is as follows: > > 1. Have a /boot/initramfs-config.img which for now will just contain > /etc/vconsole.conf (chances are this will get more files added over time) > 2. Modify mkbls from /usr/lib/kernel/install.d/20-grub.install to add an > initrd line for this image to the generated bls .conf file if the image is > present > 3. Add a new update-config-initramfs command to the install-kernel script, > which generates /boot/initramfs-config.img > 4. Make systemd-localed call "install-kernel update-config-initramfs: on > locale (and keymap) setting changes" > That sounds good to me. One comment is that as mentioned in my previous email Petitboot doesn't support having multiple initrds. That's because it kexecs a kernel and the kexec_file_load(2) syscall only allows to pass a single initrd file descriptor. So you should check if arch is ppc64le and /sys/firmware/opal exists in the 20-grub.install script and only add the config initrd if that's not the case. At least until Petitboot gets support for multiple initrds. In the meantime it will just use the /etc/vconsole.conf if exists in the initramfs, which is the current situation. > I am waiting for feedback from the silverblue people to see if this will also > work for them. If they are happy with this then I plan to start implementing > this when I'm done with the plymouth keyboard layout indicator stuff. > > Regards, > > Hans > Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 26-09-2019 14:13, Alberto Ruiz wrote: Hello Hans, Thanks for starting this discussion. Looking at this from a Fedora/Dracut POV, I think we should look at this as the start of implementing a configuration-only initramfs, (something Matthew Garret has been advocating for a while) rather than making this a vconsole.conf/plymouth specific solution. Yes there seems to be consensus that the best way to handle this is using an overlay initramfs. Let me copy and paste my comment on the silverblue issue about this here: "So my plan for regular Fedora for this is as follows: 1. Have a /boot/initramfs-config.img which for now will just contain /etc/vconsole.conf (chances are this will get more files added over time) 2. Modify mkbls from /usr/lib/kernel/install.d/20-grub.install to add an initrd line for this image to the generated bls .conf file if the image is present 3. Add a new update-config-initramfs command to the install-kernel script, which generates /boot/initramfs-config.img 4. Make systemd-localed call "install-kernel update-config-initramfs: on locale (and keymap) setting changes" I am waiting for feedback from the silverblue people to see if this will also work for them. If they are happy with this then I plan to start implementing this when I'm done with the plymouth keyboard layout indicator stuff. Regards, Hans On Thu, Sep 26, 2019 at 12:43 PM Hans de Goede mailto:hdego...@redhat.com>> wrote: Hi, On 26-09-2019 11:53, Michael Chapman wrote: > On Thu, 26 Sep 2019, Hans de Goede wrote: >> Hi, >> >> On 26-09-2019 11:10, Michael Chapman wrote: >>> On Thu, 26 Sep 2019, Hans de Goede wrote: >>> [...] I believe that the best alternative is to have localed append / update a rd.vconsole.keymap=foo argument to the kernel commandline, to override the vconsole.conf KEYMAP setting, but only in the initrd (so that later runtime changes when booted still work). The way I see this working is that localed does a read-modify-write of all the BLS .conf files under /boot/loader/entries and updates their "options" line to have rd.vconsole.keymap=foo appended or updated if already present.Hi, >>> >>> To be honest, I really do think having the initrd rebuilt completely is a >>> better approach... but I do not think localed should be directly >>> responsible for that. >> >> As I already mentioned there are 2 issues with rebuilding the initrd: >> >> 1) It might break booting the system and, assuming we rebuild the initrd >> for all installed kernels on a locale change, then their will not be >> an older one to fallback to as there normally is, which is BAD. >> >> 2) We are moving (and in case of rpmostree based distros already shipping) >> to pre-generated (on the distros buildsys) initrds, which likely will >> also be signed. >> >> How do you propose to solve these 2 issues? > > Hmm, these are good points. I do like the idea of using a > locally-generated overlay initrd though. Ok, looking at: https://github.com/fedora-silverblue/issue-tracker/issues/3 It seems that this might be the preference of the silverblue developers too and Javier also seems to favor that, so I guess the first thing to do is to give that approach a try. I've added a comment to: https://github.com/fedora-silverblue/issue-tracker/issues/3 asking the silverblue devs to confirm that the overlay initramfs is still their preferred approach, once that is confirmed I will give this a try by manually creating on overlay initramfs and then we will see from there. Regards, Hans -- Alberto Ruiz Engineering Manager - Desktop Hardware Enablement Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hello Hans, Thanks for starting this discussion. Looking at this from a Fedora/Dracut POV, I think we should look at this as the start of implementing a configuration-only initramfs, (something Matthew Garret has been advocating for a while) rather than making this a vconsole.conf/plymouth specific solution. On Thu, Sep 26, 2019 at 12:43 PM Hans de Goede wrote: > Hi, > > On 26-09-2019 11:53, Michael Chapman wrote: > > On Thu, 26 Sep 2019, Hans de Goede wrote: > >> Hi, > >> > >> On 26-09-2019 11:10, Michael Chapman wrote: > >>> On Thu, 26 Sep 2019, Hans de Goede wrote: > >>> [...] > I believe that the best alternative is to have localed append / update > a rd.vconsole.keymap=foo argument to the kernel commandline, to > override > the vconsole.conf KEYMAP setting, but only in the initrd (so that > later > runtime changes when booted still work). > > The way I see this working is that localed does a read-modify-write of > all the BLS .conf files under /boot/loader/entries and updates their > "options" line to have rd.vconsole.keymap=foo appended or updated if > already present.Hi, > >>> > >>> To be honest, I really do think having the initrd rebuilt completely > is a > >>> better approach... but I do not think localed should be directly > >>> responsible for that. > >> > >> As I already mentioned there are 2 issues with rebuilding the initrd: > >> > >> 1) It might break booting the system and, assuming we rebuild the initrd > >> for all installed kernels on a locale change, then their will not be > >> an older one to fallback to as there normally is, which is BAD. > >> > >> 2) We are moving (and in case of rpmostree based distros already > shipping) > >> to pre-generated (on the distros buildsys) initrds, which likely will > >> also be signed. > >> > >> How do you propose to solve these 2 issues? > > > > Hmm, these are good points. I do like the idea of using a > > locally-generated overlay initrd though. > > Ok, looking at: > https://github.com/fedora-silverblue/issue-tracker/issues/3 > > It seems that this might be the preference of the silverblue > developers too and Javier also seems to favor that, so I guess > the first thing to do is to give that approach a try. > > I've added a comment to: > https://github.com/fedora-silverblue/issue-tracker/issues/3 > asking the silverblue devs to confirm that the overlay initramfs > is still their preferred approach, once that is confirmed I will > give this a try by manually creating on overlay initramfs and then > we will see from there. > > Regards, > > Hans > > -- Alberto Ruiz Engineering Manager - Desktop Hardware Enablement Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 26-09-2019 11:53, Michael Chapman wrote: On Thu, 26 Sep 2019, Hans de Goede wrote: Hi, On 26-09-2019 11:10, Michael Chapman wrote: On Thu, 26 Sep 2019, Hans de Goede wrote: [...] I believe that the best alternative is to have localed append / update a rd.vconsole.keymap=foo argument to the kernel commandline, to override the vconsole.conf KEYMAP setting, but only in the initrd (so that later runtime changes when booted still work). The way I see this working is that localed does a read-modify-write of all the BLS .conf files under /boot/loader/entries and updates their "options" line to have rd.vconsole.keymap=foo appended or updated if already present.Hi, To be honest, I really do think having the initrd rebuilt completely is a better approach... but I do not think localed should be directly responsible for that. As I already mentioned there are 2 issues with rebuilding the initrd: 1) It might break booting the system and, assuming we rebuild the initrd for all installed kernels on a locale change, then their will not be an older one to fallback to as there normally is, which is BAD. 2) We are moving (and in case of rpmostree based distros already shipping) to pre-generated (on the distros buildsys) initrds, which likely will also be signed. How do you propose to solve these 2 issues? Hmm, these are good points. I do like the idea of using a locally-generated overlay initrd though. Ok, looking at: https://github.com/fedora-silverblue/issue-tracker/issues/3 It seems that this might be the preference of the silverblue developers too and Javier also seems to favor that, so I guess the first thing to do is to give that approach a try. I've added a comment to: https://github.com/fedora-silverblue/issue-tracker/issues/3 asking the silverblue devs to confirm that the overlay initramfs is still their preferred approach, once that is confirmed I will give this a try by manually creating on overlay initramfs and then we will see from there. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Thu, 26 Sep 2019, Hans de Goede wrote: > Hi, > > On 26-09-2019 11:10, Michael Chapman wrote: > > On Thu, 26 Sep 2019, Hans de Goede wrote: > > [...] > >> I believe that the best alternative is to have localed append / update > >> a rd.vconsole.keymap=foo argument to the kernel commandline, to override > >> the vconsole.conf KEYMAP setting, but only in the initrd (so that later > >> runtime changes when booted still work). > >> > >> The way I see this working is that localed does a read-modify-write of > >> all the BLS .conf files under /boot/loader/entries and updates their > >> "options" line to have rd.vconsole.keymap=foo appended or updated if > >> already present. > > > > To be honest, I really do think having the initrd rebuilt completely is a > > better approach... but I do not think localed should be directly > > responsible for that. > > As I already mentioned there are 2 issues with rebuilding the initrd: > > 1) It might break booting the system and, assuming we rebuild the initrd > for all installed kernels on a locale change, then their will not be > an older one to fallback to as there normally is, which is BAD. > > 2) We are moving (and in case of rpmostree based distros already shipping) > to pre-generated (on the distros buildsys) initrds, which likely will > also be signed. > > How do you propose to solve these 2 issues? Hmm, these are good points. I do like the idea of using a locally-generated overlay initrd though. > > There are a lot of reasons the initrd needs to be rebuilt. Changing the > > system locale is just one of them. It seems unreasonable to have every > > tool know how to append boot parameters. > > Actually there are not that many reasons, Note that all other config info > needed for the initrd, like the rootfs UUID, which raid/lvm members to > assemble, etc. is already on the kernel commandline, so it seems logical > to put the locale (which is config info) there too and pre systemd at least > Fedora was already doing this. Perhaps I've been overly eager to rebuild the initrd on my systems when changing files under /etc. I think that's because I've seen just how much Dracut copies into the initrd, and I always get the feeling that if I forget to rebuild it something will break on the next reboot... Just to pick an example, I was fiddling around with /etc/udev/rules.d files a little while ago. I just assumed I'd need to rebuild the initrd for those. Perhaps a more common example is /etc/crypttab. That certainly needs to be in the initrd if the root filesystem is encrypted. So I guess I'm already in the habit of rebuilding the initrd when modifying config in /etc that might be needed on boot, and changing the locale wouldn't be any different. > > I would be a lot happier seeing a "well-known" binary that various things > > can call to rebuild the initrd, somewhat akin to the kernel-install we > > have already. That way distributions can plug in whatever tooling they use > > for initrds (e.g. dracut, initramfs-tools, ...) > > So maybe we need a well-known binary to update the kernel-commandline ? I think that would be useful just generally. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 26-09-2019 11:10, Michael Chapman wrote: On Thu, 26 Sep 2019, Hans de Goede wrote: [...] I believe that the best alternative is to have localed append / update a rd.vconsole.keymap=foo argument to the kernel commandline, to override the vconsole.conf KEYMAP setting, but only in the initrd (so that later runtime changes when booted still work). The way I see this working is that localed does a read-modify-write of all the BLS .conf files under /boot/loader/entries and updates their "options" line to have rd.vconsole.keymap=foo appended or updated if already present. To be honest, I really do think having the initrd rebuilt completely is a better approach... but I do not think localed should be directly responsible for that. As I already mentioned there are 2 issues with rebuilding the initrd: 1) It might break booting the system and, assuming we rebuild the initrd for all installed kernels on a locale change, then their will not be an older one to fallback to as there normally is, which is BAD. 2) We are moving (and in case of rpmostree based distros already shipping) to pre-generated (on the distros buildsys) initrds, which likely will also be signed. How do you propose to solve these 2 issues? There are a lot of reasons the initrd needs to be rebuilt. Changing the system locale is just one of them. It seems unreasonable to have every tool know how to append boot parameters. Actually there are not that many reasons, Note that all other config info needed for the initrd, like the rootfs UUID, which raid/lvm members to assemble, etc. is already on the kernel commandline, so it seems logical to put the locale (which is config info) there too and pre systemd at least Fedora was already doing this. I would be a lot happier seeing a "well-known" binary that various things can call to rebuild the initrd, somewhat akin to the kernel-install we have already. That way distributions can plug in whatever tooling they use for initrds (e.g. dracut, initramfs-tools, ...) So maybe we need a well-known binary to update the kernel-commandline ? Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Thu, 26 Sep 2019, Hans de Goede wrote: [...] > I believe that the best alternative is to have localed append / update > a rd.vconsole.keymap=foo argument to the kernel commandline, to override > the vconsole.conf KEYMAP setting, but only in the initrd (so that later > runtime changes when booted still work). > > The way I see this working is that localed does a read-modify-write of > all the BLS .conf files under /boot/loader/entries and updates their > "options" line to have rd.vconsole.keymap=foo appended or updated if > already present. To be honest, I really do think having the initrd rebuilt completely is a better approach... but I do not think localed should be directly responsible for that. There are a lot of reasons the initrd needs to be rebuilt. Changing the system locale is just one of them. It seems unreasonable to have every tool know how to append boot parameters. I would be a lot happier seeing a "well-known" binary that various things can call to rebuild the initrd, somewhat akin to the kernel-install we have already. That way distributions can plug in whatever tooling they use for initrds (e.g. dracut, initramfs-tools, ...) Perhaps even just a new kernel-install verb, e.g: kernel-install refresh KERNEL-VERSION [KERNEL-IMAGE] ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hello Hans, On 9/25/19 4:50 PM, Hans de Goede wrote: > Hi all, > > Currently, at least in Fedora, but I do not believe that this problem is > unique to Fedora, there are 2 problems with keymap handling in the initrd. > > 1: If the keymap in vconsole.conf is changed then this does not apply to the > initrd without rebuilding it. This means that any changes are only applied > after installing a new kernel > This has been reported a long time ago > https://bugzilla.redhat.com/show_bug.cgi?id=1405539 > and is also listed on the list of Fedora high prio bugs: > > https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues > > 2: With silverblue, which ships with a generic pre-generated initrd we end up > with always using the keymap as defined when building the initrd on the > buildsys (KEYMAP=us), also see: > https://github.com/fedora-silverblue/issue-tracker/issues/3 > > Now arguably 1. could be fixed by regenerating the initrd, but that is tricky, > because if some component has changed on the system since the last time the > initrd was generated this will change more then just the embedded > vconsole.conf > possibly stopping the system from booting (this should never happen, but > in reality this is a real risk). > > Also do we want localed to trigger initrd rebuilds? And if we do not want > that, then should tools calling the localed DBUS API do this? > If all the tools need to do that then it seems to me that the API is > incomplete / not fully functional, so that seems undesirable. > > And for 2. we really do not want to rebuild the initrd ever, and for the > "normal" distro case at least for Fedora we also want to move to > pre-generated initrds so that we can sign them, etc. > > TL;DR: IMHO regenerating the initrd is not the answer here. > > I believe that the best alternative is to have localed append / update > a rd.vconsole.keymap=foo argument to the kernel commandline, to override > the vconsole.conf KEYMAP setting, but only in the initrd (so that later > runtime changes when booted still work). > > The way I see this working is that localed does a read-modify-write of > all the BLS .conf files under /boot/loader/entries and updates their > "options" line to have rd.vconsole.keymap=foo appended or updated if > already present. > And probably you will need to add the same for all the vconsole.* options. > I'm willing to write localed patches implementing this (targetting Fedora 32) > but before I spend time on this, it would be good to have consensus that > this is the best way to handle this. Note I'm open to other suggestions. > Another approach could be to make localed generate an initrd that contains an /etc/vconsole.conf, and overlay this to the main initrd. That way changing the keymap won't require updating the kernel commandline for all the boot entries. The disadvantage would be that passing multiple initrds isn't supported by neither petitboot nor zipl. But I guess this is less of an issue for s390x and ppc64le, so in those architectures localed can be started without the option that tells to generate an overlay initrd when changing the keymap. > Regards, > > Hans > Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi all, Currently, at least in Fedora, but I do not believe that this problem is unique to Fedora, there are 2 problems with keymap handling in the initrd. 1: If the keymap in vconsole.conf is changed then this does not apply to the initrd without rebuilding it. This means that any changes are only applied after installing a new kernel This has been reported a long time ago https://bugzilla.redhat.com/show_bug.cgi?id=1405539 and is also listed on the list of Fedora high prio bugs: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues 2: With silverblue, which ships with a generic pre-generated initrd we end up with always using the keymap as defined when building the initrd on the buildsys (KEYMAP=us), also see: https://github.com/fedora-silverblue/issue-tracker/issues/3 Now arguably 1. could be fixed by regenerating the initrd, but that is tricky, because if some component has changed on the system since the last time the initrd was generated this will change more then just the embedded vconsole.conf possibly stopping the system from booting (this should never happen, but in reality this is a real risk). Also do we want localed to trigger initrd rebuilds? And if we do not want that, then should tools calling the localed DBUS API do this? If all the tools need to do that then it seems to me that the API is incomplete / not fully functional, so that seems undesirable. And for 2. we really do not want to rebuild the initrd ever, and for the "normal" distro case at least for Fedora we also want to move to pre-generated initrds so that we can sign them, etc. TL;DR: IMHO regenerating the initrd is not the answer here. I believe that the best alternative is to have localed append / update a rd.vconsole.keymap=foo argument to the kernel commandline, to override the vconsole.conf KEYMAP setting, but only in the initrd (so that later runtime changes when booted still work). The way I see this working is that localed does a read-modify-write of all the BLS .conf files under /boot/loader/entries and updates their "options" line to have rd.vconsole.keymap=foo appended or updated if already present. I'm willing to write localed patches implementing this (targetting Fedora 32) but before I spend time on this, it would be good to have consensus that this is the best way to handle this. Note I'm open to other suggestions. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
