lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 12 Jan 2021 08:53:53 -0800 From: Andy Lutomirski <luto@...nel.org> To: "Metzger, Markus T" <markus.t.metzger@...el.com> Cc: "Bae, Chang Seok" <chang.seok.bae@...el.com>, Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>, "tdevries@...e.com" <tdevries@...e.com>, x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org> Subject: Re: gdbserver + fsgsbase kaputt On Tue, Jan 12, 2021 at 3:39 AM Metzger, Markus T <markus.t.metzger@...el.com> wrote: > > > The GDB behavior looks to be different between the two cases -- with vs > > without gdb server, when I checked the GS/GSBASE values on the ptrace front. > > 64-bit GDB doesn't support FSGSBASE for 32-bit inferiors and it looks like gdbserver > might not support FSGSBASE, at all. > > I had added support for the former as part of the tests I wrote about a year ago [1] > but never submitted the patch. Was the discussion ever concluded? > > The general behavior should be that GDB reads a regset, overwrites the registers it > knows about, and writes it back again to preserve the original values of registers it > doesn't know about. > > When I log the values that are read and written for FSGSBASE, however, it looks like > ptrace is returning a non-zero GS_BASE on a read and gdbserver is writing zero on > the next write. I instrumented the kernel, and I see: [ 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. --Andy
Powered by blists - more mailing lists