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

[Lennart Poettering]

On Fr, 27.09.19 16:16, Hans de Goede (hdegoede at redhat.com) wrote:

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

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