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

[Alberto Ruiz]

On Fri, Sep 27, 2019 at 12:50 PM Lennart Poettering <mzerqung at 0pointer.de>
wrote:

> On Mi, 25.09.19 16:50, Hans de Goede (hdegoede at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190927/c5c88f83/attachment.html>