| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
These variables will be populated from the vdso, and used
for detecting whether we are executing the sigreturn.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In gen-vdso we load in a file and assume it's a valid ELF file. In
particular we assume it's big enough to be able to read the ELF
information in e_ident in the ELF header.
Add a check that the total file length is at least big enough for all
the e_ident bytes, which is good enough for the code in gen-vdso.c.
This will catch the most obvious possible bad input file (truncated)
and allow us to run the sanity checks like "not actually an ELF file"
without potentially crashing.
The code in elf32_process() and elf64_process() still makes
assumptions about the file being well-formed, but this is OK because
we only run it on the vdso binaries that we create ourselves in the
build process by running the compiler.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250710170707.1299926-3-peter.maydell@linaro.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Coverity points out that we don't check for fseek() failure in gen-vdso.c,
and so we might pass -1 to malloc(). Add the error checking.
(This is a standalone executable that doesn't link against glib, so
we can't do the easy thing and use g_file_get_contents().)
Coverity: CID 1523742
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250710170707.1299926-2-peter.maydell@linaro.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 2fa536d10797 ("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>
|