lkml.org 
[lkml]   [2017]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/11] ARMv8.3 pointer authentication userspace support
On Tue, Jul 25, 2017 at 01:06:43PM +0100, Mark Rutland wrote:
> On Fri, Jul 21, 2017 at 06:05:09PM +0100, Dave Martin wrote:
> > On Wed, Jul 19, 2017 at 05:01:21PM +0100, Mark Rutland wrote:
> > > This series adds support for the ARMv8.3 pointer authentication extension.
>
> > > Open questions
> > > ==============
> > >
> > > * Should keys be per-thread rather than per-process?
> > >
> > > My understanding is that glibc can't (currently) handle threads having
> > > different keys, but it might be that another libc would prefer per-thread
> >
> > Can you elaborate?
> >
> > It's not valid to do a function return from one thread to another.
>
> Regardless of whether it's valid per the C spec or POSIX, some people
> use {set,get}context and {set,long}jmp in this manner (IIRC, QEMU does
> this), and my understanding is that similar tricks are in use in the
> bowels of glibc.
>
> Otherwise, my preference would be to have per-thread keys from day one.

Having considered comments I've received elsewhere, I've reversed my
position here. I think per-process keys are the more
sensible default since:

* This will allow us to protect function pointers in shared
datastructures such as vtables.

* Tasks have their own stacks, and values leaked from one stack cannot
be used to spoof return addresses on another.

* If an attacker can take control of one thread, they've already gained
code execution and/or primitives that can be used to attack the
process by other means.

Thanks,
Mark.

\
 
 \ /
  Last update: 2017-08-11 13:31    [W:0.080 / U:1.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site