From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vd6be-0000YX-Tc for mharc-grub-devel@gnu.org; Sun, 03 Nov 2013 17:57:18 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vd6bb-0000Y8-VR for grub-devel@gnu.org; Sun, 03 Nov 2013 17:57:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vd6ba-0007yD-Kq for grub-devel@gnu.org; Sun, 03 Nov 2013 17:57:15 -0500 Received: from mail-ie0-x22d.google.com ([2607:f8b0:4001:c03::22d]:46481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vd6ba-0007y6-CX for grub-devel@gnu.org; Sun, 03 Nov 2013 17:57:14 -0500 Received: by mail-ie0-f173.google.com with SMTP id u16so11407577iet.32 for ; Sun, 03 Nov 2013 14:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+/bhCVhojeUKOYgH4QQDgj0oWzVXZnwbLCeq3GZtiJc=; b=NM6xkje/7/bpXRoq7Z/pHx0uEidd2OkZu/v7urBosngy7BMzOmcnRmn75HLS/8i2rs L1yo026I+p36OLEF5MzjxMmvCZE7rier1P0iIrIs2F7Z65UB+6cnJhrkM2d95VcF9rKK hiAX8TEb3g+419Yb+Cic+LqQIUx+jM2MFuR83tjZ9d1/4Wq+BmV75jOrnpHVAgRDXnGS 2Y6d+y681wF4yeoMxkla5VWoDcmP89R6LVQ0wd8ud2K4jBW3VSffc99v2fx/03ZOwbjx TIoMtyW1y7Fy77HVBo9HHnj7GzZBM9ocG1DH4+cz5HcPWWiNF7QrxVgxAheAmFf+NeyV pCzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+/bhCVhojeUKOYgH4QQDgj0oWzVXZnwbLCeq3GZtiJc=; b=GaMfZjFCdhwtv3z0abdJTRWWh2Hl6Ru6Apc5ItCamSp2jV0Ycp+PiWf7u8/34/8d63 Dt6nBRgYFKtqcAh/StrFs33wOWVcz7363jQwjuWPDR4TXiyqh6QB/axqxiTXkZTSJtR1 tsjolVQOdra+70Y5l2qF36GK5O9HQfz1FTI5qLy0483GMpNi9l4wWf9LUPCImdZKtYgO 9/FBl5kgLyaFf0rRsPYMxvJqoxlmDA77Z7AJOrvjpGA4huP/vZSxRLicunvajJXTMfsG aZk9woq8fAM1BYngx2rc9NVa6FMhRpNURPBO6sON0Ke/3JM3Xg6/c3TFbhdOcolZO252 Idlw== X-Gm-Message-State: ALoCoQl1HNmzeZF/0OvWp1hl2he3m1+rLFv4yMuVurxmo/lNVk/UA6jeMF6UPjsbpHxeBPqxY2JX/ZLxRF5UgfAYV8NiHV66zwz4eJxD6BQtuu0gnjwfUsW0M4Jrc8x3MLjSLuyRcD4eW5W3sjN8FkyFJIvu7EjC0IiB9paaMt1AuQPm7LBcmKhRk3NDSiwiNKfxg/Lrlc3/ MIME-Version: 1.0 X-Received: by 10.50.27.102 with SMTP id s6mr9614379igg.7.1383519432984; Sun, 03 Nov 2013 14:57:12 -0800 (PST) Received: by 10.64.232.9 with HTTP; Sun, 3 Nov 2013 14:57:12 -0800 (PST) In-Reply-To: <1383449636.2867.111.camel@watermelon.coderich.net> References: <1383350640-13907-1-git-send-email-jonmccune@google.com> <20131102071336.7cff1833@opensuse.site> <1383449636.2867.111.camel@watermelon.coderich.net> Date: Sun, 3 Nov 2013 14:57:12 -0800 Message-ID: Subject: Re: [PATCH v0] Support to disable reed-solomon codes From: Jonathan McCune To: Richard Laager Content-Type: multipart/alternative; boundary=047d7b10d01557e29004ea4db842 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22d Cc: The development of GNU GRUB 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: Sun, 03 Nov 2013 22:57:17 -0000 --047d7b10d01557e29004ea4db842 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 2, 2013 at 8:33 PM, Richard Laager 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 --047d7b10d01557e29004ea4db842 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= at, Nov 2, 2013 at 8:33 PM, Richard Laager <rlaager@wiktel.com> wrote:
I'm not at all familiar with this part o= f GRUB, so take this with a big
grain of salt.

Thanks for taking the time.<= /div>
=A0
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:
=A0 "core.img.rs&= quot; =3D Reed-Solomon(core.img)
Then it writes the "c= ore.img.rs" data to disk. At boot time, GRUB reads
the "core.img.rs&= quot; data from disk, corrects errors, to reproduce
core.img, which is executed.

Yes, this = is consistent with my current understanding.
=A0
If you want to verify at boot time, you just do it after the error
correction step.

This causes the problem t= o recurse, requiring something (e.g., Coreboot) to first verify the error-c= orrecting software, and then something (presumably either a smarter initial= something, or another feature of the error-correcting software) to verify = the corrected GRUB. =A0I don't think GRUB is could support this very ea= sily, and it's my opinion that changing it to do so would not be worth = the effort.
=A0
But it sounds like you want to= verify the bits on disk
from the host environment.

I think a simpl= e, transparent verification scheme should enable verification from at least= 3 places: build environment, host environment, and whatever-is-checking-GR= UB-at-boot-time. =A0The security arguments for these various environments a= re subtle and complicated, but it's hard to have confidence in somethin= g that is difficult to test and peak inside.
=A0
Rather than "backing out&= quot; 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. =A0Given that the RS codes are adding lim= ited value in the case of trying to achieve a verified boot, I thought it b= etter to just add an option to leave them out.

-Jon

--047d7b10d01557e29004ea4db842--