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

(Sorry for the previous empty one).

I've managed to get initrd and the cmdline baked into linux and get
the whole thing verified by the shim. It's not perfect because now
updates are a bit more cumbersome to deliver but at least it works.
Linux kernel module signing would be a good way forward from here to
get the modules verified as well. Or the necessary modules could also
be baked into the kernel if known at compile time.

One piece that I see still missing is the Xen command line parameters
not being verified. It would be ideal to have the option to get that
set during compile time as well, similar to Linux's CONFIG_CMDLINE
option, to avoid for example getting iommu or XSM being turned off by
someone with physical access.

Tamas

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