On Tue, Feb 08, 2022 at 08:21:20AM -0800, Andy Lutomirski wrote: > >> 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 :-)
