There are a number of resource leaks in gen-vdso. In theory they are
harmless because this is a short lived process, but when building QEMU
with --extra-cflags="-fsanitize=address" problems ensure. The gen-vdso
program is run as part of the build, and that aborts due to the
sanitizer identifying memory leaks, leaving QEMU unbuildable.
FAILED: libqemu-x86_64-linux-user.a.p/vdso.c.inc
/var/home/berrange/src/virt/qemu/build/linux-user/gen-vdso -o libqemu-x86_64-linux-user.a.p/vdso.c.inc ../linux-user/x86_64/vdso.so
=================================================================
==1696332==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 2968 byte(s) in 1 object(s) allocated from:
#0 0x56495873f1f3 (/var/home/berrange/src/virt/qemu/build/linux-user/gen-vdso+0xa11f3) (BuildId: b69e241ad44719b6f3934f3c71dfc6727e8bdb12)
#1 0x564958780b90 (/var/home/berrange/src/virt/qemu/build/linux-user/gen-vdso+0xe2b90) (BuildId: b69e241ad44719b6f3934f3c71dfc6727e8bdb12)
This complaint is about the 'buf' variable, however, the FILE objects
are also leaked in some error scenarios, so this fix refactors the
cleanup paths to fix all leaks. For completeness it also reports an
error if fclose() fails on 'inf'.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Arusekk <floss@arusekk.pl>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250513150346.1328217-1-berrange@redhat.com>
When debugging qemu-user processes using gdbstub, the following warning
appears every time:
warning: BFD: warning: system-supplied DSO at 0x7f8253cc3000 has a corrupt string table index
The reason is that QEMU does not map the VDSO's section headers. The
VDSO's ELF header's e_shoff points to zeros, which GDB fails to parse.
The difference with the kernel's VDSO is that the latter is mapped as a
blob, ignoring program headers - which also don't cover the section
table. QEMU, on the other hand, loads it as an ELF file.
There appears to be no way to place section headers inside a section,
and, therefore, no way to refer to them from a linker script. Also, ld
hardcodes section headers to be non-loadable, see
_bfd_elf_assign_file_positions_for_non_load(). In theory ld could be
enhanced by implementing an "SHDRS" keyword in addition to the existing
"FILEHDR" and "PHDRS".
There are multiple ways to resolve the issue:
- Copy VDSO as a blob in load_elf_vdso(). This would require creating
specialized loader logic, that duplicates parts of load_elf_image().
- Fix up VDSO's PHDR size in load_elf_vdso(). This would require either
duplicating the parsing logic, or adding an ugly parameter to
load_elf_image().
- Fix up VDSO's PHDR size in gen-vdso. This is the simplest solution,
so do it.
There are two tricky parts:
- Byte-swaps need to be done either on local copies, or in-place and
then reverted in the end. To preserve the existing code structure, do
the former for Sym and Dyn, and the latter for Ehdr, Phdr, and Shdr.
- There must be no .bss, which is already the case - but having an
explicit check is helpful to ensure correctness.
To verify this change, I diffed the on-disk and the loaded VDSOs; the
result does not show anything unusual, except for what seems to be an
existing oversight (which should probably be fixed separately):
│ Symbol table '.dynsym' contains 8 entries:
│ Num: Value Size Type Bind Vis Ndx Name
│ - 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
│ - 6: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.29
│ + 0: 00007f61075bf000 0 NOTYPE LOCAL DEFAULT UND
│ + 6: 00007f61075bf000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.29
Fixes: 2fa536d107 ("linux-user: Add gen-vdso tool")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20241023202850.55211-1-iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This tool will be used for post-processing the linked vdso image,
turning it into something that is easy to include into elfload.c.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
