Re: [PATCH][gdb/server] Don't overwrite fs/gs_base with -m32

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

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