All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: UEFI Secure boot using qemu-kvm
Date: Wed, 27 Jun 2012 19:15:03 +0100	[thread overview]
Message-ID: <20120627181503.GA7775@srcf.ucam.org> (raw)
In-Reply-To: <1340818445.3175.73.camel@dabdike.int.hansenpartnership.com>

On Wed, Jun 27, 2012 at 06:34:05PM +0100, James Bottomley wrote:

> The purpose of this email is to widen the pool of people who are playing
> with UEFI Secure boot.  The Linux Foundation Technical Advisory Board
> have been looking into this because it turns out to be rather difficult
> to lay your hands on real UEFI Secure Boot enabled hardware.

http://tunnelmountain.net/ is the canonical source, but I believe that 
these are now out of stock and waiting for Intel to finish the 
firmware for the replacement.

> The current state is that I've managed to lock down the secure boot
> virtual platform with my own PK and KEK and verified that I can generate
> signed efi binaries that will run on it (and that it will refuse to run
> unsigned efi binaries).  Finally I've demonstrated that I can sign
> elilo.efi (this has to be built specially because of the bug in gnu-efi)
> and have it boot an unsigned linux kernel when the platform is in secure
> mode (I've booted up to an initrd root prompt).

It's probably worth noting that booting unsigned kernels violates the 
expectations of various vendors 
(http://msdn.microsoft.com/en-us/library/windows/desktop/hh848062%28v=vs.85%29.aspx 
would be unnecessary if you're supporting unsigned kernels, for 
example). There's no public cross-vendor guidance on this, but I'm 
trying to get that rectified.

As well as sbsign there's also https://github.com/vathpela/pesign for 
anyone stuck relying on nss rather than openssl for awkward regulatory 
reasons.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  reply	other threads:[~2012-06-27 18:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 17:34 UEFI Secure boot using qemu-kvm James Bottomley
2012-06-27 18:15 ` Matthew Garrett [this message]
2012-06-27 19:35   ` James Bottomley
2012-06-27 19:38     ` Matthew Garrett
2012-06-27 19:53       ` James Bottomley
2012-06-27 20:01         ` Matthew Garrett
2012-06-28 18:36           ` Alex Elsayed
2012-06-28 10:01 joeyli
2012-06-28 10:22 ` James Bottomley
2012-06-28 10:49   ` joeyli

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=20120627181503.GA7775@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=corbet@lwn.net \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.