On 5/17/23 16:48, Jeff Xu wrote: > However, there are a few challenges I have not yet worked through. > First, the code needs to track when the first signaling entry occurs > (saving the PKRU register to the thread struct) and when it is last > returned (restoring the PKRU register from the thread struct). Would tracking signal "depth" work in the face of things like siglongjmp? Taking a step back... Here's my concern about this whole thing: it's headed down a rabbit hole which is *highly* specialized both in the apps that will use it and the attacks it will mitigate. It probably *requires* turning off a bunch of syscalls (like io_uring) that folks kinda like in general. We're balancing that highly specialized mitigation with a feature that add new ABI, touches core memory management code and signal handling. On the x86 side, PKRU is a painfully special snowflake. It's exposed in the "XSAVE" ABIs, but not actually managed *with* XSAVE in the kernel. This would be making it an even more special snowflake because it would need new altstack ABI and handling. I'm just not sure the gain is worth the pain.
