[PATCH][gdb/server] Don't overwrite fs/gs_base with -m32
Simon Marchi
simon.marchi@polymtl.ca
Wed Jan 20 15:02:53 GMT 2021
On 2021-01-20 7:59 a.m., Tom de Vries wrote:
> Hi,
>
> Consider a minimal test-case test.c:
> ...
> int main (void) { return 0; }
> ...
> compiled with -m32:
> ...
> $ gcc test.c -m32
> ...
>
> When running the exec using gdbserver on openSUSE Factory (currently running a
> linux kernel version 5.10.5):
> ...
> $ gdbserver localhost:12345 a.out
> ...
> to which we connect in a gdb session, we run into a segfault in the inferior:
> ...
> $ gdb -batch -q -ex "target remote localhost:12345" -ex continue
> Program received signal SIGSEGV, Segmentation fault.
> 0xf7dd8bd2 in init_cacheinfo () at ../sysdeps/x86/cacheinfo.c:761
> ...
>
> The segfault is caused by gdbserver overwriting $gs_base with 0 using
> PTRACE_SETREGS. After it is overwritten, the next use of $gs in the inferior
> will trigger the segfault.
>
> Before linux kernel version 5.9, the value used by PTRACE_SETREGS for $gs_base
> was ignored, but starting version 5.9, the linux kernel has support for
> intel architecture extension FSGSBASE, which allows users to modify $gs_base,
> and consequently PTRACE_SETREGS can no longer ignore the $gs_base value.
>
> The overwrite of $gs_base with 0 is done by a memset in x86_fill_gregset,
> which was added in commit 9e0aa64f551 "Fix gdbserver qGetTLSAddr for
> x86_64 -m32". The memset intends to zero-extend 32-bit registers that are
> tracked in the regcache to 64-bit when writing them into the PTRACE_SETREGS
> data argument. But in addition, it overwrites other registers that are
> not tracked in the regcache, such as $gs_base.
>
> Fix the segfault by redoing the fix from commit 9e0aa64f551 in minimal form.
>
> Tested on x86_64-linux:
> - openSUSE Leap 15.2 (using kernel version 5.3.18):
> - native
> - gdbserver -m32
> - -m32
> - openSUSE Factory (using kernel version 5.10.5):
> - native
> - m32
>
> Any comments?
>
> Thanks,
> - Tom
This looks good as far as I can tell, but please wait for Markus' to chime in as
well.
Simon
More information about the Gdb-patches
mailing list