Re: [PATCH] Add support for the x86 XSAVE extended state on FreeBSD/x86.

[John Baldwin <jhb@FreeBSD.org>]

On 3/21/15 4:18 PM, Mark Kettenis wrote:
>> That could be reused for the core read_description callback as
>> well as the native ones.  This could also be reused by other
>> systems that grow XSAVE support in the future.
> 
> Probably a good idea.  I'm working on XSAVE support in the OpenBSD
> kernel, so I'll eventually need this as well.
> 
> I have no real objection to adding the ptrace-specific bits to the
> generic BSD native code like your diff is doing.  I'll probably try to
> use the same interface for my OpenBSD implementation.  I have one
> concern about that code though.  The _supply_xsave() and
> _collect_xsave() functions don't accept a length, so they can't do any
> bounds checking.  Therefore, 'xstat_bv' as returned by the kernel must
> be set correctly (i.e. not have bits sets that imply state beyond
> x86_save_len is present.  Does the FreeBSD kernel guarantee that?

FreeBSD determines a system-wide xsave mask during boot and then leaves
%xcr0 unchanged.  The x86_xstate_len returned by PT_GETXSTATE_INFO is
also determined at boot time and doesn't change after that.  The kernel
does assume that xsave/xsaveopt do not store any bits in xstate_bv that
aren't set in %xcr0.  Attempts to restore a saved state via PT_SETXSTATE
that set a bit in xstate_bv that isn't set in %xcr0 results in
PT_SETXSTATE failing.  Those should ensure that xstate_bv does not
return an invalid length.

However, we could do additional bounds checking in the routines in
*bsd-nat.c by making them compare X86_XSTATE_SIZE(xstate_bv) against
x86_xstate_len and fail if x86_xstate_len is too small.

> Oh, and please rename x86_xsave_len into amd64bsd_xsave_len and
> i386bsd_xsave_len to keep the "namesapce" clean.

Will do.

-- 
John Baldwin