On 26.11.2013 16:48, Jonathan McCune wrote:
> > This redundancy may be cumbersome if attempting
> > +to cryptographically validate the contents of the bootloader
> embedding
> > +area, or in more modern systems with GPT-style partition tables
> > +(@pxref{BIOS installation}) where GRUB does not reside in any
> > +unpartitioned space outside of the MBR. Disable the Reed-Solomon
> What's the reasonning behind GPT part?
>
>
> I looked at these archived threads discussing the reasoning behind
> including RS codes in the first place:
> http://lists.gnu.org/archive/html/grub-devel/2010-09/msg00218.html
> http://lists.gnu.org/archive/html/grub-devel/2010-09/msg00205.html
> ... and the motivation appeared to prioritize tolerating bad behavior
> from proprietary software over actual disk errors. I'm not aware of
> weird proprietary software stealing blocks from a GPT BIOS boot partition.
>
Perhaps we should contact Adobe to ask for an upgrade...
> Sure, changed in v3. I left the actual option as --no-rs-codes, and it
> changes an option variable from its default of 1 to 0.
>
Yes, that's what I meant.
> Okay, added __attribute__ ((unused)) and a comment where it gets passed
> a 0 on sparc64. The way setup.c is written it would be more invasive to
> actually drop the parameter.
>
Ok.
>
> Okay, dropped. Not sure if the way I #defined a NO_RS_CODES_KEY -1 is
> the right way to do an option with no short form.
>
No, it should be enum and start at 0x100
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
