From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH v2] Support to disable reed-solomon codes
Date: Tue, 26 Nov 2013 17:09:09 +0100 [thread overview]
Message-ID: <5294C7A5.1070401@gmail.com> (raw)
In-Reply-To: <CADtfRCU10SfFWM-6MgpAMdqGaoC9jHAOKQ2MR80xdc7ioCM_HA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
prev parent reply other threads:[~2013-11-26 16:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 22:37 [PATCH v2] Support to disable reed-solomon codes Jon McCune
2013-11-26 0:47 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-26 15:48 ` Jonathan McCune
2013-11-26 16:09 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5294C7A5.1070401@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.