Re: Make systemd-localed modify the kernel commandline for the initrd keymap?

[Lennart Poettering <mzxreary@xxxxxxxxxxx>]

On Fr, 27.09.19 16:00, Hans de Goede (hdegoede@xxxxxxxxxx) wrote:

> Well until we make sure nothing ever writes outside of the user
> homedir security conscious users will likely still want to use

I am pretty sure the security conscious users should not run an OS
that writes user stuff all over the place, but only does so into
$HOME.

> full-disk encryption and there is also plenty of hw which Fedora
> supports which does not have a TPM2

Well, hw with fewer functions gets less functionality, and I am sure
this is not surprising to most users.

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

Uhm, so given we lived with this issue for so long, and given it's
easy to fix on EFI in a clean and elegant way, don't you thinkg that
it wouldn't be acceptable to fix it for EFI only for now? I mean,
people who run fedora *desktops* on non-EFI hw are probably a small
enough number of people to allow this to remain unfixed a bit longer?

Who are you designing this for anyway? I mean, isn't Fedora dropping
i386 support even these days, so that in particular the Fedora
*desktop* becomes an x86-64 only thing (and thus an EFI-only thing).

Anyway, even if you insist that the Fedora desktop should care about
non-EFI, which I can accept, isn't the lesson to learn to add some
concept like EFI vars to those archs too? i.e. apparently OSes and
boot loaders want to communicate, so why not make that happen on those
archs too? I mean, the concept of EFI vars is simple and semantically
it's not even essential to have NVRAM to store them in — a fact to
which the EFI firmware typically used by qemu/kvm is document, as it
actually stores those EFI vars in the ESP, so that they are included
in the VM image.

i.e maybe write down a spec, that declares how to store settings
shared between host OS, boot loader and early-boot kernel environment
on systems that have no EFI NVRAM, and then we can make use of
that. i.e. come up with semantics inspired by the boot loader spec for
finding the boot partition to use, then define a couple of files in
there for these params.

In fact, sd-boot nowadays stores the boot-time random seed it manages
to initialize the kernel's entropy pool with in
$BOOT/loader/random-seed. It would only be natural to build on that,
and introduce $BOOT/loader/kbdmap and so on.

i.e. generating initrd images with cpio and so on is hacky, gluey,
Linux-specific. If you just use plain simple, standardized config
files at clearly defined locations, then reading and writing them is
simple, they can be shared between all players, are not Linux specific
and so on. I think systemd could certainly commit to updating those
files then.

Putting together such a spec isn't difficult even. Could be as short
as:

        "This spec builds on the boot loader spec. The keyboard map is
        stored in $BOOT/loader/kbdmap, using ISO-3166-1 alpha-2
        country codes. We suggest boot loaders use this for their own
        key maps, and pass it to the OS, for example via the kernel
        command line."

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel