From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932190AbcFTKIF (ORCPT ); Mon, 20 Jun 2016 06:08:05 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36289 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752070AbcFTKIB (ORCPT ); Mon, 20 Jun 2016 06:08:01 -0400 Subject: Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace To: Andy Lutomirski References: <94bda8cd5f326ae5591c80fb5d7c1c22624accec.1466244711.git.luto@kernel.org> Cc: Oleg Nesterov , Kees Cook , Borislav Petkov , "linux-kernel@vger.kernel.org" , X86 ML , Linus Torvalds , Jan Kratochvil , Pedro Alves From: Pedro Alves Message-ID: <177f65bb-dab9-9a1e-73a8-506904192bb2@palves.net> Date: Mon, 20 Jun 2016 11:07:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/18/2016 06:02 PM, Andy Lutomirski wrote: > Yuck. I should have dug in to the history. Why not just > unconditionally sign-extend eax when set by a 32-bit tracer? No idea. > > Do you know how to acquire a copy of erestartsys-trap.c? The old > links appear to be broken. That's part of the ptrace testsuite project, still in cvs, though the url changed: $ https://sourceware.org/systemtap/wiki/utrace/tests $ cvs -d :pserver:anoncvs:anoncvs@sourceware.org:/cvs/systemtap co ptrace-tests Can't seem to find a cvsweb interface for that. I think it'd be great to move these to the selftests infrastructure directly in the kernel tree. However, nobody's has ever managed to find energy for that. > > Also, while I have your attention: when gdb restores old state like > this, does it do it with individual calls to PTRACE_POKEUSER or does > it use SETREGSET or similar to do it all at once? I'm asking because > I have some other code (fsgsbase) that's on hold until I can figure > out how to keep it from breaking gdb if and when gdb writes to fs and > fs_base. > It depends on which register you're accessing, and on kernel version. But on a recent kernel, it should be using PTRACE_SETREGS / PTRACE_SETREGSET, thus storing a whole register set in one go. (And it's likely we could get rid of PTRACE_POKE fallback paths by now.) To write to the debug registers (dr0-dr7), PTRACE_POKEUSER is always used. There's code that coordinates with glibc's libthread_db.so that ends up _reading_ fs_base/gs_base, and gdb uses PTRACE_PEEKUSER for that, though there's a pending series that changes it, exposing fs_base/gs_base as just another register in gdb's register cache: https://www.sourceware.org/ml/gdb-patches/2015-11/msg00076.html https://www.sourceware.org/ml/gdb-patches/2015-11/msg00077.html Guess that makes fs_base/gs_base user-writable, if the kernel allows it. Thanks, Pedro Alves