From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-52528-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Sfh65-0005t1-Rb
for garchives@archives.gentoo.org; Sat, 16 Jun 2012 00:42:45 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 00947E0B10;
Sat, 16 Jun 2012 00:42:23 +0000 (UTC)
Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53])
by pigeon.gentoo.org (Postfix) with ESMTP id 0A2D1E0660
for <gentoo-dev@lists.gentoo.org>; Sat, 16 Jun 2012 00:41:48 +0000 (UTC)
Received: by bkcjk13 with SMTP id jk13so3129452bkc.40
for <gentoo-dev@lists.gentoo.org>; Fri, 15 Jun 2012 17:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type
:content-transfer-encoding;
bh=suUoWZCOnQUDSzHpsWOXp5Oa12mtWtRbR4R6q8Spp5Y=;
b=Vxu2Mb8B1jl1AYvPKMwIftAR1wSBAA+ohJTMLJ/lCx4IM/jP4DA29/wI1TrjKc4UN3
yhG24DGqBjVe+kopOUtHr4P4cLSrnvMbDA0j0iPsctjV/iwLOe0glwvuI7gzu16U01Rq
gHthqTJXJbfIFcTcjuvgP///kqEzVwYmb9TYXUf6O38xtEI+FF7LOjnbD1Pf59+eZJ6A
6dZ/DPiDieRyyPvnz8qfZKbtzy6/gLTDND2XXdL01gGkhsqBR3qtrdp1kqWeFskbt8/b
QXigCfHkuDd0oIiIzt6zslkOqm/MgC2uoHWY5i1fc7W4xdOTLAy1S8dEn9VGw3CPb+ZG
Y+/A==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.204.130.85 with SMTP id r21mr3691525bks.53.1339807308000; Fri,
15 Jun 2012 17:41:48 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.204.149.211 with HTTP; Fri, 15 Jun 2012 17:41:47 -0700 (PDT)
In-Reply-To: <20120615235553.GB9885@kroah.com>
References: <20120615042810.GA9480@kroah.com>
<CAGfcS_=U5_xwGYgdF0L_yrdjMWSNkcPeqGFmZa4o6L+JtKvX9w@mail.gmail.com>
<20120615235553.GB9885@kroah.com>
Date: Fri, 15 Jun 2012 20:41:47 -0400
X-Google-Sender-Auth: aGfSqjAsFekRVybBqxUz_S3SQCo
Message-ID: <CAGfcS_mvUwCP7zfG6rVZ64ycbDswzHoN+h6Z-r+1FbrJDDa9_w@mail.gmail.com>
Subject: Re: [gentoo-dev] UEFI secure boot and Gentoo
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: ce9ce394-f4ed-4169-8a64-ba4e7fb87235
X-Archives-Hash: 2da24839ad65f14536b8afdaca1d01ce
On Fri, Jun 15, 2012 at 7:55 PM, Greg KH <gregkh@gentoo.org> wrote:
> On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote:
> The whole chain-of-trust is an interesting issue as the UEFI spec does
> not require it at all, and some people on the UEFI committee have told
> me that it is not required either. =A0But, others have. =A0Getting to the
> root of this problem is something I'm trying to do, as it's a very
> important one for anyone who is going to be trusting, and providing, a
> key in the BIOS.
It sounds like the UEFI committee isn't really the problem here. You
can have a UEFI firmware as long as it follows the spec. However, you
won't get the Windows logo certification if you don't follow the
Windows rules.
I would think they'd basically want a chain of trust for anything that
loads into kernel space. Otherwise all a malware author has to do is
ship a signed linux kernel, have it boot a bash script that loads
their malware via an unsigned kernel module, and then at that point
they just intercept whatever they want to and then boot Windows,
discarding the rest of the linux kernel.
However, even the MS requirements say that an OEM can have other keys
as well, and nothing says that all of them need to be secure (other
than the root key). If I published a keypair on the internet and
persuaded OEMs to include it as trusted, then in theory that would
pass the MS requirements as they are currently written, and would
render secure boot meaningless.
Rich