Hi Michael, not yet - my apologies. I have a few other things I need to take care of with higher priority, but fixing up ptrace.2 is still on my todo list. Keno On Mon, Jun 8, 2020 at 11:46 AM Michael Kerrisk (man-pages) <mtk.manpages@xxxxxxxxx> wrote: > > Hi Keno, > > Any progress on a v2 patch? > > Thanks, > > Michael > > On 5/20/20 5:30 AM, 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? > > > >>> +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? > > > >>> +kernel component bitmask. Further details on the layout of the compacted xsave > >>> +area may be found in the Intel architecture manual, but note that the xsave > >>> +buffer returned from ptrace will have its XCOMP_BV set to 0. > >> > >> The note seems disconnected. You'll have to explain it here. > > > > Ok, I'll elaborate. The point I wanted to make is that even though the buffer > > looks compressed, XCOMP_BV is 0, so it's not a valid compressed buffer > > that can be xrstor'ed. > > > >>> +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). > > > > 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 ;). > > > > 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 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. > > > > > > > > Keno > > > > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/
