public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] UEFI secure boot and Gentoo
Date: Fri, 15 Jun 2012 08:01:48 -0400	[thread overview]
Message-ID: <CAGfcS_mGmP+gXdEaECcqdkmp4JeCsPYzT7e17WOoH97+_ip4PQ@mail.gmail.com> (raw)
In-Reply-To: <20120615113248.GA22231@waltdnes.org>

On Fri, Jun 15, 2012 at 7:32 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>  Question... how would "blacklisting" work on linux machines?  Let's
> say Joe Blow gets a signing key and then passes it around.  I 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



  reply	other threads:[~2012-06-15 12:03 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15  4:28 [gentoo-dev] UEFI secure boot and Gentoo Greg KH
2012-06-15  4:45 ` Arun Raghavan
2012-06-15  4:56   ` Greg KH
2012-06-15  5:24     ` Arun Raghavan
2012-06-15 21:28       ` Matthew Thode
2012-06-15  5:48     ` Eray Aslan
2012-06-15  7:26     ` Michał Górny
2012-06-15  7:49       ` Florian Philipp
2012-06-15  8:06         ` Richard Farina
2012-06-15  8:24           ` Florian Philipp
2012-06-15 23:59         ` Greg KH
2012-06-16  8:33           ` Florian Philipp
2012-06-16  0:03       ` gregkh
2012-06-15  5:00   ` [gentoo-dev] " Duncan
2012-06-15  5:03   ` [gentoo-dev] " Ben de Groot
2012-06-15  5:08     ` Matthew Finkel
2012-06-15  5:24     ` Arun Raghavan
2012-06-15  7:12       ` Ben de Groot
2012-06-15  7:58         ` Richard Farina
2012-06-15  8:37           ` Florian Philipp
2012-06-15 11:32             ` Walter Dnes
2012-06-15 12:01               ` Rich Freeman [this message]
2012-06-15 12:48                 ` Florian Philipp
2012-06-16  9:22                 ` Maxim Kammerer
2012-06-17 17:03                   ` Greg KH
2012-06-17 19:22                     ` Maxim Kammerer
2012-06-15 10:50           ` Ben de Groot
2012-06-16  0:02     ` Greg KH
2012-06-15  4:45 ` Greg KH
2012-06-15  5:48   ` Philip Webb
2012-06-16  0:01     ` Greg KH
2012-06-16  3:18       ` Philip Webb
2012-06-15 21:35   ` Matthew Thode
2012-06-16  0:00     ` Greg KH
2012-06-15  4:50 ` [gentoo-dev] " Duncan
2012-06-15  5:01   ` Matthew Finkel
2012-06-15  7:54   ` Florian Philipp
2012-06-15 12:28     ` Walter Dnes
2012-06-15 12:55       ` Florian Philipp
2012-06-16 23:37         ` Steev Klimaszewski
2012-06-17 16:58           ` Greg KH
2012-06-17 17:24             ` Dale
2012-06-16 17:51     ` Michał Górny
2012-06-17  9:20       ` Florian Philipp
2012-06-17 15:51         ` Michał Górny
2012-06-17 16:55           ` Greg KH
2012-06-17 17:06             ` Michał Górny
2012-06-17 17:17               ` Rich Freeman
2012-06-17 17:28               ` Florian Philipp
2012-06-17 17:56               ` Greg KH
2012-06-17 16:56           ` Matthew Finkel
2012-06-17 17:10             ` Michał Górny
2012-06-17 17:40               ` Florian Philipp
2012-06-17 17:34       ` Sascha Cunz
2012-06-17 17:55         ` Rich Freeman
2012-06-17 18:00         ` Florian Philipp
2012-06-17 18:56           ` Sascha Cunz
2012-06-17 19:20             ` Graham Murray
2012-06-17 20:30             ` Florian Philipp
2012-06-17 23:07               ` Rich Freeman
2012-06-22  6:42                 ` George Prowse
2012-06-15  4:57 ` [gentoo-dev] " Chí-Thanh Christopher Nguyễn
2012-06-15 12:18   ` Luca Barbato
2012-06-15 12:33     ` Rich Freeman
2012-06-15 23:56   ` Greg KH
2012-06-16  6:30     ` Michał Górny
2012-06-15 10:14 ` Rich Freeman
2012-06-15 11:26   ` Florian Philipp
2012-06-15 12:22   ` Luca Barbato
2012-06-15 12:45     ` Rich Freeman
2012-06-15 15:46   ` G.Wolfe Woodbury
2012-06-15 23:55   ` Greg KH
2012-06-16  0:41     ` Rich Freeman
2012-06-16  3:49       ` Greg KH
2012-06-16 23:52 ` Matthew Summers
2012-06-17  0:23   ` [gentoo-dev] " Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGfcS_mGmP+gXdEaECcqdkmp4JeCsPYzT7e17WOoH97+_ip4PQ@mail.gmail.com \
    --to=rich0@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox