Re: Arm64's xen.efi vs GNU binutils (and alike)

[Wei Chen <Wei.Chen@xxxxxxx>]

Hi Jan,

On 2022/7/11 22:32, Jan Beulich wrote:
> Hello,
>
> the other day I wanted to look at the basic structure of xen.efi. First
> I used my own dumping tool, which didn't work. Then I used objdump,
> which appeared to work. I decided that I should look into what they do
> different, and whether I could make mine work as well, or whether
> instead objdump is broken and shouldn't work on this sort of binary.
> While I'm not fully certain yet, I'm leaning to the latter. This is
> supported by GNU objcopy corrupting the binary (I assume this is known
> and considered okay-ish).
Did you use x86's objcopy? AArch64 GNU objcopy does not support any
PE format file. So I'm curious about the version of objcopy you are using.

> Many problems boil down to the (ab)use of the DOS executable header
> fields, yielding an invalid header. The first 8 bytes are instructions,
> with the first carefully chosen to produce 'MZ' in its low half.
> (Oddly enough Xen and Linux use different insns there.) This doesn't
> play well with the meaning of the respective fields in the DOS header.
UEFI executables are regular PE32/PE32+ images, Arm64 EFI applications 
use a subsystem "0xAA64". PE32/PE32+ require images to have a DOS header
for option#1 backwards compatibility,or option#2 to prevent images to be 
run in DOS. I think Arm64 EFI applications select option#2. In this case
I don't understand why we need a valid DOS header? For my understanding,
we just need 'MZ' for file type identify and "offset to the PE header".
Other fields have be re-used by other purpose when load Xen image as
binary. And lots of bootloaders are following this header format to load 
Xen (Linux, or other Arm64 OS/VMM) images. Therefore, it is not 
currently possible to construct a valid DOS header.
> Subsequently there are a number of .quad-s, some of which again yield
> an invalid DOS header. I'm therefore inclined to submit a patch to
> make objdump properly fail on this binary. But of course with both
I have not used objdump to dump xen image successfully. I always use
xen-syms for objdump.Sorry, Maybe I didn't understand your question clearly.

> Xen and Linux (and who knows who else) using this hairy approach, it
> may end up necessary to continue to "support" this special case,
> which is why I'm seeking your input here first.
Yes, like I said above, most OSs, VMMs and bootloaders currently follow 
this format and boot protocol. Therefore, it is difficult for us to 
completely remove it all at once.


> Furthermore the fake .reloc section overlaps the file header. The
> section is zero size (i.e. empty), but a reasonable PE loader might
> still object to its RVA being zero.
I am not very clear about "overlaps". Is it because we are setting
PointerToRelocations to zero?

Cheers,
Wei Chen

> As to objcopy: It shrinks the binary significantly in size, removes
> the dummy .reloc section, re-writes fair parts of the DOS header,
> and extends the NT header resulting in the file position of .text
> changing. The size reduction and possibly the movement of .text may
> be okay as long as the resulting binary is to only be used with UEFI
> (as it's due to zapping of the embedded DTB and the unnecessary zero-
> filling of .bss, afaict), but my understanding is that the other
> adjustments are all fatal to the usability of the binary even on
> UEFI.
>
> I may easily have forgotten further anomalies.
>
> Jan