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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 12 Jan 2021 11:39:07 +0000 From: "Metzger, Markus T" <markus.t.metzger@...el.com> To: "Bae, Chang Seok" <chang.seok.bae@...el.com>, "Lutomirski, Andy" <luto@...capital.net> CC: 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 > 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. Chang, is that also what you were seeing? Regards, Markus. [1] https://lkml.org/lkml/2019/11/29/306 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
Powered by blists - more mailing lists