Xen.efi and secure boot

Xen.efi and secure boot

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 659 bytes --]

So while doing a bit of investigation into a request that we have
instructions for how to sign a Xen binary, I came across a related pair of
questions.  If we boot from a signed Xen binary, then:
1. Will Xen then successfully boot a signed dom0 kernel / initrd?
2. Will Xen fail to boot an unsigned dom0 kernel / initrd?

I think if Xen is signed, then ideally we want both 1 and 2 to be true,
right?  Does UEFI provide a way to check the signature of files?  Does it
happen automatically, or would we need to add extra support?  Or would we
need to embed a public key within the Xen binary and have Xen check the
signatures of files that it reads?

 -George

[-- Attachment #1.2: Type: text/html, Size: 686 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen.efi and secure boot

[Andrew Cooper]

On 26/11/12 17:57, George Dunlap wrote:
> So while doing a bit of investigation into a request that we have
> instructions for how to sign a Xen binary, I came across a related
> pair of questions.  If we boot from a signed Xen binary, then:
> 1. Will Xen then successfully boot a signed dom0 kernel / initrd?
> 2. Will Xen fail to boot an unsigned dom0 kernel / initrd?
>
> I think if Xen is signed, then ideally we want both 1 and 2 to be
> true, right?  Does UEFI provide a way to check the signature of
> files?  Does it happen automatically, or would we need to add extra
> support?  Or would we need to embed a public key within the Xen binary
> and have Xen check the signatures of files that it reads?
>
>  -George

The problem is deeper than that.

The idea of secure boot is that only signed/verified code can perform
privileged operations.  One can argue as to exactly where this boundary
lies, but in the native case, it contains any kernel level code. 
Userspace uses the kernel API/ABI subject to the permissions checks
present and (assuming no security holes), everyone is happy.

In the Xen case, Xen will happily accept any privileged hypercalls from
dom0.  So you could argue that anything able to make ioctls against
/dev/xen/privcmd (and friends) would need to be within the signed code. 
This is the entire toolstack, and all root processes.

Furthermore, cross-domain systems like xenbus/xenstore would also need
to be signed.  Imagine the carnage a malicious xenstored could cause!

I am struggling to think of a way of getting secure boot working
correctly without signing all of dom0.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

Re: Xen.efi and secure boot

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 1874 bytes --]

On Mon, Nov 26, 2012 at 6:16 PM, Andrew Cooper <andrew.cooper3@citrix.com>wrote:

> The idea of secure boot is that only signed/verified code can perform
> privileged operations.  One can argue as to exactly where this boundary
> lies, but in the native case, it contains any kernel level code.
> Userspace uses the kernel API/ABI subject to the permissions checks
> present and (assuming no security holes), everyone is happy.
>

Different people have different opinions on this.  Fedora are signing all
the way down to modules, but not user-space; as a result, IIUC, they are
ruling out third-party or out-of-tree drivers.  Ubuntu are not signing
modules AIUI, so in theory someone could install a rootkit; but they think
that it's likely any local attacker is going to be able to attack the
kernel anyway; on the balance having third-party drivers is more important
to them.

Nonetheless, Ubuntu are still signing kernels, so that the kernel can still
do some of the "boot mode" UEFI operations. (Not sure the correct term
here.)  The idea is that the kernel will disable the "boot mode" UEFI
operations before it loads any kernel modules.  Someone booting Xen
directly from EFI may want to do the same thing.

 -George


>
> In the Xen case, Xen will happily accept any privileged hypercalls from
> dom0.  So you could argue that anything able to make ioctls against
> /dev/xen/privcmd (and friends) would need to be within the signed code.
> This is the entire toolstack, and all root processes.
>
> Furthermore, cross-domain systems like xenbus/xenstore would also need
> to be signed.  Imagine the carnage a malicious xenstored could cause!
>
> I am struggling to think of a way of getting secure boot working
> correctly without signing all of dom0.
>
> --
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com
>
>

[-- Attachment #1.2: Type: text/html, Size: 2570 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen.efi and secure boot

[Alan Cox]

> ruling out third-party or out-of-tree drivers.  Ubuntu are not signing
> modules AIUI, so in theory someone could install a rootkit; but they think

They can anyway. If the kernel has a hole you can just stuff something
hidden in early early userspace boot (eg in the initrd) to re-trojan it.

Plus the next generation of devices mostly suspend/resume so its hardly
that important anyway.

> that it's likely any local attacker is going to be able to attack the
> kernel anyway; on the balance having third-party drivers is more important
> to them.

Don't be misled into thinking this has anything much to do with security.
If you are trying to do security use the TPM and do a trusted measured
boot which gives you the keys to the file system which then uses signing
of its own.
 
> Nonetheless, Ubuntu are still signing kernels

In the UEFI sense they are not - nor are Fedora. They are signing a tiny
boot loader and implementing their own policy behind that. It's basically
a way around the Windows 8 lock down.

Re: Xen.efi and secure boot

[Pasi Kärkkäinen]

On Tue, Nov 27, 2012 at 10:51:06AM +0000, George Dunlap wrote:
>    On Mon, Nov 26, 2012 at 6:16 PM, Andrew Cooper
>    <[1]andrew.cooper3@citrix.com> wrote:
> 
>      The idea of secure boot is that only signed/verified code can perform
>      privileged operations.  One can argue as to exactly where this boundary
>      lies, but in the native case, it contains any kernel level code.
>      Userspace uses the kernel API/ABI subject to the permissions checks
>      present and (assuming no security holes), everyone is happy.
> 
>    Different people have different opinions on this.  Fedora are signing all
>    the way down to modules, but not user-space; as a result, IIUC, they are
>    ruling out third-party or out-of-tree drivers.
>

Fedora/Redhat are planning to support custom/out-of-tree drivers by allowing
the user to install trusted custom signing keys, so you can sign the kernel drivers
using those keys.

The process was described for example in Matthew Garrett's UEFI presentation at 
LinuxCon 2012 NA after XenSummit 2012.

Some info:
http://mjg59.dreamwidth.org/16863.html:

"We're planning on using Suse's approach of permitting local key management at the shim level, and I spent some time discussing this with Vojtech last week. In combination with the above, this should provide a workable mechanism for permitting the end-user to install module signing keys."

-- Pasi

Re: Xen.efi and secure boot

[Ian Campbell]

On Mon, 2012-11-26 at 18:16 +0000, Andrew Cooper wrote:
> On 26/11/12 17:57, George Dunlap wrote:
> > So while doing a bit of investigation into a request that we have
> > instructions for how to sign a Xen binary, I came across a related
> > pair of questions.  If we boot from a signed Xen binary, then:
> > 1. Will Xen then successfully boot a signed dom0 kernel / initrd?
> > 2. Will Xen fail to boot an unsigned dom0 kernel / initrd?
> >
> > I think if Xen is signed, then ideally we want both 1 and 2 to be
> > true, right?  Does UEFI provide a way to check the signature of
> > files?  Does it happen automatically, or would we need to add extra
> > support?  Or would we need to embed a public key within the Xen binary
> > and have Xen check the signatures of files that it reads?
> >
> >  -George
> 
> The problem is deeper than that.
> 
> The idea of secure boot is that only signed/verified code can perform
> privileged operations.  One can argue as to exactly where this boundary
> lies, but in the native case, it contains any kernel level code. 
> Userspace uses the kernel API/ABI subject to the permissions checks
> present and (assuming no security holes), everyone is happy.
> 
> In the Xen case, Xen will happily accept any privileged hypercalls from
> dom0.  So you could argue that anything able to make ioctls against
> /dev/xen/privcmd (and friends) would need to be within the signed code. 
> This is the entire toolstack, and all root processes.

AIUI Restricted Boot doesn't really concern itself with the integrity of
the system post boot, just with the integrity of the bits which are
being booted. I think this extends to booting dom0 but anything relating
to booting guests could reasonably be considered to be handled
separately.

Given that it's very possible that the hypervisor could lock down even
dom0 from being able to make calls which would allow the firmware to be
subverted (i.e. access to I/O ports or MMIO regions which would allow
the BIOS to be reflashed or whatever), at which point dom0 root user and
toolstack becomes irrelevant.

That probably involves some sort of black/whitelisting scheme for I/O
ports and such which is pretty tedious but not overwhelming I don't
think.

> Furthermore, cross-domain systems like xenbus/xenstore would also need
> to be signed.  Imagine the carnage a malicious xenstored could cause!

It would need to be able to subvert the bootloader and system firmware
or something, which seems like a bit of a stretch.

> I am struggling to think of a way of getting secure boot working
> correctly without signing all of dom0.

Ian.

Re: Xen.efi and secure boot

[Alan Cox]

> That probably involves some sort of black/whitelisting scheme for I/O
> ports and such which is pretty tedious but not overwhelming I don't
> think.

Until you start to think about indirect access via DMA or using one
device to set up an I/O window into another, or the ACPI EC or the GPU ...

its nigh on impossible. PC hardware isn't designed for restricted boot.

Alan

Re: Xen.efi and secure boot

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

On Mon, 26 Nov 2012, George Dunlap wrote:
> So while doing a bit of investigation into a request that we have instructions for how to sign a Xen binary, I came across a related pair of questions.  If we
> boot from a signed Xen binary, then:
> 1. Will Xen then successfully boot a signed dom0 kernel / initrd?
> 2. Will Xen fail to boot an unsigned dom0 kernel / initrd?
> 
> I think if Xen is signed, then ideally we want both 1 and 2 to be true, right? 

I think that you are right

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen.efi and secure boot

[Alan Cox]

On Mon, 26 Nov 2012 20:12:04 +0000
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Mon, 26 Nov 2012, George Dunlap wrote:
> > So while doing a bit of investigation into a request that we have instructions for how to sign a Xen binary, I came across a related pair of questions.  If we
> > boot from a signed Xen binary, then:
> > 1. Will Xen then successfully boot a signed dom0 kernel / initrd?
> > 2. Will Xen fail to boot an unsigned dom0 kernel / initrd?
> > 
> > I think if Xen is signed, then ideally we want both 1 and 2 to be true, right? 
> 
> I think that you are right

I think you'd have to be out of your tree to try and sign Xen itself
using the MS setup - assuming you can ever get a key and get it to work
which seems to be an issue of its own.

You want to sign a small bootloader that is tightly auditable and do your
own key management within that for anything else. I would think you'd be
able to make use of the Linux bootloader work.

Better yet would be to take the entire sorry EFI and 'secure' boot mess
and kick it where the sun won't shine but alas that may be a challenge
until the PC manufacturers realise they can't handle the support costs of
things in the current state and fix it.

Re: Xen.efi and secure boot

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 1366 bytes --]

On Mon, Nov 26, 2012 at 9:51 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> I think you'd have to be out of your tree to try and sign Xen itself
> using the MS setup - assuming you can ever get a key and get it to work
> which seems to be an issue of its own.
>

> You want to sign a small bootloader that is tightly auditable and do your
> own key management within that for anything else. I would think you'd be
> able to make use of the Linux bootloader work.
>

I was thinking of people who wanted to install their own keys.  Some people
think that since you have EFI you shouldn't need a bootloader. :-)

But you're right, I think on the whole the critical thing is just to make
sure that "secure" bootloaders from distros know how to load signed Xen /
Linux images.  Booting Xen directly is probably going to be a bit niche.
That said, I'm sure there are people who will want to do it, so it probably
should be on our "to-do" list.


>
> Better yet would be to take the entire sorry EFI and 'secure' boot mess
> and kick it where the sun won't shine but alas that may be a challenge
> until the PC manufacturers realise they can't handle the support costs of
> things in the current state and fix it.
>

I'm not sure the vendors have much choice in the matter, as long as a
single vendor controls the majority of the market and can dictate terms.

 -George

[-- Attachment #1.2: Type: text/html, Size: 2072 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen.efi and secure boot

[Jan Beulich]

>>> On 27.11.12 at 10:50, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Mon, Nov 26, 2012 at 9:51 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> You want to sign a small bootloader that is tightly auditable and do your
>> own key management within that for anything else. I would think you'd be
>> able to make use of the Linux bootloader work.
>>
> 
> I was thinking of people who wanted to install their own keys.  Some people
> think that since you have EFI you shouldn't need a bootloader. :-)

I think boot loader is the wrong term - shim loader is what our folks
use (i.e. just a wrapper to deal with the key problem). That would
wrap grub2.efi (or whatever its name) as well as xen.efi or (if
someone cares) elilo.efi.

Jan

Re: Xen.efi and secure boot

[Jan Beulich]

>>> On 26.11.12 at 18:57, George Dunlap <dunlapg@umich.edu> wrote:
> So while doing a bit of investigation into a request that we have
> instructions for how to sign a Xen binary, I came across a related pair of
> questions.  If we boot from a signed Xen binary, then:
> 1. Will Xen then successfully boot a signed dom0 kernel / initrd?
> 2. Will Xen fail to boot an unsigned dom0 kernel / initrd?
> 
> I think if Xen is signed, then ideally we want both 1 and 2 to be true,
> right?  Does UEFI provide a way to check the signature of files?  Does it
> happen automatically, or would we need to add extra support?  Or would we
> need to embed a public key within the Xen binary and have Xen check the
> signatures of files that it reads?

I don't have any answers to these questions yet; as we need to
do this for our upcoming SLE11 SP3, I'm expecting our EFI and/or
kernel folks to come forward with an outline of what needs to be
done (and ideally with an implementation in the boot loader) that
I could then just clone for the Xen code. I had expected that to
happen already, but it's apparently not making enough progress
(or the progress is not visible to me).

Jan

Re: Xen.efi and secure boot

[Jan Beulich]

>>> On 26.11.12 at 18:57, George Dunlap <dunlapg@umich.edu> wrote:
> So while doing a bit of investigation into a request that we have
> instructions for how to sign a Xen binary, I came across a related pair of
> questions.  If we boot from a signed Xen binary, then:
> 1. Will Xen then successfully boot a signed dom0 kernel / initrd?
> 2. Will Xen fail to boot an unsigned dom0 kernel / initrd?
> 
> I think if Xen is signed, then ideally we want both 1 and 2 to be true,
> right?

Not necessarily: With the shim approach that most people now
seem to agree to, it would depend on whether xen.efi actually
got loaded directly or through the shim. When loaded through
the shim, both ought to be true. If loaded without the shim,
whether Xen is signed doesn't matter, and hence whether the
Dom0 kernel image is signed shouldn't matter either.

The grub2 code I just looked at doesn't verify the initrd btw,
that's apparently left to the kernel.

> Does UEFI provide a way to check the signature of files? Does
> it happen automatically, or would we need to add extra support?
> Or would we need to embed a public key within the Xen binary
> and have Xen check the signatures of files that it reads?

No, that's what the shim is actually for - it publishes a suitable,
trivial protocol.

Adding the verification step has turned out to require 19 added
lines, so pretty trivial. I didn't look into what additional data Dom0
may need access to, yet.

Jan

Re: Xen.efi and secure boot

[Jan Beulich]

>>> On 28.11.12 at 16:33, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 26.11.12 at 18:57, George Dunlap <dunlapg@umich.edu> wrote:
>> So while doing a bit of investigation into a request that we have
>> instructions for how to sign a Xen binary, I came across a related pair of
>> questions.  If we boot from a signed Xen binary, then:
>> 1. Will Xen then successfully boot a signed dom0 kernel / initrd?
>> 2. Will Xen fail to boot an unsigned dom0 kernel / initrd?
>> 
>> I think if Xen is signed, then ideally we want both 1 and 2 to be true,
>> right?
> 
> Not necessarily: With the shim approach that most people now
> seem to agree to, it would depend on whether xen.efi actually
> got loaded directly or through the shim. When loaded through
> the shim, both ought to be true. If loaded without the shim,
> whether Xen is signed doesn't matter, and hence whether the
> Dom0 kernel image is signed shouldn't matter either.
> 
> The grub2 code I just looked at doesn't verify the initrd btw,
> that's apparently left to the kernel.
> 
>> Does UEFI provide a way to check the signature of files? Does
>> it happen automatically, or would we need to add extra support?
>> Or would we need to embed a public key within the Xen binary
>> and have Xen check the signatures of files that it reads?
> 
> No, that's what the shim is actually for - it publishes a suitable,
> trivial protocol.
> 
> Adding the verification step has turned out to require 19 added
> lines, so pretty trivial. I didn't look into what additional data Dom0
> may need access to, yet.

So I learned a little more meanwhile - it's not that trivial: I'm told
the shim uses UEFI services to do the verification, and those
services only handle PE images. But we obviously can't reasonably
expect the Dom0 kernel to be packaged as PE image, as that
would then be unusable as DomU kernel (on older hosts at least,
i.e. even if we added a PE loader to libxc).

I'm therefore considering to create a PE image from the kernel
binary [if compressed, even without uncompressing] on the fly
(in memory), and present that to the verification routine. Which
requires a way to locate the signature within that binary kernel
blob, which would need to be placed there without disturbing the
decompression of the image - not sure if that's possible at all.

Jan

Re: Xen.efi and secure boot

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 534 bytes --]

On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote:

> So I learned a little more meanwhile - it's not that trivial: I'm told
> the shim uses UEFI services to do the verification, and those
> services only handle PE images. But we obviously can't reasonably
> expect the Dom0 kernel to be packaged as PE image, as that
> would then be unusable as DomU kernel (on older hosts at least,
> i.e. even if we added a PE loader to libxc).
>

Sorry for the n00b question, but what's a PE image in this context?

 -George

[-- Attachment #1.2: Type: text/html, Size: 906 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen.efi and secure boot

[Mats Petersson]

On 30/11/12 10:42, George Dunlap wrote:
> On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com 
> <mailto:JBeulich@suse.com>> wrote:
>
>     So I learned a little more meanwhile - it's not that trivial: I'm told
>     the shim uses UEFI services to do the verification, and those
>     services only handle PE images. But we obviously can't reasonably
>     expect the Dom0 kernel to be packaged as PE image, as that
>     would then be unusable as DomU kernel (on older hosts at least,
>     i.e. even if we added a PE loader to libxc).
>
>
> Sorry for the n00b question, but what's a PE image in this context?
I think this refers to the Microsoft PE (portable executable) file 
format - that is, the file should be like a .EXE or .DLL on windows.

I wish I thought I was wrong here, but I'm afraid that MS solutions are 
rather popular in some camps...
Further searching seems to confirm that PE is indeed "standard format" 
for EFI.
http://en.wikipedia.org/wiki/Portable_Executable

--
Mats
>
>  -George
>

Re: Xen.efi and secure boot

[Jan Beulich]

>>> On 30.11.12 at 11:42, George Dunlap <dunlapg@umich.edu> wrote:
> On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> So I learned a little more meanwhile - it's not that trivial: I'm told
>> the shim uses UEFI services to do the verification, and those
>> services only handle PE images. But we obviously can't reasonably
>> expect the Dom0 kernel to be packaged as PE image, as that
>> would then be unusable as DomU kernel (on older hosts at least,
>> i.e. even if we added a PE loader to libxc).
>>
> 
> Sorry for the n00b question, but what's a PE image in this context?

"Portable Executable", i.e. the binary format used by Windows
and EFI for their executables.

Jan

Re: Xen.efi and secure boot

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 762 bytes --]

On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote:

>
> So I learned a little more meanwhile - it's not that trivial: I'm told
> the shim uses UEFI services to do the verification, and those
> services only handle PE images. But we obviously can't reasonably
> expect the Dom0 kernel to be packaged as PE image, as that
> would then be unusable as DomU kernel (on older hosts at least,
> i.e. even if we added a PE loader to libxc).
>

But what does the shim use to check the signature of Xen in this case?
Does Xen / native Linux need to be a PE image to boot from the shim?  If
not, wouldn't the native PE image suffice?  And if so, why can't the shim
check signatures the same way it checks the sig for the thing it's booting?

 -George

[-- Attachment #1.2: Type: text/html, Size: 1149 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen.efi and secure boot

[Jan Beulich]

>>> On 30.11.12 at 11:56, George Dunlap <dunlapg@umich.edu> wrote:
> On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>>
>> So I learned a little more meanwhile - it's not that trivial: I'm told
>> the shim uses UEFI services to do the verification, and those
>> services only handle PE images. But we obviously can't reasonably
>> expect the Dom0 kernel to be packaged as PE image, as that
>> would then be unusable as DomU kernel (on older hosts at least,
>> i.e. even if we added a PE loader to libxc).
>>
> 
> But what does the shim use to check the signature of Xen in this case?
> Does Xen / native Linux need to be a PE image to boot from the shim?

Yes - xen.efi just needs to get a signature implanted for that
part to work, and native Linux uses the EFI_STUB mechanism
to gets its binary into said format (which then also only needs a
signature added).

>  If
> not, wouldn't the native PE image suffice?  And if so, why can't the shim
> check signatures the same way it checks the sig for the thing it's booting?

The checking code only knows to locate signatures inside PE
images. Consequently, whatever you want to pass to that code
needs to look like one. xen.efi and native Linux with EFI_STUB
enabled already do, but if you handed such a kernel binary to
either of the two PV domain kernel loaders Xen has, they would
just bail.

But - now that I checked what I was told, I can't see the EFI_STUB
config option to result in a PE binary to be created. So I'm back to
square 1...

Jan

Re: Xen.efi and secure boot

[Jan Beulich]

>>> On 30.11.12 at 12:23, "Jan Beulich" <JBeulich@suse.com> wrote:
> But - now that I checked what I was told, I can't see the EFI_STUB
> config option to result in a PE binary to be created. So I'm back to
> square 1...

Wait - I looked at the wrong file, it _is_ a PE binary that results.

Jan

Re: Xen.efi and secure boot

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 1988 bytes --]

On Fri, Nov 30, 2012 at 11:23 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 30.11.12 at 11:56, George Dunlap <dunlapg@umich.edu> wrote:
> > On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >
> >>
> >> So I learned a little more meanwhile - it's not that trivial: I'm told
> >> the shim uses UEFI services to do the verification, and those
> >> services only handle PE images. But we obviously can't reasonably
> >> expect the Dom0 kernel to be packaged as PE image, as that
> >> would then be unusable as DomU kernel (on older hosts at least,
> >> i.e. even if we added a PE loader to libxc).
> >>
> >
> > But what does the shim use to check the signature of Xen in this case?
> > Does Xen / native Linux need to be a PE image to boot from the shim?
>
> Yes - xen.efi just needs to get a signature implanted for that
> part to work, and native Linux uses the EFI_STUB mechanism
> to gets its binary into said format (which then also only needs a
> signature added).
>
> >  If
> > not, wouldn't the native PE image suffice?  And if so, why can't the shim
> > check signatures the same way it checks the sig for the thing it's
> booting?
>
> The checking code only knows to locate signatures inside PE
> images. Consequently, whatever you want to pass to that code
> needs to look like one. xen.efi and native Linux with EFI_STUB
> enabled already do, but if you handed such a kernel binary to
> either of the two PV domain kernel loaders Xen has, they would
> just bail.
>

OK... so Fedora and Ubuntu are going to be shipping signed kernel
binaries.  Are those binaries going to be in PE / EFI format then?  If so:
1. You won't need to do any fancy on-the-fly repackaging in Xen; you can
just pass the already-signed distro-supplied binary
2. The toolstack is simply going to have to be able to read PE kernels for
PV guests
3. If distros don't include non-PE kernels, we're going to have to backport
that functionality to older versions of Xen.

 -George

[-- Attachment #1.2: Type: text/html, Size: 2622 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen.efi and secure boot

[Jan Beulich]

>>> On 30.11.12 at 12:34, George Dunlap <dunlapg@umich.edu> wrote:
> On Fri, Nov 30, 2012 at 11:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 30.11.12 at 11:56, George Dunlap <dunlapg@umich.edu> wrote:
>> > On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >
>> >>
>> >> So I learned a little more meanwhile - it's not that trivial: I'm told
>> >> the shim uses UEFI services to do the verification, and those
>> >> services only handle PE images. But we obviously can't reasonably
>> >> expect the Dom0 kernel to be packaged as PE image, as that
>> >> would then be unusable as DomU kernel (on older hosts at least,
>> >> i.e. even if we added a PE loader to libxc).
>> >>
>> >
>> > But what does the shim use to check the signature of Xen in this case?
>> > Does Xen / native Linux need to be a PE image to boot from the shim?
>>
>> Yes - xen.efi just needs to get a signature implanted for that
>> part to work, and native Linux uses the EFI_STUB mechanism
>> to gets its binary into said format (which then also only needs a
>> signature added).
>>
>> >  If
>> > not, wouldn't the native PE image suffice?  And if so, why can't the shim
>> > check signatures the same way it checks the sig for the thing it's
>> booting?
>>
>> The checking code only knows to locate signatures inside PE
>> images. Consequently, whatever you want to pass to that code
>> needs to look like one. xen.efi and native Linux with EFI_STUB
>> enabled already do, but if you handed such a kernel binary to
>> either of the two PV domain kernel loaders Xen has, they would
>> just bail.
>>
> 
> OK... so Fedora and Ubuntu are going to be shipping signed kernel
> binaries.  Are those binaries going to be in PE / EFI format then?  If so:
> 1. You won't need to do any fancy on-the-fly repackaging in Xen; you can
> just pass the already-signed distro-supplied binary
> 2. The toolstack is simply going to have to be able to read PE kernels for
> PV guests
> 3. If distros don't include non-PE kernels, we're going to have to backport
> that functionality to older versions of Xen.

Looks like our bzImage loader may be able to deal with these
(fake) PE images already, so that should then be backwards
compatible back to 3.4.2 (DomU loader) and 4.0.0 (Dom0
loader). Good enough, I think. I'll check next week whether
that's actually true.

Jan