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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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