> From: Andy Lutomirski <l...@kernel.org> > > On Tue, Jan 12, 2021 at 9:02 AM Metzger, Markus T > <markus.t.metz...@intel.com> wrote: > > > > > [ 26.990644] getreg: gs_base = 0xf7f8e000 > > > [ 26.991694] getreg: GS=0x63, GSBASE=0xf7f8e000 > > > [ 26.993117] PTRACE_SETREGS > > > [ 26.993813] putreg: change gsbase from 0xf7f8e000 to 0x0 > > > [ 26.995134] putreg: write GS=0x63; old GSBASE=0x0 > > > [ 26.996235] PTRACE_SETREGS done > > > > > > That's gdbserver reading GS and GSBASE and then telling the kernel to > > > set GS to the same value and GSBASE to 0. > > > > > > I can come up with horrible kernel hacks to try to work around this, > > > but gdbserver is really giving the kernel bad instructions here. > > > > I agree that this looks like a GDB bug rather than a kernel bug. GDB > > should preserve the GS_BASE value if it doesn't intend to change it. > > Indeed. But we have this pesky no-userspace-regressions policy in the kernel. > > So the question I have is: is this enough of a regression that we need > to hack around it in the kernel? The specific broken use case seems > quite niche: 64-bit gdbserver targeting 32-bit userspace. It's taken > two-and-a-half kernel releases for anyone to notice, because sensible > people use plain gdb for local debugging and gdbserver for debugging > VMs, embedded targets, and such.
IMHO I'd just fix GDB and leave it at that. The kernel changes exposed a bug in gdbserver. Tom already submitted a fix. I'm wondering why we're considering some ugly hacks in the kernel for what's obviously a bug in user-space, yet ignore changes to GDB functionality (for changing FS/GS from within GDB) we had been discussing a year ago. Regards, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
