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 ) id 1SfVFN-0008Cc-S2 for garchives@archives.gentoo.org; Fri, 15 Jun 2012 12:03:26 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 47B16E0774; Fri, 15 Jun 2012 12:03:02 +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 6AC18E06F4 for ; Fri, 15 Jun 2012 12:01:49 +0000 (UTC) Received: by bkcjk13 with SMTP id jk13so2566804bkc.40 for ; Fri, 15 Jun 2012 05:01: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=VAb2xylTuUwQDdNOjtwrTzfo5dfNfre32DOc4eg4zZg=; b=qySUHa3A8lM5zJi8OKr7+k3fF+0RsGy7zGdLs3iNxttvkZDubDQcNLlgClVcdea17f LtuhE5lvHF3xunvpMKkmuAaajUDI2+VFe1teCHGJbdZbX5vwf3QeRox/+KasV51OVhh7 O+cilrMDKK5ipSceqCFdybEacIraerLYvaHqwCNfPzIgyS6iT84lPOVrPeb6Pq//+Qy9 N/mG06Y+gLh4JqXG3pqL22TA0wpBlnIgb8UCm9EGE1Qv+wWEdPcm33VFK1u++Ba6yP9u Lhy9ZbkBQtlel80iCOMdEmryuYH4UZ+ir3leOawlJbTFtQcebidAr9DNxCtH710e2nmE Z8mQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.149.216 with SMTP id u24mr2722545bkv.36.1339761708430; Fri, 15 Jun 2012 05:01:48 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.204.149.211 with HTTP; Fri, 15 Jun 2012 05:01:48 -0700 (PDT) In-Reply-To: <20120615113248.GA22231@waltdnes.org> References: <20120615042810.GA9480@kroah.com> <4FDAEB22.4010109@gmail.com> <4FDAF42E.9010304@binarywings.net> <20120615113248.GA22231@waltdnes.org> Date: Fri, 15 Jun 2012 08:01:48 -0400 X-Google-Sender-Auth: 81Gi7tZPWyx83kwZgLK59CH9_fo Message-ID: Subject: Re: [gentoo-dev] UEFI secure boot and Gentoo From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 74eb7a4a-46db-4509-8bd8-1c36a25d0593 X-Archives-Hash: 0a4e2e095659489c14da8ccdd91103ad On Fri, Jun 15, 2012 at 7:32 AM, Walter Dnes wrote: > =A0Question... how would "blacklisting" work on linux machines? =A0Let's > say Joe Blow gets a signing key and then passes it around. =A0I can see > that if you want to build an executable (*.exe) to run under Windows, > you'll run into problems if the monthly MS Windows Update kills that > specific key. I took the time to read the MS Hardware Certification guide. I haven't read the full UEFI spec though it is referenced to it. It sounds like UEFI has a provision for revocation, and that includes an area of flash to store revoked keys. So, if you booted the device on Windows, then Windows could download a list of keys MS doesn't like, and then since Windows is trusted by the firmware it could add those keys to the flash. Then on a reboot the firmware would no longer boot those keys in secure mode. So, the revocation is non-volatile, and doesn't require a firmware update. Of course, if you never run Windows on the device then it probably won't get the update. It wasn't 100% clear, but it sounds like a full factory reset of the firmware might clear these revoked keys out (it definitely is supposed to clear out any custom keys you load). After reading up it seems to me that the best bet for somebody who wants free as in freedom is to just run in custom mode and load their own keys. The MS document leaves a lot of policy questions unanswered though. The vendor has to trust the MS key, and has to secure their root keys. However, they can trust any number of keys, and nothing is said about those keys having to be secure. It seems like that is a loophole that would be rapidly closed in practice if a vendor got "out of line." For ARM users are up the creek unless they can get the vendor to include their keys, or get a signature from somebody whose keys are included. ARM lacks the ability to use custom mode, which means you can't load your own keys, and it can't disable secure boot. Then again, all of this is only as good as the implementation. My current Android phone used just about all the tricks in the spec (flash is locked by bootloader, no downgrading, and so on). However, in the case of my phone messing with the power supply can reset the flash controller before it resets the CPU, unlocking it and allowing a rooted device to flash the bootloader. However, the UEFI specs themselves seem secure, and you can't count on every piece of hardware having an exploit. I think that anybody that really cares about security should be running in custom mode anyway, and should just re-sign anything they want to run. Custom mode lets you clear every single key in the system from the vendor on down, and gives you the ability to ensure the system only boots stuff you want it to. The MS spec does require a full factory reset to restore the original keys, though if you're using secure boot and TPM you could ensure that your hard drive becomes unreadable if this is done (unless the TPM has some backdoor and your vendor is complicit in accessing it). I don't have a problem with secure boot, and obviously to use it any pre-loaded OS has to have pre-loaded keys. What I don't like is the way certain companies are getting privileged in the process. If a full factory reset unlocked the machine, letting the first CD you boot from restore that OS vendor's keys or whatever, then then that would be more neutral. The whole bit about not allowing users to load their keys on ARM is obviously objectionable - I'm fine with ensuring security by making the user go into the pre-boot firmware, but the computer owner should have the final say. Rich