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

[Andrei Borzenkov]

Отправлено с iPhone

>> 2 нояб. 2016 г., в 18:31, Daniel Kiper <address@hidden> написал(а):
>>
>> 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?

Originally core.img is written to sda1 and modules to /boot/grub. They
match. Then user runs grub-install /dev/sda - they still match. Now
grub package is updated and package scripts write new core.img to sda1
and new modules to /boot/grub. They do not match /dev/sda anymore -
but for booting core.img from /dev/sda is used. And this is not
updated.


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

Wrong link, sorry. Here is the right one

https://forums.opensuse.org/showthread.php/520421-Grub-throwing-a-quot-error-no-symbol-table-quot?p=2797849#post2797849

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

This needs extra code to match hashes; this needs storing hashes
somewhere, probably both in modules and in core.img. All of this adds
up to size, which is already very tight to 32K limit for legacy MBR
layout even with the most basic requirements (no layered storage, ext2
as /boot/grub).

> 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