On Sun, Feb 06, 2022 at 08:42:03PM +0200, Mike Rapoport wrote: > (added more CRIU people) Thanks, Mike. > On Sun, Jan 30, 2022 at 01:18:03PM -0800, Rick Edgecombe wrote: > > This is a slight reboot of the userspace CET series. I will be taking over the > > series from Yu-cheng. Per some internal recommendations, I’ve reset the version > > number and am calling it a new series. Hopefully, it doesn’t cause confusion. > > > > The new plan is to upstream only userspace Shadow Stack support at this point. > > IBT can follow later, but for now I’ll focus solely on the most in-demand and > > widely available (with the feature on AMD CPUs now) part of CET. > > > > I thought as part of this reset, it might be useful to more fully write-up the > > design and summarize the history of the previous CET series. So this slightly > > long cover letter does that. The "Updates" section has the changes, if anyone > > doesn't want the history. [...] > > CRIU Support > > ------------ > > In the past there was some speculation on the mailing list about > > whether CRIU would need to be taught about CET. It turns out, it does. > > The first issue hit is that CRIU calls sigreturn directly from its > > “parasite code” that it injects into the dumper process. This violates > > this shadow stack implementation’s protection that intends to prevent > > attackers from doing this. > > > > With so many packages already enabled with shadow stack, there is > > probably desire to make it work seamlessly. But in the meantime if > > distros want to support shadow stack and CRIU, users could manually > > disabled shadow stack via “GLIBC_TUNABLES=glibc.cpu.x86_shstk=off” for > > a process they will wants to dump. It’s not ideal. > > > > I’d like to hear what people think about having shadow stack in the > > kernel without this resolved. Nothing would change for any users until > > they enable shadow stack in the kernel and update to a glibc configured > > with CET. Should CRIU userspace be solved before kernel support?
