From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1AB4C433E6 for ; Thu, 4 Feb 2021 15:41:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7648864F48 for ; Thu, 4 Feb 2021 15:41:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237509AbhBDPlO (ORCPT ); Thu, 4 Feb 2021 10:41:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:59230 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237167AbhBDPhH (ORCPT ); Thu, 4 Feb 2021 10:37:07 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id CAE2064F3C; Thu, 4 Feb 2021 15:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612452980; bh=V2+LJ8z1KQnNgpVRjLeJbDwIcI5psNklwq0UR+e71Wo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jlhYQNe7yZFHun18Iv/OtdC4lYOA60k12RugBYQGdC4Tj78W9V84V84pyZZmTGs12 9ZjhJIaW4p1uqsuoNshWx4ZtTcrNi8EXT/XDAbcDXA/2yavrKD47ZSFItuKSnU+9o9 G1NN7Rbex/GdwzlhEXOjnUTxXtGKSXFEmd/4g/iSUbVQPfm3c+SaxlaFKfzysmFNo2 Of3a527jfeyY0PVkAHafTs69zccRXsa4rMaRcxnXkVLLtQkJ++yhy44bmvw8EHAG6q Q0w7yrU9JyeRlids1I3QvQkUxAti3EcHLWtEtg0jZdkjZ3Fmcf6Wf2L0aeh3AW/4pl JqVavM4fpD1Mw== Date: Thu, 4 Feb 2021 15:36:15 +0000 From: Will Deacon To: Andrei Vagin Cc: Catalin Marinas , Oleg Nesterov , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Anthony Steinhauser , Dave Martin , Keno Fischer Subject: Re: [PATCH 2/3] arm64/ptrace: introduce PTRACE_O_ARM64_RAW_REGS Message-ID: <20210204153615.GB21058@willie-the-truck> References: <20210201194012.524831-1-avagin@gmail.com> <20210201194012.524831-3-avagin@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210201194012.524831-3-avagin@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 01, 2021 at 11:40:11AM -0800, Andrei Vagin wrote: > We have some ABI weirdness in the way that we handle syscall > exit stops because we indicate whether or not the stop has been > signalled from syscall entry or syscall exit by clobbering a general > purpose register (ip/r12 for AArch32, x7 for AArch64) in the tracee > and restoring its old value after the stop. > > This behavior was inherited from ARM and it isn't common for other > architectures. Now, we have PTRACE_GET_SYSCALL_INFO that gives all > required information about system calls, so the hack with clobbering > registers isn't needed anymore. > > This change adds the new ptrace option PTRACE_O_ARM64_RAW_REGS. If it > is set, PTRACE_GETREGSET returns values of all registers without > clobbering r12 or x7 and PTRACE_SETREGSE sets all registers even if a > process has been stopped in syscall-enter or syscall-exit. > > Signed-off-by: Andrei Vagin > --- > arch/arm64/include/uapi/asm/ptrace.h | 4 ++ > arch/arm64/kernel/ptrace.c | 70 ++++++++++++++++------------ > include/linux/ptrace.h | 1 + > include/uapi/linux/ptrace.h | 9 +++- > 4 files changed, 52 insertions(+), 32 deletions(-) Please split this up so that the arm64-specific changes are separate to the core changes. > diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h > index 83ee45fa634b..bcc8c362ddd9 100644 > --- a/include/uapi/linux/ptrace.h > +++ b/include/uapi/linux/ptrace.h > @@ -7,6 +7,7 @@ > /* has the defines to get at the registers. */ > > #include > +#include > > #define PTRACE_TRACEME 0 > #define PTRACE_PEEKTEXT 1 > @@ -137,8 +138,14 @@ struct ptrace_syscall_info { > #define PTRACE_O_EXITKILL (1 << 20) > #define PTRACE_O_SUSPEND_SECCOMP (1 << 21) > > +/* (1<<28) is reserved for arch specific options. */ > +#ifndef _PTRACE_O_ARCH_OPTIONS > +#define _PTRACE_O_ARCH_OPTIONS 0 > +#endif It seems a bit fragile to rely on a comment here to define the user ABI; why not define _PTRACE_O_ARCH_OPTIONS to the right value unconditionally? Also, it seems as though we immediately burn this bit on arm64, so if we ever wanted another option we'd have to come back here and allocate another bit. Could we do better, e.g. by calling into an arch hook (arch_ptrace_setoptions()) and passing the 'addr' parameter? How do other architectures manage this sort of thing? I'm wondering whether a separate regset containing just "real x7" and orig_x0 would be preferable after all... Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 845F3C433E0 for ; Thu, 4 Feb 2021 15:37:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3EDC464DEB for ; Thu, 4 Feb 2021 15:37:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3EDC464DEB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6n+OM09QNzeD3paAOsko52z79vIrvc3UrWODh2OjvYk=; b=m8VzcLoFRZgF5GmOaJlkHDD9x B4lyUaElouec5RkO+uuHbtkqPB1D8UEy07beC7YXofkanyeED1vSAvh+/xWJbgqHYrOeNelbhUYLf AOk5BWDJoV40WlpWA7v3n6TbQV1ZEWTijJDXwBRJlH/O3DA4E6SdLdcfSJ4M3pijswAs7pL9/9qnu J6v8Mb9B+bty/uUD/nx02WwCxsIDXmjqhMJE1hlrmk3HU5zLo2lracj41o0aWdTYoB2gIbz/KDFeO tz/hgglPlaSfnBrSDxrNZmO79g0Eed4WjSKLTjCWymhI9/65lW4NPTO4AVhNAiNSTtsC207ngWByx Or3va5MjA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7ggC-000485-Dh; Thu, 04 Feb 2021 15:36:24 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7gg9-000474-1t for linux-arm-kernel@lists.infradead.org; Thu, 04 Feb 2021 15:36:22 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id CAE2064F3C; Thu, 4 Feb 2021 15:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612452980; bh=V2+LJ8z1KQnNgpVRjLeJbDwIcI5psNklwq0UR+e71Wo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jlhYQNe7yZFHun18Iv/OtdC4lYOA60k12RugBYQGdC4Tj78W9V84V84pyZZmTGs12 9ZjhJIaW4p1uqsuoNshWx4ZtTcrNi8EXT/XDAbcDXA/2yavrKD47ZSFItuKSnU+9o9 G1NN7Rbex/GdwzlhEXOjnUTxXtGKSXFEmd/4g/iSUbVQPfm3c+SaxlaFKfzysmFNo2 Of3a527jfeyY0PVkAHafTs69zccRXsa4rMaRcxnXkVLLtQkJ++yhy44bmvw8EHAG6q Q0w7yrU9JyeRlids1I3QvQkUxAti3EcHLWtEtg0jZdkjZ3Fmcf6Wf2L0aeh3AW/4pl JqVavM4fpD1Mw== Date: Thu, 4 Feb 2021 15:36:15 +0000 From: Will Deacon To: Andrei Vagin Subject: Re: [PATCH 2/3] arm64/ptrace: introduce PTRACE_O_ARM64_RAW_REGS Message-ID: <20210204153615.GB21058@willie-the-truck> References: <20210201194012.524831-1-avagin@gmail.com> <20210201194012.524831-3-avagin@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210201194012.524831-3-avagin@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210204_103621_254293_93B2C73A X-CRM114-Status: GOOD ( 21.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Anthony Steinhauser , Catalin Marinas , Oleg Nesterov , linux-kernel@vger.kernel.org, Keno Fischer , linux-api@vger.kernel.org, Dave Martin , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 01, 2021 at 11:40:11AM -0800, Andrei Vagin wrote: > We have some ABI weirdness in the way that we handle syscall > exit stops because we indicate whether or not the stop has been > signalled from syscall entry or syscall exit by clobbering a general > purpose register (ip/r12 for AArch32, x7 for AArch64) in the tracee > and restoring its old value after the stop. > > This behavior was inherited from ARM and it isn't common for other > architectures. Now, we have PTRACE_GET_SYSCALL_INFO that gives all > required information about system calls, so the hack with clobbering > registers isn't needed anymore. > > This change adds the new ptrace option PTRACE_O_ARM64_RAW_REGS. If it > is set, PTRACE_GETREGSET returns values of all registers without > clobbering r12 or x7 and PTRACE_SETREGSE sets all registers even if a > process has been stopped in syscall-enter or syscall-exit. > > Signed-off-by: Andrei Vagin > --- > arch/arm64/include/uapi/asm/ptrace.h | 4 ++ > arch/arm64/kernel/ptrace.c | 70 ++++++++++++++++------------ > include/linux/ptrace.h | 1 + > include/uapi/linux/ptrace.h | 9 +++- > 4 files changed, 52 insertions(+), 32 deletions(-) Please split this up so that the arm64-specific changes are separate to the core changes. > diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h > index 83ee45fa634b..bcc8c362ddd9 100644 > --- a/include/uapi/linux/ptrace.h > +++ b/include/uapi/linux/ptrace.h > @@ -7,6 +7,7 @@ > /* has the defines to get at the registers. */ > > #include > +#include > > #define PTRACE_TRACEME 0 > #define PTRACE_PEEKTEXT 1 > @@ -137,8 +138,14 @@ struct ptrace_syscall_info { > #define PTRACE_O_EXITKILL (1 << 20) > #define PTRACE_O_SUSPEND_SECCOMP (1 << 21) > > +/* (1<<28) is reserved for arch specific options. */ > +#ifndef _PTRACE_O_ARCH_OPTIONS > +#define _PTRACE_O_ARCH_OPTIONS 0 > +#endif It seems a bit fragile to rely on a comment here to define the user ABI; why not define _PTRACE_O_ARCH_OPTIONS to the right value unconditionally? Also, it seems as though we immediately burn this bit on arm64, so if we ever wanted another option we'd have to come back here and allocate another bit. Could we do better, e.g. by calling into an arch hook (arch_ptrace_setoptions()) and passing the 'addr' parameter? How do other architectures manage this sort of thing? I'm wondering whether a separate regset containing just "real x7" and orig_x0 would be preferable after all... Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel