lkml.org 
[lkml]   [2020]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack
From
Date
On 9/8/2020 10:57 AM, Dave Hansen wrote:
> On 9/8/20 10:50 AM, Yu, Yu-cheng wrote:
>> What about this:
>>
>> - Do not add any new syscall or arch_prctl for creating a new shadow stack.
>>
>> - Add a new arch_prctl that can turn an anonymous mapping to a shadow
>> stack mapping.
>>
>> This allows the application to do whatever is necessary.  It can even
>> allow GDB or JIT code to create or fix a call stack.
>
> Fine with me. But, it's going to effectively be
>
> arch_prctl(PR_CONVERT_TO_SHS..., addr, len);
>
> when it could just as easily be:
>
> madvise(addr, len, MADV_SHSTK...);
>
> Or a new syscall. The only question in my mind is whether we want to do
> something generic that we can use for other similar things in the
> future, like:
>
> madvise2(addr, len, flags, MADV2_SHSTK...);
>
> I don't really feel strongly about it, though. Could you please share
> your logic on why you want a prctl() as opposed to a whole new syscall?
>

A new syscall is more intrusive, I think. When creating a new shadow
stack, the kernel also installs a restore token on the top of the new
shadow stack, and it is somewhat x86-specific. So far no other arch's
need this.

Yes, madvise is better if the kernel only needs to change the mapping.
The application itself can create the restore token before calling
madvise().

\
 
 \ /
  Last update: 2020-09-08 20:26    [W:0.284 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site