<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 12:50 PM Lennart Poettering <<a href="mailto:mzerqung@0pointer.de">mzerqung@0pointer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mi, 25.09.19 16:50, Hans de Goede (<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>) wrote:<br>
<br>
> Hi all,<br>
><br>
> Currently, at least in Fedora, but I do not believe that this problem is<br>
> unique to Fedora, there are 2 problems with keymap handling in the<br>
> initrd.<br>
<br>
Hmm, why do you need a correct initrd in the early boot? I can see two<br>
reasons:<br>
<br>
1. full disk encryption with the user typing in the password on the<br>
   kbd. But isn't the answer to this to link the root OS to the tpm<br>
   instead, and use user-keyed crypto only for $HOME? The OS itself<br>
   doesn't need to be protected after all, everbody should have the<br>
   same files there anyway, it's $HOME that needs protection.<br></blockquote><div><br></div><div>Some counterarguments here:<br>- The TPM does not protect you from someone stealing your entire laptop and booting from external media,</div><div>- There are plenty of systems out there without a TPM module that Fedora cares about<br></div><div>- A key password entry is still a fallback if your motherboard gets fried and you move your hardrive to a new laptop.</div><div>- /var may contain pretty sensitive data these days too (SSSD caches, libvirt system wide vms, docker images...).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. debugging in the initrd. Does this really matter though? Aren't<br>
   people who can usefully debug the initrd also smart enough to load the<br>
   kbd mappings themselves (or work with american keybindings for a bit)?<br>
<br>
Aren't you making something here a problem that actually doesn't<br>
matter much?<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
That said, if it is worth fixing this, why stop at the initrd here,<br>
shouldn't the bootloader get right keymaps too? After all, most boot<br>
loaders I know have a line editor...<br>
<br>
Which hence raises the question: isn't this something the boot loader<br>
should manage initially, and then just pass to the kernel/initrd?<br>
i.e. on EFI systems, shouldn't this just be an efi var, that the boot<br>
ldr can read, and then pass on to the kernel (or alternatively, read<br>
by the initrd?) Alternatively, if you care about non-EFI, isn't this<br>
also something you want to tell the boot ldr about, and then have the<br>
boot loader pass to the kernel, maybe via a struct boot_param entry?<br>
(or simply by appending something to the kernel cmdline if that<br>
doesn't fly).<br></blockquote><div><br></div><div>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.<br><br></div><div>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).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> TL;DR: IMHO regenerating the initrd is not the answer here.<br>
<br>
Yeah, leave the initrd alone, it should be immutable outside of kernel<br>
updates, I am sure.<br>
<br>
> I'm willing to write localed patches implementing this (targetting Fedora 32)<br>
> but before I spend time on this, it would be good to have consensus that<br>
> this is the best way to handle this. Note I'm open to other suggestions.<br>
<br>
I'd be happy to merge patches that just use an EFI variable for this,<br>
so that boot loader, initrd and GNOME can all make use of this.<br></blockquote><div><br></div><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>Alberto Ruiz<br></div>Engineering Manager - Desktop Hardware Enablement<br></div>Red Hat<br></div></div></div></div></div></div></div></div></div>