[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 30.11.12 at 11:56, George Dunlap <dunlapg@xxxxxxxxx> wrote:
> On Fri, Nov 30, 2012 at 10:27 AM, Jan Beulich <JBeulich@xxxxxxxx> 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


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.