Re: [PATCH v0] Support to disable reed-solomon codes

[Jonathan McCune <jonmccune@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

On Fri, Nov 1, 2013 at 8:13 PM, Andrey Borzenkov <arvidjaar@gmail.com>wrote:

> В Fri,  1 Nov 2013 17:04:00 -0700
> Jon McCune <jonmccune@google.com> пишет:
>
> >  * new grub-*-setup flag to disable insertion of reed solomon codes
> >  * grub-install support for option --no-rs-codes
>
> What problem does it solve?


A simple motivation is the desire to run the bare minimum amount of code
required to boot a machine.

However, the high-level problem I'm trying to address is to make the binary
part of GRUB (core.img + boot.img or similar) easier to verify
cryptographically.

First, if a hash or signature checks out, then the bits are known to be
correct and there's no need for the redundancy of the RS codes.

Second, I am not a fan of verification mechanisms that require "just
install it, then look at what is installed and assume it is correct, and
then sign that."  I think it should be possible to generate all the
necessary signatures at *build time* instead of *install time* (modulo
knowledge of the install target's partition table layout), to eliminate any
target-specific configuration weirdness that's not accounted for at build
time.

I think it also helps to think about this problem by working backwards.
 Build GRUB on machine A, and install it on machine B (assume same
architecture everywhere, but it doesn't really matter).  Given the contents
of B's disk (e.g., MBR + contents of embedding area), and the build output
of A, how do we know if machine B indeed has all the right bits installed?

It's not too hard to run the same grub-mkimage command everywhere so as to
generate a consistent core.img (and whatever .img makes sense for the MBR)
doing the verification, and it's not too hard to take knowledge of B's
partition table layout to make the necessary changes to those .img files.
But, the reed-solomon codes that util/setup.c adds into the embedding area
are yet another step that would need to be backed out.

This patch just adds a flag. :)

Thanks,
-Jon

[-- Attachment #2: Type: text/html, Size: 2780 bytes --]