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

[Daniel Kiper]

On Thu, Nov 03, 2016 at 05:20:41PM +0300, Andrei Borzenkov wrote:
> ???????????????????? ?? 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.

Ahhh... Right, I have not thought about that.

[...]

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

Yep, however, in worst case we can use CRC-something.

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

Wait, it looks that it could be simpler. During install we calculate
core.img hash and put it into every module and core.img. Then during
load we compare hash stored in core.img and loaded module. In this
situation we do not need a lot of extra code and data in core.img.
Does it make sense?

Daniel