Bug#1069844: More debug info
Alex Bennée
alex.bennee at linaro.org
Fri Apr 26 17:10:11 BST 2024
On Fri, 26 Apr 2024 at 16:48, Julian Andres Klode <
julian.klode at canonical.com> wrote:
> On Thu, Apr 25, 2024 at 09:10:08PM +0100, Alex Bennée wrote:
> > Alex Bennée <alex.bennee at linaro.org> writes:
> >
> > > Julian Andres Klode <julian.klode at canonical.com> writes:
> > >
> > >> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
> > >>>
> > >>> Continuing to debug on QEMU it seems there is an incompatibility with
> > >>> the images and the peloader (which overrides the normal efi loader):
> > >>>
> > <snip>
> > >
> > >> In the error case you can see though, that one of the section
> > >> addresses in the Xen binary to be relocated points into the (PE)
> > >> header of the binary, which obviously seems wrong.
> > >>
> > >> So go check your PE sections and check which one is wrong?
> > >
> > > Is there any tooling for examining PE sections?
> >
> > Nothing really jumps out from objdump:
> >
> > 1:08:50 [root at debian-arm64:~] # objdump -h /boot/xen
> >
> > /boot/xen: file format pei-aarch64-little
> >
> > Sections:
> > Idx Name Size VMA LMA File
> off Algn
> > 0 .reloc 00000000 0000000000000000 0000000000000000
> 00000000 2**0
> > ALLOC, LOAD, READONLY, DATA
>
>
> This looks suspicious. Yes it's 0 size but it's address is 0 which
> clearly points into the header, and we don't skip 0 size sections when
> loading the PE binary for later relocation, and we don't use any .reloc
> section.
>
It does get skipped in the reloc code:
if (!info->reloc || !(info->reloc->size))
{
grub_dprintf ("linux", "no relocations\n");
return GRUB_EFI_SUCCESS;
}
Although the x86_64 build of Xen uses reloc sections (which Xen itself
deals with) we don't actually need them for Arm. However the way the PE
binary is built is a little funky:
make
UPD include/xen/compile.h
Xen 4.19-unstable
make[1]: Nothing to be done for 'include'.
make[1]: 'arch/arm/include/asm/asm-offsets.h' is up to date.
CC common/version.o
LD common/built_in.o
CC arch/arm/acpi/domain_build.o
INIT_O arch/arm/acpi/domain_build.init.o
LD arch/arm/acpi/built_in.o
CC arch/arm/domain_build.o
INIT_O arch/arm/domain_build.init.o
CC arch/arm/efi/boot.o
INIT_O arch/arm/efi/boot.init.o
LD arch/arm/efi/built_in.o
CC arch/arm/setup.o
LD arch/arm/built_in.o
LD prelink.o
ld -EL --no-warn-rwx-segments --fix-cortex-a53-843419 -T
arch/arm/xen.lds -N prelink.o \
./common/symbols-dummy.o -o ./.xen-syms.0
nm -pa --format=sysv ./.xen-syms.0 \
| ./tools/symbols --sysv --sort \
> ./.xen-syms.0.S
make -f ./Rules.mk obj=. ./.xen-syms.0.o
CC .xen-syms.0.o
ld -EL --no-warn-rwx-segments --fix-cortex-a53-843419 -T
arch/arm/xen.lds -N prelink.o \
./.xen-syms.0.o -o ./.xen-syms.1
nm -pa --format=sysv ./.xen-syms.1 \
| ./tools/symbols --sysv --sort \
> ./.xen-syms.1.S
make -f ./Rules.mk obj=. ./.xen-syms.1.o
CC .xen-syms.1.o
ld -EL --no-warn-rwx-segments --fix-cortex-a53-843419 -T
arch/arm/xen.lds -N prelink.o --build-id=sha1 \
./.xen-syms.1.o -o xen-syms
nm -pa --format=sysv xen-syms \
| ./tools/symbols --all-symbols --xensyms --sysv --sort \
> xen-syms.map
rm -f ./.xen-syms.[0-9]*
objcopy -O binary -S xen-syms xen
ln -sf xen xen.efi
I can't work out how to build without the reloc section and trying to
remove the .reloc section after the fact results in something where the
file-offset is ahead of the VMA position:
➜ objcopy --remove-section=.reloc -O binary -S xen-syms xen-test
🕙17:03:23 alex at gwenyn:xen.git/xen on testing/new-attempt:new-attempt
[!?]
➜ objdump -h xen-test
xen-test: file format pei-aarch64-little
Sections:
Idx Name Size VMA LMA File off
Algn
0 .reloc 00000000 0000000000000000 0000000000000000 00000000
2**0
ALLOC, LOAD, READONLY, DATA
1 .text 00127ea8 0000000000000160 0000000000000160 00000160
2**4
CONTENTS, ALLOC, LOAD, CODE
🕙17:03:25 alex at gwenyn:xen.git/xen on testing/new-attempt:new-attempt
[!?]
➜ objcopy --remove-section=.reloc xen-test
🕙17:03:37 alex at gwenyn:xen.git/xen on testing/new-attempt:new-attempt
[!?]
➜ objdump -h xen-test
xen-test: file format pei-aarch64-little
Sections:
Idx Name Size VMA LMA File off
Algn
0 .text 00127ea8 0000000000000160 0000000000000160 000001b0
2**2
CONTENTS, ALLOC, LOAD, CODE
>
> > 1 .text 00107ea8 0000000000000160 0000000000000160
> 00000160 2**4
> > CONTENTS, ALLOC, LOAD, CODE
> > 21:08:53 [root at debian-arm64:~] # objdump -h /boot/vmlinuz
>
>
> I suppose the header is smaller than 0x160 bytes and this is ok.
>
> My colleague Heinrich has written a nice PE analyser tool too:
>
> https://github.com/xypron/efi_analyzer
That seems pretty happy with the binary:
/home/alex/lsrc/xen.git/xen/xen.efi
Offset to PE: 0x40
Machine type: 0xaa64, ARM64 little endian
NumberOfSymbols should be 0.
Characteristics: 0x0206
* The file is executable.
* COFF line numbers were stripped from the file.
* Debugging information was removed.
LinkerVersion 2.20
BaseOfCode: 0x160
AddressOfEntryPoint: 0xe8c20
Image type: PE32+
Subsystem: EFI application
DLL Characteristics: 0x0000
ImageBase: 0x0
SectionAlignment: 0x1000
FileAlignment: 0x8
SizeOfImage: 0x175000
.reloc.address: 0x0
.reloc.size: 0x0
Number data tables: 6
Exports : 0x00000000 - 0x00000000
Imports : 0x00000000 - 0x00000000
Resources : 0x00000000 - 0x00000000
Exceptions : 0x00000000 - 0x00000000
Certificates : 0x00000000 - 0x00000000
Base Relocations : 0x00000000 - 0x00000000
Number of sections: 2
Section[0]: .reloc
Virtual size: 0x0
Virtual address: 0x0
Size of raw data: 0x0
Pointer to raw data: 0x0
End of raw data: 0x0
Characteristics: 0x42000040
* The section contains initialized data.
* The section can be discarded as needed.
* The section can be read.
* Align data on a 1 byte boundary.
Section[1]: .text
Virtual size: 0x174ea0
Virtual address: 0x160
Size of raw data: 0x127ea8
Pointer to raw data: 0x160
End of raw data: 0x128008
Characteristics: 0xe0000020
* The section contains executable code.
* The section can be executed as code.
* The section can be read.
* The section can be written to.
* Align data on a 16 byte boundary.
I'm going to continue to see if I can improve the way Xen builds its EFI
blob but I think the validation code should just skip zero length sections.
>
>
>
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer i speak de, en
>
--
Alex Bennée
Emulation and Virtualisation Tech Lead @ Linaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grub-devel/attachments/20240426/d5b2d758/attachment-0001.htm>
More information about the Pkg-grub-devel
mailing list