Re: [Xen-devel] Xen.efi and secure boot

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.11.12 at 16:33, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 26.11.12 at 18:57, George Dunlap <dunlapg@xxxxxxxxx> 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


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