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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
