On Wed, Jun 01, 2022 at 05:24:26PM +0000, Edgecombe, Rick P wrote: > On Wed, 2022-06-01 at 11:06 +0300, Mike Rapoport wrote: > > > Yea, having something working is really great. My only hesitancy is > > > that, per a discussion on the LAM patchset, we are going to make > > > this > > > enabling API CET only (same semantics for though). I suppose the > > > locking API arch_prctl() could still be support other arch > > > features, > > > but it might be a second CET only regset. It's not the end of the > > > world. > > > > The support for CET in criu is anyway experimental for now, if the > > kernel > > API will be slightly different in the end, we'll update criu. > > The important things are the ability to control tracee shadow stack > > from ptrace, the ability to map the shadow stack at fixed address and > > the > > ability to control the features at least from ptrace. > > As long as we have APIs that provide those, it should be Ok. > > > > > I guess the other consideration is tieing CRIU to glibc > > > peculiarities. > > > Like even if we fix glibc, then CRIU may not work with some other > > > libc > > > or app that force disables for some weird reason. Is it supposed to > > > be > > > libc-agnostic? > > > > Actually using the ptrace to control the CET features does not tie > > criu to > > glibc. The current proposal for the arch_prctl() allows libc to lock > > CET > > features and having a ptrace call to control the lock makes criu > > agnostic > > to libc behaviour. > > From staring at the glibc code, I'm suspicious something was weird with > your test setup, as I don't think it should be locking. But I guess to > be completely proper you would need to save and restore the lock state > anyway. So, ok yea, on balance probably better to have an extra > interface. > > Should we make it a GET/SET interface? Yes, I think so. -- Sincerely yours, Mike.
