The x86_64 abi has a legacy vsyscall page. The kernel folk have been trying to deprecate this since at least v3.1, but
(1) We don't implement the vdso that replaces vsyscalls, (2) As of v5.5, the vsyscall page is still enabled by default. This lack is affecting Peter's linux-user testing. The dependency is not obvious because Peter is running the tests on x86_64, so the host is providing a vsyscall page to qemu. Because of how user-only memory operations are handled, with no validation of guest vs host pages, so long as qemu chooses to run with guest_base == 0, the guest may Just So Happen to read the host's vsyscall page. Complicating this, new OS releases may use a kernel configured with CONFIG_LEGACY_VSYSCALL_XONLY=y, which means the the vsyscall page cannot be read, only executed. Which means that the guest then cannot read the host vsyscall page during translation and will SIGSEGV. Exactly which of these many variables is affecting Peter's testing with Ubuntu 18.04 of my TCG merge, I'm not exactly sure. I suspect that it is the change to drop the textseg_addr adjustment to user-only static binaries. IIRC bionic does not support -static-pie, which is the preferred replacement. This could mean that the host and guest binaries overlap, which leads to guest_base != 0. I vaguely remember someone (Paolo?) implementing something like this many years ago, but clearly it never got merged. In any case, this emulation has been missing for too long. r~ Richard Henderson (3): target/i386: Renumber EXCP_SYSCALL linux-user/i386: Split out gen_signal linux-user/i386: Emulate x86_64 vsyscalls target/i386/cpu.h | 6 +- linux-user/i386/cpu_loop.c | 197 ++++++++++++++++++++++++++----------- target/i386/translate.c | 16 ++- 3 files changed, 155 insertions(+), 64 deletions(-) -- 2.20.1