lkml.org 
[lkml]   [2021]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v27 24/31] x86/cet/shstk: Handle thread shadow stack
Date
* 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

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