From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vco0U-0007D5-3e for mharc-grub-devel@gnu.org; Sat, 02 Nov 2013 23:05:42 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vco0R-0007Cx-TF for grub-devel@gnu.org; Sat, 02 Nov 2013 23:05:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vco0Q-0003ta-Mv for grub-devel@gnu.org; Sat, 02 Nov 2013 23:05:39 -0400 Received: from mail-ie0-x232.google.com ([2607:f8b0:4001:c03::232]:56170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vco0Q-0003tR-8n for grub-devel@gnu.org; Sat, 02 Nov 2013 23:05:38 -0400 Received: by mail-ie0-f178.google.com with SMTP id x13so10141043ief.37 for ; Sat, 02 Nov 2013 20:05:36 -0700 (PDT) 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 :content-type; bh=LBR4MqTyP+C+qDzPxJ2Xf3B3kYaq+l6UM7aEEm98g18=; b=c0+LeDGhOjgGJJ7DatcRyNqE6YeJUtDBnoSMRwyibBfvQ7eUdX3uWBIUmCa3GUwmg+ eoNYV9NrFT9rSDrH/Klxok1XFsuc6ymvIlvB1mDyADylv7etncL6fYfSWFnIUgv7eKzn xvR26EEYyxTDu/71o2mFVeQb6ElJoYqwmLd9l/U6KpVUHnB1fYHLuRcOlECfJNsXwOcr eh33LZj56x/GXFtmvXAn8+Uhfh+QR6i246ASHcTvDE2xXzOs4HQ4COg7LeXOFb4nT0Nh gzU7GgO7clC6XAzLW28pAOM+YK5JyLAYmPAp/yqgNvNhEjl0/ZqxiCJgpIKLPv0UmHB3 2sEA== 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:content-type; bh=LBR4MqTyP+C+qDzPxJ2Xf3B3kYaq+l6UM7aEEm98g18=; b=NzFQOVWoDpeLt/E6ZZYp+HnpfC31T7dZhljinjmHJl4a9u1SewlCIKpZVtqQ2pATSi i/0ZiKJjIF7kGlv/zePDNL6fzzDZvalfi61iMy0Op4NP1mu/TXyaP2c3qseuQryg5I9B TL6l7OLgF0ry5qESinh14ZFtPKpc5A2yFe9YC0GdcUhFq4OfM2iJQCg6RCR3G4eXoCos vDaZzQ4nCLkG1KqT25wphiO+/H6TpalTCZ8WeAGef2TXhZ9gxnEjWei4bVAkeRFKEwRN Fanwo8kObT4Gn9+Hg0cKaU1uXboEZTsRYolg5z1HRP82VtlLp8Z2ahXn+0ZxPLv0zYyz q+TQ== X-Gm-Message-State: ALoCoQlDoOtVjrSZZaJrDZYGhddjtmHYJ54P/jibLX5fbW31kykCe5UC7e9BuJeBxW/IFlbC6I8o36ZbM3OT9LOy1nvHZAnwkXoOLCdeUZztQQgslNco5ngtGSaLByUfDHQiLviXKDUXM7TBc1TPhcB43BnVWxyXRawV2ejpnOYcSqwRAtGyTok0b+fERVzR3C5POJUrVyqe MIME-Version: 1.0 X-Received: by 10.50.13.104 with SMTP id g8mr7667511igc.30.1383447936076; Sat, 02 Nov 2013 20:05:36 -0700 (PDT) Received: by 10.64.232.9 with HTTP; Sat, 2 Nov 2013 20:05:35 -0700 (PDT) In-Reply-To: <20131102071336.7cff1833@opensuse.site> References: <1383350640-13907-1-git-send-email-jonmccune@google.com> <20131102071336.7cff1833@opensuse.site> Date: Sat, 2 Nov 2013 20:05:35 -0700 Message-ID: Subject: Re: [PATCH v0] Support to disable reed-solomon codes From: Jonathan McCune To: The development of GNU GRUB Content-Type: multipart/alternative; boundary=089e013c69c6cbb56d04ea3d12a5 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::232 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 03:05:41 -0000 --089e013c69c6cbb56d04ea3d12a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 1, 2013 at 8:13 PM, Andrey Borzenkov wrote= : > =D0=92 Fri, 1 Nov 2013 17:04:00 -0700 > Jon McCune =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > * new grub-*-setup flag to disable insertion of reed solomon codes > > * grub-install support for option --no-rs-codes > > What problem does it solve? A simple motivation is the desire to run the bare minimum amount of code required to boot a machine. However, the high-level problem I'm trying to address is to make the binary part of GRUB (core.img + boot.img or similar) easier to verify cryptographically. First, if a hash or signature checks out, then the bits are known to be correct and there's no need for the redundancy of the RS codes. Second, I am not a fan of verification mechanisms that require "just install it, then look at what is installed and assume it is correct, and then sign that." I think it should be possible to generate all the necessary signatures at *build time* instead of *install time* (modulo knowledge of the install target's partition table layout), to eliminate any target-specific configuration weirdness that's not accounted for at build time. I think it also helps to think about this problem by working backwards. Build GRUB on machine A, and install it on machine B (assume same architecture everywhere, but it doesn't really matter). Given the contents of B's disk (e.g., MBR + contents of embedding area), and the build output of A, how do we know if machine B indeed has all the right bits installed? It's not too hard to run the same grub-mkimage command everywhere so as to generate a consistent core.img (and whatever .img makes sense for the MBR) doing the verification, and it's not too hard to take knowledge of B's partition table layout to make the necessary changes to those .img files. But, the reed-solomon codes that util/setup.c adds into the embedding area are yet another step that would need to be backed out. This patch just adds a flag. :) Thanks, -Jon --089e013c69c6cbb56d04ea3d12a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 1, 2013 at 8:13 PM, Andrey Borzenkov <arvidjaar@gmail.com&g= t; wrote:
=D0=92 Fri, =C2=A01 Nov 2013 17:04:00 -0700
Jon McCune <jonmccune@google.com= > =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

> =C2=A0* new grub-*-setup flag to disable insertion of reed solomon cod= es
> =C2=A0* grub-install support for option --no-rs-codes

What problem does it solve?

A si= mple motivation is the desire to run the bare minimum amount of code requir= ed to boot a machine.

However, the high-= level problem I'm trying to address is to make the binary part of GRUB = (core.img + boot.img or similar) easier to verify cryptographically. =C2=A0=

First, if a hash or signature checks out, then the bits= are known to be correct and there's no need for the redundancy of the = RS codes.

Second, I am not a fan of verificati= on mechanisms that require "just install it, then look at what is inst= alled and assume it is correct, and then sign that." =C2=A0I think it = should be possible to generate all the necessary signatures at *build time*= instead of *install time* (modulo knowledge of the install target's pa= rtition table layout), to eliminate any target-specific configuration weird= ness that's not accounted for at build time.

I think it also helps to think about this problem by wo= rking backwards. =C2=A0Build GRUB on machine A, and install it on machine B= (assume same architecture everywhere, but it doesn't really matter). = =C2=A0Given the contents of B's disk (e.g., MBR + contents of embedding= area), and the build output of A, how do we know if machine B indeed has a= ll the right bits installed? =C2=A0

It's not too hard to run the same grub-mkimage comm= and everywhere so as to generate a consistent core.img (and whatever .img m= akes sense for the MBR) doing the verification, and it's not too hard t= o take knowledge of B's partition table layout to make the necessary ch= anges to those .img files. But, the reed-solomon codes that util/setup.c ad= ds into the embedding area are yet another step that would need to be backe= d out. =C2=A0 =C2=A0

This patch just adds a flag. :)

Thanks,
-Jon



=
--089e013c69c6cbb56d04ea3d12a5--