The 08/23/2023 17:45, Catalin Marinas wrote: > On Wed, Aug 23, 2023 at 01:51:35PM +0100, Mark Brown wrote: > > On Wed, Aug 23, 2023 at 11:09:59AM +0100, Szabolcs Nagy wrote: > > > The 08/22/2023 18:53, Mark Brown wrote: > > > > My sense is that they deployment story is going to be smoother with > > > > defaults being provided since it avoids dealing with the issue of what > > > > to do if userspace creates a thread without a GCS in a GCS enabled > > > > process but like I say I'd be totally happy to extend clone3(). I will > > > > put some patches together for that (probably once the x86 stuff lands). > > > > Given the size of this series it might be better split out for > > > > manageability if nothing else. > > > > > i would make thread without gcs to implicitly disable gcs, since > > > that's what's bw compat with clones outside of libc (the libc can > > > guarantee gcs allocation when gcs is enabled). > > > > That'd create a pretty substantial divergence with the x86 patches if > > they land this time around, there's not enough time to rework them now - > > I suppose it'd mainly bite people implementing libc type stuff but > > still, doesn't feel great. > > I don't mind the divergence in this area if the libc folks are ok with > it. x86 can eventually use the clone3() interface if they want more > flexibility, they'll just have to continue supporting the old one. I > think we already diverge around the prctl(). i will have to prototype it, but in principle i'm ok with moving gcs allocation to userspace and passing it as argument to clone3. i will have to think if x86 divergence could cause issues. to maximize compat with existing raw clone users gcs either has to be disabled implicitly or allocated by the kernel. if we move gcs management to userspace then disable sounds better to me. (except vfork/fork does not have to disable etc.) to support gcs, a libc would have to use clone3 or enable gcs in the clone start code. i don't know if we can allow disabled gcs thread creation with locked gcs state. (i can see arguments both ways, so further prctl flag may be needed which may be another divergence from x86) i wonder if we can allow MAP_FIXED as well as MAP_FIXED_NOREPLACE semantics for map_shadow_stack (MAP_FIXED makes sense if userspace allocates thread stack + tls + gcs + guard pages with one PROT_NONE mapping and then mprotects / map_shadow_stack on top of that) i.e. if userspace manages the gcs it may need more flexibility here. (for now i think separate gcs mapping works for me.)
