Messages in this thread | | | Subject | Re: [PATCH v27 24/31] x86/cet/shstk: Handle thread shadow stack | From | "Yu, Yu-cheng" <> | Date | Wed, 21 Jul 2021 11:34:53 -0700 |
| |
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
| |