From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VlLCh-0007P9-2p for mharc-grub-devel@gnu.org; Tue, 26 Nov 2013 11:09:35 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlLCZ-0007H3-GA for grub-devel@gnu.org; Tue, 26 Nov 2013 11:09:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlLCS-0006UB-80 for grub-devel@gnu.org; Tue, 26 Nov 2013 11:09:27 -0500 Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]:59601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlLCS-0006U6-1u for grub-devel@gnu.org; Tue, 26 Nov 2013 11:09:20 -0500 Received: by mail-ea0-f177.google.com with SMTP id n15so3713778ead.36 for ; Tue, 26 Nov 2013 08:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=WmiQQeamtBKGAqYAC/Tq/tO4EA6V/91MaJ+jhirNNRM=; b=SJMzFQb7DtWHAl319NuT+m6b/xlEsghFsh2IBRdDoDQCwmK/3mfESI0NjnF232GrYw E7BI7W+OB6jUkhUCNY1FcQ8bjE8IuTa8t5x5mZw3FTxbT+SZlTIj9F9/OpZtyAnAsGFP 9r2OX4qyjq2miOhIMCbYl7G5mvP/GTTuWIGeys6veVtj9qXCwxqLdcOVpPiuieBnu3x2 4XxRwesjL/NOtyKnsH3rK+DRwMpJeIhghANrQp4GRZZHnJa7PWcZh0hkoVD50n3XSQ34 hfpwZmscM2glbXcwhtlG0hQAaH1hKMXX3/cVyNJTRY1ulYh6XpKSD76XCLtlv5c5p5pn 4/EA== X-Received: by 10.14.199.1 with SMTP id w1mr41166775een.29.1385482159310; Tue, 26 Nov 2013 08:09:19 -0800 (PST) Received: from [192.168.1.121] (31-249.1-85.cust.bluewin.ch. [85.1.249.31]) by mx.google.com with ESMTPSA id o47sm10318598eem.21.2013.11.26.08.09.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 08:09:18 -0800 (PST) Message-ID: <5294C7A5.1070401@gmail.com> Date: Tue, 26 Nov 2013 17:09:09 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [PATCH v2] Support to disable reed-solomon codes References: <1385419038-23566-1-git-send-email-jonmccune@google.com> <5293EFA7.2000002@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2TRUVLKWJNMTCRKRFBXPW" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::231 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 16:09:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TRUVLKWJNMTCRKRFBXPW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-Solomo= n > What's the reasonning behind GPT part? >=20 >=20 > 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 partiti= on. > =20 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. > =20 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 t= o > actually drop the parameter. > =20 Ok. >=20 > 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. > =20 No, it should be enum and start at 0x100 ------enig2TRUVLKWJNMTCRKRFBXPW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlKUx60ACgkQmBXlbbo5nOs5QQD9HHXezw0SvUCOD068ADQ1irPI SoIRGRYgWss03CrfSNQA/j9IamP8yVQBXPJliJYdoN8B75q0aawl0dLzkQ4OhTIc =qUKw -----END PGP SIGNATURE----- ------enig2TRUVLKWJNMTCRKRFBXPW--