linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Denys Vlasenko <vda.linux@googlemail.com>
To: Keno Fischer <keno@juliacomputing.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-man <linux-man@vger.kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH] ptrace.2: Describe PTRACE_SET/GETREGSET on NT_X86_XSTATE
Date: Wed, 20 May 2020 12:03:35 +0200	[thread overview]
Message-ID: <CAK1hOcMLxkoT9i8TRZhV3gcD0BKiUxXoHHXEAqL2rG5ekyF3BA@mail.gmail.com> (raw)
In-Reply-To: <CABV8kRxvt0EKb3VF0JKGR43Ozaujj9PB3cMx6K7e_qLoFrqemA@mail.gmail.com>

On Wed, May 20, 2020 at 12:47 AM Keno Fischer <keno@juliacomputing.com> wrote:
> > > > +Thus, to obtain an xsave area that may be set back to the tracee, all unused
> > > > +state components must first be re-set to the correct initial state for the
> > > > +corresponding state component, and the XSTATE_BV bitfield must subsequently
> > > > +be adjusted to match the kernel xstate component bitmask (obtained as
> > > > +described above).
> >
> > The above paragraph needs a better wording. Are you saying the following? -
> >
> > "If a state component is not saved (its XSTATE_BV bit is zero) but you
> > want to modify corresponding registers in the tracee, you need to set
> > this bit to 1 and initialize the component to the desired state."
>
> Kind of, what I want to get across is a warning that the following pattern:
>
> struct iov = { ... };
> ptrace(PTRACE_GETREGSET, pid1, NT_X86_XSTATE, &iov);
> ptrace(PTRACE_SETREGSET, pid2, NT_X86_XSTATE, &iov);
>
> will not necessarily result in pid1 and pid2 having identical register states.
> If a state component was in its initial state in pid1, the XSTATE_BV
> bit will be cleared, resulting in the registers in pid2 not being modified.

Wanting to set the registers to initial state is a subset of the case where
you want to set them to some state (initial or not), so my proposed
explanation covers it too.

But your example with two separate pids makes it clearer when you would
need to be aware of it even if the state you are setting is the initial one:
you need explicitly set it, can't assume just "copying" will do.

I propose:

If a state component is not saved (its XSTATE_BV bit is zero) but you
want to modify corresponding registers in the tracee, you need to set
this bit to 1 and initialize the component to the desired state.

In particular, it means that on PTRACE_SETREGSET, not saved component
does not cause corresponding registers to be re-initialized: a naive
"copy registers from pid1 to pid2":

ptrace(PTRACE_GETREGSET, pid1, NT_X86_XSTATE, &iov);
ptrace(PTRACE_SETREGSET, pid2, NT_X86_XSTATE, &iov);

will not copy register sets which are in initial state in pid1,
they will remain unmodified in pid2.

  reply	other threads:[~2020-05-20 10:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18  3:00 [PATCH] ptrace.2: Describe PTRACE_SET/GETREGSET on NT_X86_XSTATE Keno Fischer
2020-05-19 20:44 ` Michael Kerrisk (man-pages)
2020-05-19 21:29   ` Denys Vlasenko
2020-05-19 22:46     ` Keno Fischer
2020-05-20 10:03       ` Denys Vlasenko [this message]
2020-05-20  1:19 ` Andi Kleen
2020-05-20  3:30   ` Keno Fischer
2020-05-20  5:08     ` Michael Kerrisk (man-pages)
2020-05-20 13:56     ` Andi Kleen
2020-06-08 15:46     ` Michael Kerrisk (man-pages)
2020-06-08 22:07       ` Keno Fischer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK1hOcMLxkoT9i8TRZhV3gcD0BKiUxXoHHXEAqL2rG5ekyF3BA@mail.gmail.com \
    --to=vda.linux@googlemail.com \
    --cc=andi@firstfloor.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=keno@juliacomputing.com \
    --cc=linux-man@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mtk.manpages@gmail.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).