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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Wed, Sep 20, 2017 at 09:59:51AM -0600, Tamas K Lengyel wrote:
> 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 have played with Xen master in July and have not seen any issues.
I will take a stab at it probably next week.

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

Partial solution for your problem is Linux kernel module signing.

Daniel

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