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

[Jonathan McCune]

On Sat, Nov 2, 2013 at 8:33 PM, Richard Laager <address@hidden> wrote:

I'm not at all familiar with this part of GRUB, so take this with a big
grain of salt.

Thanks for taking the time.

 

On Sat, 2013-11-02 at 20:05 -0700, Jonathan McCune wrote:
> I think it should be possible to generate all the necessary signatures
> at *build time* instead of *install time*

If I understand your email correctly, you're saying that at build time,
grub builds core.img. Then at install time, it calculates:
  "core.img.rs" = Reed-Solomon(core.img)
Then it writes the "core.img.rs" data to disk. At boot time, GRUB reads
the "core.img.rs" data from disk, corrects errors, to reproduce
core.img, which is executed.

Yes, this is consistent with my current understanding.

 

If you want to verify at boot time, you just do it after the error
correction step.

This causes the problem to recurse, requiring something (e.g., Coreboot) to first verify the error-correcting software, and then something (presumably either a smarter initial something, or another feature of the error-correcting software) to verify the corrected GRUB.  I don't think GRUB is could support this very easily, and it's my opinion that changing it to do so would not be worth the effort.

 

But it sounds like you want to verify the bits on disk
from the host environment.

I think a simple, transparent verification scheme should enable verification from at least 3 places: build environment, host environment, and whatever-is-checking-GRUB-at-boot-time.  The security arguments for these various environments are subtle and complicated, but it's hard to have confidence in something that is difficult to test and peak inside.

 

Rather than "backing out" the Reed-Solomon
coding, why not do it the other way around? Verify core.img, then
re-encode the known good copy (for which code already exists as part of
the installation procedure) and then just compare that to what is
actually on disk?

This is feasible, but seems unnecessarily complicated.  Given that the RS codes are adding limited value in the case of trying to achieve a verified boot, I thought it better to just add an option to leave them out.

-Jon