On Fri, Sep 27, 2019 at 12:50 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
On Mi, 25.09.19 16:50, Hans de Goede (hdegoede@xxxxxxxxxx) 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,
- 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_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
