Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391396 > unrolled thread

Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES Dave Hansen <dave.hansen@linux.intel.com> - 2016-04-29 22:30 +0200
    Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES Yu-cheng Yu <yu-cheng.yu@intel.com> - 2016-04-30 00:40 +0200
      Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES Dave Hansen <dave.hansen@linux.intel.com> - 2016-04-30 00:40 +0200
        Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES Yu-cheng Yu <yu-cheng.yu@intel.com> - 2016-04-30 00:50 +0200

#1391396 — Re: [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES

On 03/04/2016 10:12 AM, Yu-cheng Yu wrote:
> +	for (i = 0; i < XFEATURE_MAX; i++) {
> +		/*
> +		 * Copy only in-use xstates.
> +		 */
> +		if (((header.xfeatures >> i) & 1) && xfeature_enabled(i)) {
> +			void *src = get_xsave_addr_no_check(xsave, i);

How could a bit in header.xfeatures get set if it is not set in
xfeature_enabled() aka xfeatures_mask aka XCR0?

...
> +int copyin_to_xsaves(const void *kbuf, const void __user *ubuf,
> +		     struct xregs_state *xsave)
> +{
> +	unsigned int offset, size;
> +	int i;
> +	u64 xfeatures;
> +
> +	offset = offsetof(struct xregs_state, header);
> +	size = sizeof(xfeatures);
> +
> +	if (kbuf)
> +		memcpy(&xfeatures, kbuf + offset, size);
> +	else if (__copy_from_user(&xfeatures, ubuf + offset, size))
> +		return -EFAULT;
> +
> +	/*
> +	 * Reject if the user tries to set any supervisor xstates.
> +	 */
> +	if (xfeatures & XFEATURE_MASK_SUPERVISOR)
> +		return -EINVAL;
> +
> +	for (i = 0; i < XFEATURE_MAX; i++) {
> +		u64 mask = ((u64)1 << i);
> +
> +		if ((xfeatures & mask) && xfeature_enabled(i)) {
> +			void *dst = get_xsave_addr_no_check(xsave, i);
> +
> +			offset = xstate_offsets[i];
> +			size = xstate_sizes[i];
> +
> +			if (kbuf)
> +				memcpy(dst, kbuf + offset, size);
> +			else if (__copy_from_user(dst, ubuf + offset, size))
> +				return -EFAULT;
> +		}
> +	}

If a caller tries to pass a non-enabled xfeature in, we appear to just
silently drop it and return success.  Is that really what we want to do
or do we want to error out?

[toc] | [next] | [standalone]

#1391502

On Fri, Apr 29, 2016 at 01:25:34PM -0700, Dave Hansen wrote:
> On 03/04/2016 10:12 AM, Yu-cheng Yu wrote:
> > +	for (i = 0; i < XFEATURE_MAX; i++) {
> > +		/*
> > +		 * Copy only in-use xstates.
> > +		 */
> > +		if (((header.xfeatures >> i) & 1) && xfeature_enabled(i)) {
> > +			void *src = get_xsave_addr_no_check(xsave, i);
> 
> How could a bit in header.xfeatures get set if it is not set in
> xfeature_enabled() aka xfeatures_mask aka XCR0?

Do you mean, we should test xfeature_enabled(i) first, like,

	if (xfeature_enabled(i) && ((header.xfeatures >> i) & 1)) ?

The result will be the same, like you said, if XCR0[i] is not set,
hader.xfeatures[i] cannot be set.  But if XCR0[i] is set,
header.xfeatures[i] can be cleared. 

> 
> If a caller tries to pass a non-enabled xfeature in, we appear to just
> silently drop it and return success.  Is that really what we want to do
> or do we want to error out?

Let it fail.  I will chage it.

[toc] | [prev] | [next] | [standalone]

#1391506

On 04/29/2016 03:30 PM, Yu-cheng Yu wrote:
> On Fri, Apr 29, 2016 at 01:25:34PM -0700, Dave Hansen wrote:
>> On 03/04/2016 10:12 AM, Yu-cheng Yu wrote:
>>> +	for (i = 0; i < XFEATURE_MAX; i++) {
>>> +		/*
>>> +		 * Copy only in-use xstates.
>>> +		 */
>>> +		if (((header.xfeatures >> i) & 1) && xfeature_enabled(i)) {
>>> +			void *src = get_xsave_addr_no_check(xsave, i);
>>
>> How could a bit in header.xfeatures get set if it is not set in
>> xfeature_enabled() aka xfeatures_mask aka XCR0?
> 
> Do you mean, we should test xfeature_enabled(i) first, like,
> 
> 	if (xfeature_enabled(i) && ((header.xfeatures >> i) & 1)) ?
> 
> The result will be the same, like you said, if XCR0[i] is not set,
> hader.xfeatures[i] cannot be set.  But if XCR0[i] is set,
> header.xfeatures[i] can be cleared. 

I think the xfeature_enabled(i) is probably redundant.  Does it serve
any actual purpose?

[toc] | [prev] | [next] | [standalone]

#1391512

On Fri, Apr 29, 2016 at 03:36:12PM -0700, Dave Hansen wrote:
> On 04/29/2016 03:30 PM, Yu-cheng Yu wrote:
> > On Fri, Apr 29, 2016 at 01:25:34PM -0700, Dave Hansen wrote:
> >> On 03/04/2016 10:12 AM, Yu-cheng Yu wrote:
> >>> +	for (i = 0; i < XFEATURE_MAX; i++) {
> >>> +		/*
> >>> +		 * Copy only in-use xstates.
> >>> +		 */
> >>> +		if (((header.xfeatures >> i) & 1) && xfeature_enabled(i)) {
> >>> +			void *src = get_xsave_addr_no_check(xsave, i);
> >>
> >> How could a bit in header.xfeatures get set if it is not set in
> >> xfeature_enabled() aka xfeatures_mask aka XCR0?
> > 
> > Do you mean, we should test xfeature_enabled(i) first, like,
> > 
> > 	if (xfeature_enabled(i) && ((header.xfeatures >> i) & 1)) ?
> > 
> > The result will be the same, like you said, if XCR0[i] is not set,
> > hader.xfeatures[i] cannot be set.  But if XCR0[i] is set,
> > header.xfeatures[i] can be cleared. 
> 
> I think the xfeature_enabled(i) is probably redundant.  Does it serve
> any actual purpose?

Got it.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web