Message-ID: <1340825704.3175.88.camel@dabdike.int.hansenpartnership.com>
Subject: Re: UEFI Secure boot using qemu-kvm
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
        Jonathan Corbet <corbet@lwn.net>
Date: Wed, 27 Jun 2012 20:35:04 +0100
In-Reply-To: <20120627181503.GA7775@srcf.ucam.org>
References: <1340818445.3175.73.camel@dabdike.int.hansenpartnership.com>
	 <20120627181503.GA7775@srcf.ucam.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2075
Lines: 45

On Wed, 2012-06-27 at 19:15 +0100, Matthew Garrett wrote:
> 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.

I've tried to build pesign, but I have huge problems with the make
process; how did you build it?

However, sbsign (with four extra patches I've sent to Jeremy) seems to
be built and working.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/