On 13/06/2019 16:35, Catalin Marinas wrote:
On Thu, Jun 13, 2019 at 12:16:59PM +0100, Dave P Martin wrote:
On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
From: Catalin Marinas catalin.marinas@arm.com
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 catalin.marinas@arm.com
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?
Yeah, it went through several names but it seems that I didn't update all places.
+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 <linux/kernel.h> #include <linux/mm.h> #include <linux/stddef.h> +#include <linux/sysctl.h> #include <linux/unistd.h> #include <linux/user.h> #include <linux/delay.h> @@ -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.
The problem is that if you disable the ABI globally, lots of applications would crash. This sysctl is meant as a way to disable the opt-in to the TBI ABI. Another option would be a kernel command line option (I'm not keen on a Kconfig option).
Why you are not keen on a Kconfig option?
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.
I left it in for symmetry but I don't expect it to be used. A potential use-case is doing it per subsequent threads in an application.
- 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?
Yes, for MTE. That's why I wouldn't allow random bits here.
I'm wondering whether this is really a bitmask or an enum, or a mixture of the two. Maybe it doesn't matter.
User may want to set PR_TAGGED_ADDR_ENABLE | PR_MTE_PRECISE in a single call.
- 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.
Yes. I forgot you added this.