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

[Hans de Goede]

Hi,

On 9/27/19 1:49 PM, Lennart Poettering 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. 

Ack that is the main use-case for this.

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

Well until we make sure nothing ever writes outside of the user
homedir security conscious users will likely still want to use
full-disk encryption and there is also plenty of hw which Fedora
supports which does not have a TPM2

> 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)?

I agree that this is a non-issue.

> 
> Aren't you making something here a problem that actually doesn't
> matter much?

We have a bug open for this for a long long time and it is even listed on:
https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues

> That said, if it is worth fixing this,

I think it is safe to say that the people involved from the Fedora
side have decided it is indeed 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...

That is a very interesting point, on one hand using the bootloader
line-editor sort of matches your dracut-debug scenario, IOW not
so important to fix.

OTOH I agree that if we are looking into fixing the kbd layout
for the initrd it would be interesting to see if we can also fix
it for the bootloader.

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

We definitely care about non EFI and we care about a scala on
bootloaders, modifying them all for this really does not scale,
so I believe we really need a solution outside of the bootloader
and parallel to that we can think about also passing this info
to the bootloader somehow.

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

I know you love EFI variables and I understand why you do, but
unfortunately there are still e.g. a lot of 64 bit core2 duo laptops
and desktops which still run fine and are still being used, so
we still need to support legacy BIOS for those and there are
also other more exotic platforms which do not have EFI.

TL;DR: we do not live in an EFI only world, so using EFI is
not the answer.

Regards,

Hans