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

On Wed, 2022-06-01 at 11:06 +0300, Mike Rapoport wrote:

quoted

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.
 

quoted

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?