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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

Jan


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