On Wed, Sep 20, 2017 at 12:30 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>> On 20.09.17 at 00:23, <ta...@tklengyel.com> wrote: >> On Mon, Sep 18, 2017 at 2:58 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>>> On 14.09.17 at 18:20, <ta...@tklengyel.com> wrote: >>>> Of course, you can grab them from here: >>>> https://drive.google.com/drive/folders/0B5duyI9SzNtWaXE0cjM1QzZJbVk?usp=shar >>>> ing >>> >>> So the dumps of the two (using my own tool) are identical except for >>> the expected difference due to the certificate. In particular neither >>> image has any strange relocation types afaics, and both have the >>> sort of unexpected, but also supposedly benign >>> IMAGE_SCN_LNK_NRELOC_OVFL flag set for .bss. Hence I'm afraid ... >>> >>>> I've verified that xen-signed.efi boots with Secureboot enabled when >>>> booted directly but doesn't boot through the shim. >>> >>> ... you'll need to do some debugging in order to figure out what's >>> going on here. With the above the prime suspect is the shim though, >>> fiddling with the image after loading it into memory. So perhaps >>> dumping the .reloc section contents in order to compare it with >>> what's in the image may be a suitable approach. >> >> 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. > >> 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. 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). Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
