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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Wed, Sep 20, 2017 at 10:10 AM, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
> 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