From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Martin Subject: Re: [PATCH v17 03/15] arm64: Introduce prctl() options to control the tagged user addresses ABI Date: Thu, 13 Jun 2019 12:16:59 +0100 Message-ID: <20190613111659.GX28398@e103592.cambridge.arm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Andrey Konovalov Cc: Mark Rutland , kvm@vger.kernel.org, Christian Koenig , Szabolcs Nagy , Catalin Marinas , Will Deacon , dri-devel@lists.freedesktop.org, Kostya Serebryany , Khalid Aziz , Lee Smith , linux-kselftest@vger.kernel.org, Vincenzo Frascino , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Christoph Hellwig , Jason Gunthorpe , Dmitry Vyukov , Evgeniy Stepanov , linux-media@vger.kernel.org, Kees Cook , Ruben Ayrapetyan , Kevin Brodsky List-Id: linux-rdma@vger.kernel.org On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote: > From: Catalin Marinas > > It is not desirable to relax the ABI to allow tagged user addresses into > the kernel indiscriminately. This patch introduces a prctl() interface > for enabling or disabling the tagged ABI with a global sysctl control > for preventing applications from enabling the relaxed ABI (meant for > testing user-space prctl() return error checking without reconfiguring > the kernel). The ABI properties are inherited by threads of the same > application and fork()'ed children but cleared on execve(). > > The PR_SET_TAGGED_ADDR_CTRL will be expanded in the future to handle > MTE-specific settings like imprecise vs precise exceptions. > > Signed-off-by: Catalin Marinas > --- > arch/arm64/include/asm/processor.h | 6 +++ > arch/arm64/include/asm/thread_info.h | 1 + > arch/arm64/include/asm/uaccess.h | 3 +- > arch/arm64/kernel/process.c | 67 ++++++++++++++++++++++++++++ > include/uapi/linux/prctl.h | 5 +++ > kernel/sys.c | 16 +++++++ > 6 files changed, 97 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h > index fcd0e691b1ea..fee457456aa8 100644 > --- a/arch/arm64/include/asm/processor.h > +++ b/arch/arm64/include/asm/processor.h > @@ -307,6 +307,12 @@ extern void __init minsigstksz_setup(void); > /* PR_PAC_RESET_KEYS prctl */ > #define PAC_RESET_KEYS(tsk, arg) ptrauth_prctl_reset_keys(tsk, arg) > > +/* PR_TAGGED_ADDR prctl */ (A couple of comments I missed in my last reply:) Name mismatch? > +long set_tagged_addr_ctrl(unsigned long arg); > +long get_tagged_addr_ctrl(void); > +#define SET_TAGGED_ADDR_CTRL(arg) set_tagged_addr_ctrl(arg) > +#define GET_TAGGED_ADDR_CTRL() get_tagged_addr_ctrl() > + [...] > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index 3767fb21a5b8..69d0be1fc708 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -30,6 +30,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -323,6 +324,7 @@ void flush_thread(void) > fpsimd_flush_thread(); > tls_thread_flush(); > flush_ptrace_hw_breakpoint(current); > + clear_thread_flag(TIF_TAGGED_ADDR); > } > > void release_thread(struct task_struct *dead_task) > @@ -552,3 +554,68 @@ void arch_setup_new_exec(void) > > ptrauth_thread_init_user(current); > } > + > +/* > + * Control the relaxed ABI allowing tagged user addresses into the kernel. > + */ > +static unsigned int tagged_addr_prctl_allowed = 1; > + > +long set_tagged_addr_ctrl(unsigned long arg) > +{ > + if (!tagged_addr_prctl_allowed) > + return -EINVAL; So, tagging can actually be locked on by having a process enable it and then some possibly unrelated process clearing tagged_addr_prctl_allowed. That feels a bit weird. Do we want to allow a process that has tagging on to be able to turn it off at all? Possibly things like CRIU might want to do that. > + if (is_compat_task()) > + return -EINVAL; > + if (arg & ~PR_TAGGED_ADDR_ENABLE) > + return -EINVAL; How do we expect this argument to be extended in the future? I'm wondering whether this is really a bitmask or an enum, or a mixture of the two. Maybe it doesn't matter. > + > + if (arg & PR_TAGGED_ADDR_ENABLE) > + set_thread_flag(TIF_TAGGED_ADDR); > + else > + clear_thread_flag(TIF_TAGGED_ADDR); I think update_thread_flag() could be used here. [...] Cheers ---Dave