Re: [PATCH 00/35] Shadow stacks for userspace

Andy Lutomirski
2022-02-08T16:17:50Z

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.