Re: [RFC PATCH v2] x86/arch_prctl: Add ARCH_SET_XCR0 to set XCR0 per-thread

[Andy Lutomirski]

On Wed, Apr 15, 2020 at 6:17 PM Keno Fischer <keno@xxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Apr 15, 2020 at 9:14 PM Keno Fischer <keno@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > > Would it make matters easier if tasks with nonstandard XCR0 were not
> > > allowed to use ptrace() at all?  And if ARCH_SET_XCR0 were disallowed
> > > if the caller is tracing anyone?
> >
> > That would be fine by me (as long as you're still allowed to ptrace them of
> > course).
>
> Sorry, I realized after I had hit send that this wording may not be clear.
> What I meant was that it would need to be able to have an external ptracer
> (with unmodified XCR0) attach to the task, even if it had modified its XCR0.
> I don't think you were suggesting that that wouldn't be possible,
> but I just wanted to make sure.

Yes, exactly.  Just to make sure we're on the same page, I suggest:

If a process modifies XCR0, then it cannot use ptrace().  Signal
delivery and sigreturn use the modified XCR0.  If you modify your XCR0
from within a signal handler, you get to keep both pieces.  If you
ptrace() a process with a modified XCR0, you see the full regset.
Among other things, this means that you could ptrace() a task with a
reduced XCR0, poke a value in one of the disabled register sets with
ptrace(), and read that same value back out again with ptrace().

Before you implement this, you might want to make sure that at least
one other x86 maintainer agrees with me. :)

I'm sure the CRIU people will notice this and want to find a way to
make ptrace() work from a modified-XCR0 process.  They are welcome to
propose semantics, since neither of the obvious ways to handle it
actually seem correct.

--Andy