Re: Make systemd-localed modify the kernel commandline for the initrd keymap?

[Lennart Poettering <mzerqung@xxxxxxxxxxx>]

On Fr, 27.09.19 10:20, Hans de Goede (hdegoede@xxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel