On Mon, Jun 10, 2019 at 07:53:30PM +0100, Catalin Marinas wrote: > On Mon, Jun 10, 2019 at 11:07:03AM -0700, Kees Cook wrote: > > On Mon, Jun 10, 2019 at 06:53:27PM +0100, Catalin Marinas wrote: > > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > > > index 3767fb21a5b8..fd191c5b92aa 100644 > > > --- a/arch/arm64/kernel/process.c > > > +++ b/arch/arm64/kernel/process.c > > > @@ -552,3 +552,18 @@ void arch_setup_new_exec(void) > > > > > > ptrauth_thread_init_user(current); > > > } > > > + > > > +/* > > > + * Enable the relaxed ABI allowing tagged user addresses into the kernel. > > > + */ > > > +int untagged_uaddr_set_mode(unsigned long arg) > > > +{ > > > + if (is_compat_task()) > > > + return -ENOTSUPP; > > > + if (arg) > > > + return -EINVAL; > > > + > > > + set_thread_flag(TIF_UNTAGGED_UADDR); > > > + > > > + return 0; > > > +} > > > > I think this should be paired with a flag clearing in copy_thread(), > > yes? (i.e. each binary needs to opt in) > > It indeed needs clearing though not in copy_thread() as that's used on > clone/fork but rather in flush_thread(), called on the execve() path. Ah! Yes, thanks. > And a note to myself: I think PR_UNTAGGED_ADDR (not UADDR) looks better > in a uapi header, the user doesn't differentiate between uaddr and > kaddr. Good point. I would agree. :) -- Kees Cook