On Wed, Dec 13, 2023 at 5:37 AM Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Tue, Dec 12, 2023 at 04:50:38PM -0800, Deepak Gupta wrote: > > > A theoretical scenario (no current workloads should've this case > > because no shadow stack) > > > - User mode did _ENABLE on the main thread. Shadow stack was allocated > > for the current > > thread. > > - User mode created a bunch worker threads to run untrusted contained > > code. They shadow > > stack too. > > - main thread had to do dlopen and now need to disable shadow stack on > > itself due to > > incompatibility of incoming object in address space. > > - main thread controls worker threads and knows they're contained and > > should still be running > > with a shadow stack. Although once in a while the main thread needs > > to perform writes to a shadow > > stack of worker threads for some fixup (in the same addr space). > > main thread doesn't want to delegate > > this responsibility of ss writes to worker threads because they're untrusted. > > > How will it do that (currently _ENABLE is married to _WRITE and _PUSH) ? > > That's feeling moderately firmly into "don't do that" territory to be > honest, the problems of trying to modify the stack of another running > thread while it's active just don't seem worth it - if you're > coordinating enough to do the modifications it's probably possible to > just ask the thread who's stack is being modified to do the modification > itself and having an unprotected thread writing into shadow stack memory > doesn't feel great. > Yeah no leanings on my side. Just wanted to articulate this scenario. Since this is new ground, we can define what's appropriate. Let's keep it this way where a thread can write to shadow stack mappings only when it itself has shadow stack enabled.
