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

On Tue, Feb 08, 2022 at 08:21:20AM -0800, Andy Lutomirski wrote:

quoted

quoted

But such a knob will immediately reduce the security value of the entire
thing, and I don't have good ideas how to deal with it :(

Probably a kind of latch in the task_struct which would trigger off once
returt to a different address happened, thus we would be able to jump inside
paratite code. Of course such trigger should be available under proper
capability only.

I'm not fully in touch with how parasite, etc works.  Are we talking about save or restore?

We use parasite code in question during checkpoint phase as far as I remember.
push addr/lret trick is used to run "injected" code (code injection itself is
done via ptrace) in compat mode at least. Dima, Andrei, I didn't look into this code
for years already, do we still need to support compat mode at all?

If it's restore, what exactly does CRIU need to do?  Is it just that CRIU needs to return
out from its resume code into the to-be-resumed program without tripping CET?  Would it
be acceptable for CRIU to require that at least one shstk slot be free at save time?
Or do we need a mechanism to atomically switch to a completely full shadow stack at resume?

Off the top of my head, a sigreturn (or sigreturn-like mechanism) that is intended for
use for altshadowstack could safely verify a token on the altshdowstack, possibly
compare to something in ucontext (or not -- this isn't clearly necessary) and switch
back to the previous stack.  CRIU could use that too.  Obviously CRIU will need a way
to populate the relevant stacks, but WRUSS can be used for that, and I think this
is a fundamental requirement for CRIU -- CRIU restore absolutely needs a way to write
the saved shadow stack data into the shadow stack.

So I think the only special capability that CRIU really needs is WRUSS, and
we need to wire that up anyway.

Thanks for these notes, Andy! I can't provide any sane answer here since didn't
read tech spec for this feature yet :-)