Re: [RFD] match kernel and modules at run time

[Daniel Kiper]

On Sat, Oct 29, 2016 at 09:54:24AM +0300, Andrei Borzenkov wrote:
> Distributions are usually using some distro-specific means to record
> bootloader location for future updates (like debconf,
> /etc/default/grub_installdevice or similar). Unfortunately those means
> are not widely known; but it is very easy to hit Internet post that
> recommends "grub-install /dev/sda" as ultimate grub repair tool.
>
> The problem is that this will work ... until next grub update. Then -
> depending on bootloader location recorded in distro configuration
> database - core.img used for booting starts to diverge from modules in
> /boot/grub. With unpredictable effects.

Hmmm... IIRC, modules are always updated when install happens. If it
is true then this should not be a problem. Am I right?

> Last confirmed example is here:
>
> https://forums.opensuse.org/showthread.php/520709-Opensuse-13-2-Howto-set-password-for-single-user-mode-in-grub2?p=2797852#post2797852

AIUI, this is more about password issue...

> Anyone thinks this is a problem (I obviously do)?

I agree to some extent.

> I see several possible steps to mitigate it.
>
> 1. Define grub install locations in /etc/default/grub and use them by
> grub-install. This way distributions can converge on using it, which
> makes grub-install more safe.

I think that we should store default install options there too. Then if
somebody calls grub-install without arguments it should get all config
data from /etc/default/grub. Otherwise it should care about command
line arguments.

> Cons - users will still hit Internet articles that recommend explicit
> device names years from now.

IMO, we should not care a lot about that.

> 2. Use some form of checksum and verify it during module load. Similar
> to what Linux kernel does.
>
> Pros - guarantees that module built for different kernel will fail to
> load, making it obvious instead of crashing in unpredictable way later.

We should have two options: fail or warn.

> Cons - likely increases core size; and platform most susceptible to this
> issue is also one most sensitive to core size.

Why? I have a feeling that we have some hashing functions there. Additionally,
I think that we can store hashes in modules. They should be generated using
version number (or something like that; core.img hash?) stored in core.img and
contents of a given module. Does it make sense in general? Of course the details
should be worked out. Or stolen from somewhere... ;-))) Linux?

> 3. Variant of 3 - generate single random number on every build.
>
> Cons - reproducible builds; will block module loading even if they are
> binary compatible.

No, please, this way we would not be able, or at least it would be
complicated, to rebuild the same binary version.

Daniel