From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932091AbcFUQdU (ORCPT ); Tue, 21 Jun 2016 12:33:20 -0400 Received: from mail-vk0-f53.google.com ([209.85.213.53]:34008 "EHLO mail-vk0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752058AbcFUQdR (ORCPT ); Tue, 21 Jun 2016 12:33:17 -0400 MIME-Version: 1.0 In-Reply-To: References: <6347a4fe9e8c67d511e7b8a68e8ee5ffb02ca968.1466464928.git.luto@kernel.org> From: Andy Lutomirski Date: Tue, 21 Jun 2016 09:32:23 -0700 Message-ID: Subject: Re: [PATCH v3 2/3] x86/signal: Rewire the restart_block() syscall to have a constant nr To: Pedro Alves Cc: Oleg Nesterov , Kees Cook , Borislav Petkov , "linux-kernel@vger.kernel.org" , X86 ML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Jun 21, 2016 5:40 AM, "Pedro Alves" wrote: > > Hi Andy, > > On 06/21/2016 12:39 AM, Andy Lutomirski wrote: > > Suppose a 64-bit task A traces a 32-bit task B. > > I gave your x86/ptrace branch a try: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/ptrace > > (this looks to be the same patch set.) > > Unfortunately, with gdb git master, I still get the > 64-bit ptracer x 32-bit ptracee problem: > > (gdb) r > Starting program: interrupt.32 > talk to me baby > ^C I didn't try that particular experiment. But, from that email: > After that, GDB can control the stopped inferior. To call function "func1()" of inferior, GDB need: Step 1, save current values of registers ($rax 0xfffffffffffffe00(64 bits -512) is cut to 0xfffffe00(32 bits -512) because inferior is a 32 bits program). That sounds like it may be a gdb bug. Why does gdb truncate the register? I haven't played with it recently, but, in my experience, gdb seems to work quite poorly in mixed-mode situations. For example, if you attach 64-bit gdb to qemu-system-x86_64's gdbserver, boot a 64-bit guest, and breakpoint in early 32-bit code, gdb tends to explode pretty badly. On x86_64, I think gdb should treat CPU state as 64-bit no matter what. The fact that a 32-bit tracee code segment is in use shouldn't change much. Admittedly the kernel doesn't really help. There is some questionable code involving which regsets to show to ptrace.