On Tue, Feb 8, 2022, at 1:31 AM, Thomas Gleixner wrote: > On Mon, Feb 07 2022 at 17:31, Andy Lutomirski wrote: >> So this leaves altshadowstack. If we want to allow userspace to handle >> a shstk overflow, I think we need altshadowstack. And I can easily >> imagine signal handling in a coroutine or user-threading evironment (Go? >> UMCG or whatever it's called?) wanting this. As noted, this obnoxious >> Andy person didn't like putting any shstk-related extensions in the FPU >> state. >> >> For better or for worse, altshadowstack is (I think) fundamentally a new >> API. No amount of ucontext magic is going to materialize an entire >> shadow stack out of nowhere when someone calls sigaltstack(). So the >> questions are: should we support altshadowstack from day one and, if so, >> what should it look like? > > I think we should support them from day one. > >> So I don't have a complete or even almost complete design in mind, but I >> think we do need to make a conscious decision either to design this >> right or to skip it for v1. > > Skipping it might create a fundamental design fail situation as it might > require changes to the shadow stack signal handling in general which > becomes a nightmare once a non-altstack API is exposed. It would also expose a range of kernels in which shstk is on but programs that want altshadowstack don't have it. That would be annoying. > >> As for CRIU, I don't think anyone really expects a new kernel, running >> new userspace that takes advantage of features in the new kernel, to >> work with old CRIU. > > Yes, CRIU needs updates, but what ensures that CRIU managed user space > does not use SHSTK if CRIU is not updated yet? In some sense this is like any other feature. If a program uses timerfd but CRIU doesn't support timerfd, then it won't work. SHSTK is a bit unique because it's likely that all programs on a system will start using it all at once.
