[systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?

[Hans de Goede]

Hi,

On 9/27/19 1:59 PM, Lennart Poettering wrote:
> On Fr, 27.09.19 10:20, Hans de Goede (hdegoede at redhat.com) wrote:
<snip>

>> "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.

<snip>

> 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