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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Thu, Sep 14, 2017 at 12:06 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 14.09.17 at 17:43, <tamas@xxxxxxxxxxxxx> wrote:
>> On Wed, Sep 13, 2017 at 11:42 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 13.09.17 at 16:40, <tamas@xxxxxxxxxxxxx> wrote:
>>>> On Wed, Sep 13, 2017 at 3:21 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>>>> On 13.09.17 at 07:27, <tamas@xxxxxxxxxxxxx> wrote:
>>>>>>Sections:
>>>>>>Idx Name          Size      VMA               LMA               File off
>> Algn
>>>>>>  0 .text         0017a1ba  ffff82d080200000  ffff82d080200000  00001000
>> 2**12
>>>>>>                  CONTENTS, ALLOC, LOAD, CODE
>>>>>>  1 .rodata       000826a0  ffff82d080400000  ffff82d080400000  0017c000
>> 2**5
>>>>>>                  CONTENTS, ALLOC, LOAD, DATA
>>>>>>  2 .buildid      00000035  ffff82d0804826a0  ffff82d0804826a0  001fe6a0
>> 2**2
>>>>>>                  CONTENTS, ALLOC, LOAD, READONLY, DATA
>>>>>>  3 .init         00077df0  ffff82d080600000  ffff82d080600000  001ff000
>> 2**12
>>>>>>                  CONTENTS, ALLOC, LOAD, CODE, DATA
>>>>>>  4 .data.re      0000aa40  ffff82d080800000  ffff82d080800000  00277000
>> 2**7
>>>>>>                  CONTENTS, ALLOC, LOAD, DATA
>>>>>>  5 .data         000105a8  ffff82d08080b000  ffff82d08080b000  00282000
>> 2**12
>>>>>>                  CONTENTS, ALLOC, LOAD, DATA
>>>>>>  6 .bss          00143280  ffff82d080820000  ffff82d080820000  00000000
>> 2**4
>>>>>>                  ALLOC, RELOC
>>>>>
>>>>> Objdump is apparently ignoring a section attribute bit here - my
>>>>> own utility properly prints "bss" in addition to "read" (which presumably
>>>>> matches "ALLOC" above, albeit that's a bogus translation apparently
>>>>> applying ELF semantics to COFF). You'll want to check that bit 7 in the
>>>>> section attributes is set. I'm also puzzled by "RELOC", but I do see a
>>>>> matching bit dumped here; not sure why that's being set.
>>>>
>>>> Looking at it with readpe I get:
>>>>
>>>> Name:                            .bss
>>>> Virtual Address:                 0x820000
>>>> Physical Address:                0x143280
>>>> Size:                            0 (0 bytes)
>>>> Pointer To Data:                 0
>>>> Relocations:                     0
>>>> Characteristics:                 0xc1000080
>>>>                                  contains uninitialized data
>>>>                                  contains extended relocations
>>>>                                  is readable
>>>>                                  is writable
>>>>
>>>> So bit 7 is set AFAICT.
>>>
>>> Good.
>>>
>>>>> It is certainly the case that .bss style sections are expected to have a
>>>>> zero file offset, as there's no data for such sections inside the file 
>>>>> (note
>>>>> the missing "CONTENTS" above. So I would conclude that, unless the
>>>>> bss flag really got lost, it's a shim loader bug. Since other people can
>>>>> load xen.efi with the shim, that might be a problem with the particular
>>>>> version you're using.
>>>>
>>>> Perhaps, I'm using the latest master
>>>> (e22a7b5b772dba6588dd955dc017e572f7e29784) from
>>>> https://github.com/mjg59/shim, the one being linked to on the wiki. If
>>>> there is a known good version, I would be happy to give that a shot
>>>> and see if I can get it working.
>>>
>>> I have no idea. What I'd suggest you to try is to zap that stray
>>> "contains extended relocations" flag. I've written down to go hunt
>>> for where it comes from, but I don't have the time to do that right
>>> away.
>>
>> So I had made some progress using the shim from
>> https://github.com/rhboot/shim, it actually has been able to jump into
>> the signed xen.efi. However, Xen bails with the message "Unsupported
>> relocation type" which is in efi_arch_relocate_image.
>
> Iirc the dump you did send showed quite a few strange relocs;
> I wasn't sure whether these were just a result of the dumping
> utility not working well, but it now looks like the relocations
> really aren't right. Could you make available an un-signed
> xen.efi (which I understand works for you) and the corresponding
> signed one somewhere for analysis?
>

Of course, you can grab them from here:
https://drive.google.com/drive/folders/0B5duyI9SzNtWaXE0cjM1QzZJbVk?usp=sharing
I've verified that xen-signed.efi boots with Secureboot enabled when
booted directly but doesn't boot through the shim.

Tamas

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