Linux-man Archive on
 help / color / Atom feed
From: Andi Kleen <>
To: Keno Fischer <>
Cc: Andi Kleen <>,
	Michael Kerrisk-manpages <>,
	linux-man <>,
	Andy Lutomirski <>,
	Dave Hansen <>,
	Peter Zijlstra <>,
	Thomas Gleixner <>,
	Ingo Molnar <>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<>, "H. Peter Anvin" <>,
	Borislav Petkov <>,
	Dave Hansen <>
Subject: Re: [PATCH] ptrace.2: Describe PTRACE_SET/GETREGSET on NT_X86_XSTATE
Date: Wed, 20 May 2020 06:56:46 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, May 19, 2020 at 11:30:02PM -0400, Keno Fischer wrote:
> > > +.SS The layout and operation of the NT_X86_XSTATE regset
> >
> > Should rather have a complete table of NT_* entries first. The others
> > can be dummies for now.
> Oh boy, I'm not sure my man-page-formatting-fu is up to the task of
> creating a nice looking table :).
> Michael, can you help?

'\" t in the first line


c s 
l l.

> > > +Obtain the kernel xsave component bitmask from the software-reserved area of the
> > > +xstate buffer. The software-reserved area beings at offset 464 into the xsave
> >
> > It would be better to put some struct defining this into the kernel uapi
> > and then reference that instead of magic numbers.
> We have user_xstateregs in the kernel, but that's not in the uapi.
> I suppose we should move it, given that it is exposed here.


> > > +buffer and the first 64 bits of this area contain the kernel xsave component bitmask
> > > +.IP 2.
> > > +Compute the offset of each state component by adding the sizes of all prior state
> > > +components that are enabled in the kernel xsave component bitmask, aligning to 64 byte boundaries along the way. This
> > > +format matches that of a compacted xsave area with XCOMP_BV set to the
> >
> > The sizes of these areas should probably also be in the uapi include
> Yes, that seems like a good idea.
> What's the policy on helper functions in uapi includes?
> Can we have helper functions that given a buffer and the kernel xstate mask,
> does this computation for you?

Yes that sounds like a good idea. Just needs to be an inline.

I'm not aware of any policy against that.

> > > +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).
> >
> > I wonder if we shouldn't just fix the kernel to do this properly on its
> > own.  Presumably it won't break any existing user space.
> >
> > It seems more a bug than something that should be a documented ABI.
> I'd be happy to see this interface improved, since I do think it wasn't quite
> intended to work this way when originally conceived (i.e. originally, before
> the init optimization and before we had flags that turn off various xstate
> components resulting in a compressed buffer).

Yes we should fix the kernel to make sure that anything copied out
can be straight copied in again (plus probably some self tests for this)

> As I said in the other email thread, I think it would be reasonable to change
> the offsets to always be non-compressed, which would at least make this
> a normal xsave buffer. No ptracer that I looked at knows that this buffer
> can be compressed, so changing the kernel behavior here would actually
> make it closer to what existing userspace expects ;).

Hmm, maybe. It seems a bit risky to mess with an ABI.
I guess could add a new NT_* for this and deprecate the old one.

> I'm not sure what to do about the getregset/setregset mismatch. On the one
> hand it's pretty bad, but on the other hand, I'm not really sure what to do
> about it, short of introducing a different NT_X86_* constant that behaves
> differently.

The kernel just needs to fill in the right fields on GET?

Or perhaps it can be only fixed in a new NT_*

> > > +
> > > +The value of the kernel's state component bitmask is determined on boot and
> > > +need not be equivalent to the maximal set of state components supported by the
> > > +CPU (as enumerated through CPUID).
> >
> > Okay so how should someone get it? Looks like that's a hole in the
> > kernel API that we need to fix somehow.
> The cpuid enumerated value does still represent a maximum so that can be used
> to size the buffer and the actual value can then be read from the software saved
> area as described here. Is that what you were asking? Not sure I understood
> correctly.

Okay so it's already exported. Never mind.


      parent reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18  3:00 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
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 [this message]

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-man Archive on

Archives are clonable:
	git clone --mirror linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ \
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone