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=-10.7 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 AA48FC433E0 for ; Mon, 8 Feb 2021 18:34:40 +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 4B4FE64E37 for ; Mon, 8 Feb 2021 18:34:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B4FE64E37 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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=wuiaGwGex70KSKsv0p4VLefXbdODXr/MVpmUWP1alDg=; b=vjJKDvhemxfnl0nB1Exp2maBX nyf80umofOm3/VdB/cyVynqA5a5worsNQY3Ne42dveO8+XiBx+JdyWwr4w75NuF9TU/MfUMCxiPv+ UDSPGCR2I3RAqUeyNq92qhtl/WgdgT7Cy/Yo0pqPX/+nox8KWUs9V3Uf/L9lqWgF2rH2CinBn+kxM 9SLrjWrzStn4RPFVaSOOwiqM/whZTuBa2nvkUN0xNP01VpV70sgPa+ORC0UTR1jo5tPKw7sC15NfV TAPWChlUxxQJ1vxGIgpDnxO+WyctubiH1AqbWs4FPAwJIl+z37lj9HLGDE4NkLOXsymNzkG5AVfWi qKCqGa/kQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9BLn-0006EP-5c; Mon, 08 Feb 2021 18:33:31 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9BLj-0006DT-0u for linux-arm-kernel@lists.infradead.org; Mon, 08 Feb 2021 18:33:27 +0000 Received: by mail-pj1-x1029.google.com with SMTP id gb24so52182pjb.4 for ; Mon, 08 Feb 2021 10:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mEJZ0ZpLe5V+Hwesxu2Q7j9S4ixMQFc1RZqNUqFzFw0=; b=fzTC5UF811/9wmC0owcaUofLPqmABFbU2HydH3c5dfuWew7zwmzX4zc0EYdNyZnO5L vbEB1n4XNqx7cUrlUR+p4DDrYTYp4rorJL5m9DFH34aMBQC9IiXzcPskcySSBpkYn5o2 BPV9J7cm+O3flSeBj+pnYEGVkbCzzWN5iye/mof0BtJ7yHYHpVU7Rd648IYeJsEKffeF zpCYn2c6M0vIxLfLkIaLlAIGVUKUm4ejUZgFybMVkHqiJsqgmDRvHNSgNROrhzyKc/gh ik760cUSzTlZP8Mj7ek9IHdtjpR3Zeq9a+wPAXxq14mcQQ4hT2w3sHOFs7xHhRH/mCvO w7KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mEJZ0ZpLe5V+Hwesxu2Q7j9S4ixMQFc1RZqNUqFzFw0=; b=tWOAX5AozpTA6DvUDgB98RsP6Wp+3U9PDMvt8GIkS7uzrVkMevyJjRZUGagnfsmYDL lr7GjCBcd/VQyfaYNiCVHqCZFzDwM0BsCVQ0KbqW4d67OpY93/8iyhxtiTGa0JrYEzY4 1KuA+PwzxeMRhbHm9KEym0+6eQYauz3vBLWj6nI1bc3eaM3uxBOGtjbduvozj0D3/F7U 0lLEo2O3+glbN8B6bCWUu1+/z5ifHwO+w5KkhECE8Bhlt9ZaxkTX8CQxGErSf5l+8oBr /O6pZkJJRhKOWn2Jk4RmOcCOLW9YxYvDjtu/v+ufh2VAVUo4rMVOSTPd8tJADI1EIWpd zGxA== X-Gm-Message-State: AOAM5331K0vqetBAxpXrptqEMPzjLjiM34O+DlW8V4TY6yOmGJ7zQW8u W0keWhmLgaxQWjHI5ZWKbbk= X-Google-Smtp-Source: ABdhPJy8N84AH5SAi2pdUHvIMNYnC4ZAFk5GTjflBAq30S3MPfq2xZRFfBZOKxED1jVC0D473VSkdg== X-Received: by 2002:a17:90b:1649:: with SMTP id il9mr130289pjb.62.1612809202930; Mon, 08 Feb 2021 10:33:22 -0800 (PST) Received: from gmail.com ([2601:600:9b7f:872e:a655:30fb:7373:c762]) by smtp.gmail.com with ESMTPSA id np7sm29272pjb.10.2021.02.08.10.33.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Feb 2021 10:33:22 -0800 (PST) Date: Mon, 8 Feb 2021 10:31:35 -0800 From: Andrei Vagin To: Will Deacon , Dave Martin , Keno Fischer Subject: Re: [PATCH 2/3] arm64/ptrace: introduce PTRACE_O_ARM64_RAW_REGS Message-ID: <20210208183135.GA559391@gmail.com> References: <20210201194012.524831-1-avagin@gmail.com> <20210201194012.524831-3-avagin@gmail.com> <20210204153615.GB21058@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210204153615.GB21058@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210208_133327_127943_119F988D X-CRM114-Status: GOOD ( 34.70 ) 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, linux-api@vger.kernel.org, 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 Thu, Feb 04, 2021 at 03:36:15PM +0000, Will Deacon wrote: > 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. ok > > > 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? We don't want to allow setting options that are not supported. _PTRACE_O_ARCH_OPTIONS is added to PTRACE_O_MASK and then ptrace_setoptions checks whether all specified options is supported or not. > > 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? I am not sure that I understand the idea. Do you suggest to have PTRACE_O_ARCH_OPTION and pass arch-specific options in addr? In this case, I think it could be more cleaner to introduce a new ptrace command. If this is the idea, I think it worth doing this only if we expect to have more than one,two,three options. As for my solution, we need to come back to allocate a new bit to be sure that we don't intersect with non-arch specific options. And those who add a non-arch option should see that they don't use bits of arch-specific options. Let's decide what interface we want to use to solve the problem and then if we will stop on a ptrace option I will figure out how to improve this code. > > 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... Yeah, it might be a good idea. We will need to do one extra ptrace system call, but in comparison with ptrace context-switches, this is nothing. Dave, Keno, what do you think about this? > > Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel