All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Subject: UEFI Secure boot using qemu-kvm
Date: Wed, 27 Jun 2012 18:34:05 +0100	[thread overview]
Message-ID: <1340818445.3175.73.camel@dabdike.int.hansenpartnership.com> (raw)

Hi Everyone,

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.  Many
thanks are due to the Intel Tianocore project which recently added the
secure boot facility to their UEFI rom images.

What I have done:

I've built the tianocore boot system (along with a README describing how
to use it) and placed it in the opensuse build system so you can
download it (the OVMF package) from:

http://download.opensuse.org/repositories/home:/jejb1:/UEFI/openSUSE_12.1/

(it has no OS depends, so the rpm should be installable on almost any
distro ... including debian via alien).  Also in this repository is
Jeremy Kerr's sbsigntools which can be used to sign efi binaries.

While doing all of this, I discovered a bug in the gnu-efi environment
we usually use to build efi binaries on Linux (the fix is to the loader
script).  I've got an example of how to use the fixed script and a
builder for a LockDown.efi binary that will take a secure boot platform
in setup mode and install a Platform Key and Key Exchange Key and enable
secure boot (if you type make, it will build the PK and KEK
certificates, plus roll them into the binary).

http://git.kernel.org/?p=linux/kernel/git/jejb/efitools.git;a=summary

I'll probably add other useful efi utilities as the project progresses.

I should note that currently Jeremy's efi signing tools only really do
x86_64 binaries, so the whole project is based on that architecture.

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).

I'm releasing this now because interest in UEFI Secure Boot is rising,
particularly amongst the Linux Distributions which don't have access to
UEFI secure boot hardware, so having a virtual platform should allow
them to experiment with coming up with their own solutions.

Please remember, though, that all this is very alpha.  The Tianocore
firmware that does secure boot is only a few weeks old, and the
sbsigning tools weren't really working up until yesterday, so this is
very far from rock solid.

James

PS if you don't understand terms like Platform Key, or Setup Mode in the
above, please ask google for help.  Secure boot is very technical, but
there have been some good blog posts explaining the basics.



             reply	other threads:[~2012-06-27 17:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 17:34 James Bottomley [this message]
2012-06-27 18:15 ` UEFI Secure boot using qemu-kvm Matthew Garrett
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=1340818445.3175.73.camel@dabdike.int.hansenpartnership.com \
    --to=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.