Re: [PATCH v3] xen: Strip xen.efi by default

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 5463 bytes --]

On 11/6/25 05:28, Jan Beulich wrote:
> On 06.11.2025 10:58, Frediano Ziglio wrote:
>> On Thu, 6 Nov 2025 at 03:52, Demi Marie Obenour <demiobenour@gmail.com> wrote:
>>> Does objdump on the signed file return correct section names?
>>
>> From objdump -x
>>
>> Sections:
>> Idx Name          Size      VMA               LMA               File off  Algn
>>   0 .text         0016c9ae  ffff82d040200000  ffff82d040200000  00000320  2**4
>>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>>   1 .rodata       0006b9e8  ffff82d040400000  ffff82d040400000  0016cce0  2**2
>>                   CONTENTS, ALLOC, LOAD, DATA
>>   2 .buildid      00000035  ffff82d04046c000  ffff82d04046c000  001d86e0  2**2
>>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>>   3 .init.text    0004d123  ffff82d040600000  ffff82d040600000  001d8720  2**2
>>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>>   4 .init.data    0006c9b0  ffff82d040800000  ffff82d040800000  00225860  2**2
>>                   CONTENTS, ALLOC, LOAD, DATA
>>   5 .data.read_mostly 00028da8  ffff82d040a00000  ffff82d040a00000
>> 00292220  2**4
>>                   CONTENTS, ALLOC, LOAD, DATA
>>   6 .data         0000feec  ffff82d040a29000  ffff82d040a29000  002bafe0  2**4
>>                   CONTENTS, ALLOC, LOAD, DATA
>>   7 .bss          00223108  ffff82d040a39000  ffff82d040a39000  00000000  2**4
>>                   ALLOC
>>   8 .reloc        000016b8  ffff82d040c5d000  ffff82d040c5d000  002caee0  2**2
>>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>>   9 .sbat         000000a6  ffff82d040c5f000  ffff82d040c5f000  002cc5a0  2**2
>>                   CONTENTS, READONLY
>>
>> Which looks correct.
>>
>> From hexdump -C I can see close to the end
>>
>> ...
>> 002cc580  30 ae 38 ae 60 ae 00 00  00 80 a3 00 10 00 00 00  |0.8.`...........|
>> 002cc590  a0 ae c0 ae e0 ae 00 00  00 00 00 00 00 00 00 00  |................|
>> 002cc5a0  73 62 61 74 2c 31 2c 53  42 41 54 20 56 65 72 73  |sbat,1,SBAT Vers|
>> 002cc5b0  69 6f 6e 2c 73 62 61 74  2c 31 2c 68 74 74 70 73  |ion,sbat,1,https|
>> 002cc5c0  3a 2f 2f 67 69 74 68 75  62 2e 63 6f 6d 2f 72 68  |://github.com/rh|
>> 002cc5d0  62 6f 6f 74 2f 73 68 69  6d 2f 62 6c 6f 62 2f 6d  |boot/shim/blob/m|
>> 002cc5e0  61 69 6e 2f 53 42 41 54  2e 6d 64 0a 78 65 6e 2e  |ain/SBAT.md.xen.|
>> 002cc5f0  78 73 2c 31 2c 43 6c 6f  75 64 20 53 6f 66 74 77  |xs,1,Cloud Softw|
>> 002cc600  61 72 65 20 47 72 6f 75  70 2c 78 65 6e 2c 34 2e  |are Group,xen,4.|
>> 002cc610  32 30 2e 31 2d 37 2e 32  32 2e 67 33 65 30 36 37  |20.1-7.22.g3e067|
>> 002cc620  32 36 62 2e 78 73 39 2c  6d 61 69 6c 74 6f 3a 73  |26b.xs9,mailto:s|
>> 002cc630  65 63 75 72 69 74 79 40  78 65 6e 73 65 72 76 65  |ecurity@xenserve|
>> 002cc640  72 2e 63 6f 6d 0a 00 00  00 00 00 00 00 00 00 00  |r.com...........|
>> 002cc650  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>> 002cc660  2c 00 00 00 2e 69 6e 69  74 2e 74 65 78 74 00 2e  |,....init.text..|
>> 002cc670  69 6e 69 74 2e 64 61 74  61 00 2e 64 61 74 61 2e  |init.data..data.|
>> 002cc680  72 65 61 64 5f 6d 6f 73  74 6c 79 00 00 00 00 00  |read_mostly.....|
>> 002cc690  9e 05 00 00 00 02 02 00  30 82 05 92 06 09 2a 86  |........0.....*.|
>> 002cc6a0  48 86 f7 0d 01 07 02 a0  82 05 83 30 82 05 7f 02  |H..........0....|
>> 002cc6b0  01 01 31 0f 30 0d 06 09  60 86 48 01 65 03 04 02  |..1.0...`.H.e...|
>> 002cc6c0  01 05 00 30 5c 06 0a 2b  06 01 04 01 82 37 02 01  |...0\..+.....7..|
>> 002cc6d0  04 a0 4e 30 4c 30 17 06  0a 2b 06 01 04 01 82 37  |..N0L0...+.....7|
>> 002cc6e0  02 01 0f 30 09 03 01 00  a0 04 a2 02 80 00 30 31  |...0..........01|
>> 002cc6f0  30 0d 06 09 60 86 48 01  65 03 04 02 01 05 00 04  |0...`.H.e.......|
>> 002cc700  20 e2 47 64 f8 e8 7b 62  eb 17 e0 13 0a 0d 93 02  | .Gd..{b........|
>> 002cc710  7a d8 3b f0 20 a8 ee 3d  49 98 3f de c1 47 de 15  |z.;. ..=I.?..G..|
>> 002cc720  43 a0 82 03 2c 30 82 03  28 30 82 02 10 a0 03 02  |C...,0..(0......|
>> 002cc730  01 02 02 11 00 8f fc 11  bf 41 54 40 74 89 2c 53  |.........AT@t.,S|
>> 002cc740  a5 78 c1 e8 32 30 0d 06  09 2a 86 48 86 f7 0d 01  |.x..20...*.H....|
>> 002cc750  01 0b 05 00 30 1c 31 1a  30 18 06 03 55 04 03 13  |....0.1.0...U...|
>> 002cc760  11 58 65 6e 53 65 72 76  65 72 20 58 65 6e 20 64  |.XenServer Xen d|
>> 002cc770  65 76 30 1e 17 0d 32 35  30 33 32 30 31 36 35 35  |ev0...2503201655|
>> 002cc780  30 37 5a 17 0d 33 37 30  31 31 39 30 33 31 34 30  |07Z..37011903140|
>> 002cc790  37 5a 30 1c 31 1a 30 18  06 03 55 04 03 13 11 58  |7Z0.1.0...U....X|
>> 002cc7a0  65 6e 53 65 72 76 65 72  20 58 65 6e 20 64 65 76  |enServer Xen dev|
>> ...
>>
>> So, this confirms that the string table is there to support larger
>> section names and the signature is there and it's working.
> 
> But is it going to work on all EFI implementations, or merely the one you tried?
> Of course it would help if Demi could give more concrete pointers to (possible)
> implementations where there might be (known? suspected?) issues.
> 
> Jan

I misread the PE hashing code in EDK2.  I assumed it mishandled the case where
there is data *between* the sections and the signature, but it actually mishandles
the case where there is data *after* the signature.  I'll file an EDK2 PR to
reject such images on the grounds that they could never have worked.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]