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
