lkml.org 
[lkml]   [2021]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v27 24/31] x86/cet/shstk: Handle thread shadow stack
From
Date
On 7/21/2021 11:28 AM, Florian Weimer wrote:
> * John Allen:
>
>> At the very least, it would seem that on some systems, it isn't valid to
>> rely on the stack_size passed from clone3, though I'm unsure what the
>> correct behavior should be here. If the passed stack_size == 0 and sp ==
>> 0, is this a case where we want to alloc a shadow stack for this thread
>> with some capped size? Alternatively, is this a case that isn't valid to
>> alloc a shadow stack and we should simply return 0 instead of -EINVAL?
>>
>> I'm running Fedora 34 which satisfies the required versions of gcc,
>> binutils, and glibc.
>
> Fedora 34 doesn't use clone3 yet. You can upgrade to a rawhide build,
> e.g. glibc-2.33.9000-46.fc35:
>
> <https://koji.fedoraproject.org/koji/buildinfo?buildID=1782678>
>
> It's currently not in main rawhide because the Firefox sandbox breaks
> clone3. The “fix” is that clone3 will fail with ENOSYS under the
> sandbox.
>
> I expect that container runtimes turn clone3 into clone in the same way
> (via ENOSYS), at least for the medium term. So it would make sense to
> allocate some sort of shadow stack for clone as well, if that's possible
> to implement in some way.
>
> Thanks,
> Florian
>

Thanks Florian! And because of that reason, we will put back clone2
support in my next v28 patches.

Yu-cheng

\
 
 \ /
  Last update: 2021-07-21 20:36    [W:0.111 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site