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

Re: [Xen-devel] Booting signed xen.efi through shim

On Wed, Sep 20, 2017 at 9:46 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 20.09.17 at 17:20, <tamas@xxxxxxxxxxxxx> wrote:
>> On Wed, Sep 20, 2017 at 12:30 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 20.09.17 at 00:23, <tamas@xxxxxxxxxxxxx> wrote:
>>>> Yeap, the shim pretty simply removed the .reloc section as it was
>>>> marked discardable and did the relocations for Xen. So with that
>>>> removed from the shim I no longer get the error and I see that the
>>>> dom0 kernel gets verified using the shim lock protocol.
>>> So did you instead try whether simply clearing the discardable
>>> flag from the section also helps? The flag ought to matter in
>>> paged environments only (which EFI isn't despite paging being
>>> enabled), but as we see some people think otherwise.
>> Yes, that would work. Even if the shim does its relocations everything
>> "just works" as long as Xen can also find the .reloc section. For now
>> it was just simpler for me to patch the shim to copy the reloc section
>> but it would be ideal if the xen.efi that's produced during
>> compilation would not have that flag set to begin with. I did search
>> around briefly to see where that flag is coming from but the only
>> reference to it within Xen I found was arch/x86/efi/mkreloc.c. So sans
>> writing a separate tool that binary patches xen.efi after compilation
>> to remove that flag I'm not sure how to get that done.
> That'll likely be another binutils tweak. What I find odd is that you're
> apparently the only one to have this problem.

My guess is that not many people have actually tried booting Xen
through the shim before. I looked through the shim history and the
reloc section was discarded all the way back to several years if it
was marked discardable. So unless the discardable flag is something
that only has been added to the reloc section recently, someone should
have run into it already.

>>>> I still didn't
>>>> get dom0 to boot for some reason but that might be an unrelated issue
>>>> (and I have no serial console right now). Nevertheless, progress!
>>> And it doesn't get far enough for you to see any output at all?
>>> Did you try "earlyprintk=xen" on the kernel command line and/or
>>> "vga=keep" on the Xen one?
>> I tried with both just now, no output at all from Xen on the screen
>> after it exits EFI boot. I also couldn't get any output from it on my
>> other laptop with Intel AMT.
> Odd.
>> I did manage to get another Linux kernel booting but my goal was to
>> get a shim verified dom0 kernel booting without an initrd image as
>> right now the ramdisk is not verified by the shim (also not sure how
>> that's supposed to work as sbsign/pesign can only deal with PE/COFF
>> binaries which the ramdisk isn't).
> That's not how it's supposed to work, I think. Just like the shim only
> verifies Xen and hands through the other modules unchecked, Xen
> only verifies the Dom0 kernel image (with the help of the shim). It's
> the Dom0 kernel to then verify the content (not necessarily the
> blob) of the initrd.

Yea, that would be a sensible approach though I haven't (yet) found
anything that I could use with linux to do that initrd verification.
So my approach right now is to get the initrd baked into the dom0
kernel, that way the whole thing can be signed and Xen can verify both
in one shot using shim.


Xen-devel mailing list



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