Re: [PATCH v4 3/3] x86: Align output sections for UEFI CA memory mitigation requirements

[Jan Beulich <jbeulich@suse.com>]

On 24.09.2024 12:22, Frediano Ziglio wrote:
> There are indeed some oddities in the final executable(s):
> 
> From "objdump -x":
> 
> xen/normal/xen.efi:     file format pei-x86-64
> xen/normal/xen.efi
> architecture: i386:x86-64, flags 0x0000013b:
> HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED
> start address 0xffff82d04062bfdc
> ...
> The Data Directory
> Entry 0 0000000000000000 00000000 Export Directory [.edata (or where
> ever we found it)]
> Entry 1 0000000000000000 00000000 Import Directory [parts of .idata]
> Entry 2 0000000000000000 00000000 Resource Directory [.rsrc]
> Entry 3 0000000000000000 00000000 Exception Directory [.pdata]
> Entry 4 0000000000000000 00000000 Security Directory
> Entry 5 00000000009489a0 000016c0 Base Relocation Directory [.reloc]
> Entry 6 00000000004871c8 0000001c Debug Directory
> Entry 7 0000000000000000 00000000 Description Directory
> Entry 8 0000000000000000 00000000 Special Directory
> ...
> There is a debug directory in .buildid at 0xffff82d0404871c8
> ...
> Sections:
> Idx Name          Size      VMA               LMA               File off  Algn
>  0 .text         0018c5f6  ffff82d040200000  ffff82d040200000  00001000  2**4
>                  CONTENTS, ALLOC, LOAD, CODE
>  1 .rodata       000871c8  ffff82d040400000  ffff82d040400000  0018e000  2**2
>                  CONTENTS, ALLOC, LOAD, DATA
>  2 .buildid      00000035  ffff82d0404871c8  ffff82d0404871c8  002151e0  2**2
>                  CONTENTS, ALLOC, LOAD, READONLY, DATA
>  3 .init.text    0004775b  ffff82d040600000  ffff82d040600000  00215220  2**2
>                  CONTENTS, ALLOC, LOAD, READONLY, CODE
> ....
> 
> Some notes:
> 1- I don't understand why the debug directory points to .buildid section
>   (I suppose that's the reason for the "There is a debug directory..." message);

Like in ELF final executables, in PE ones information like this should
be locatable by means other than looking up sections by name and then
hoping they contain what's expected. Short of program headers and
dynamic tags, this is the scheme people invented to make the build ID
actually locatable. If you look at how this works in our build system,
you'll find that this even requires passing a COFF object to the linker
(i.e. involving a little bit of trickery).

> 2- .buildid follows .rodata (this is expected);
> 3- .buildid is not page aligned but the loader I tried seems to be
> happy with that,
>   I think it should be aligned;

Generally it doesn't need to be. If the secure boot stuff requires it
to be, then we need to live with that (and the wasted page). Preferably
it could continue to use (in the common case) a few bytes on the last
.rodata page. Or we could see whether folding .buildid into .rodata
works (I don't recall whether I tried that back at the time).

> 4- .rodata for some reason is not marked as READONLY, even on ELF you
> get the same issue.

I can confirm this oddity, without having an explanation. It must be
one of the inputs; I've checked that prelink.o's .rodata is r/o. So it
can only be some other constituent.

Jan