lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 22 Apr 2015 12:34:02 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	"Yu, Fenghua" <fenghua.yu@...el.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Mallick, Asit K" <asit.k.mallick@...el.com>,
	"Williamson, Glenn P" <glenn.p.williamson@...el.com>
CC:	linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use user_xstate_size
 for xstate size in signal context

On 04/22/2015 12:05 PM, Yu, Fenghua wrote:
>> From: Hansen, Dave
>> Sent: Wednesday, April 22, 2015 11:45 AM
>> To: Yu, Fenghua; H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit
>> K; Williamson, Glenn P
>> Cc: linux-kernel; x86
>> Subject: Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use
>> user_xstate_size for xstate size in signal context
>>
>> On 04/21/2015 09:51 PM, Fenghua Yu wrote:
>>> +	/*
>>> +	 * Copy rest of xstates in compact format to user.
>>> +	 */
>>> +	for (i = 2; i < xstate_features; i++) {
>>> +		if (test_bit(i, (unsigned long *)&pcntxt_mask)) {
>>> +			int user_offset, kernel_offset;
>>> +			int size;
>>> +
>>> +			user_offset = xstate_offsets[i];
>>> +			kernel_offset = xstate_comp_offsets[i];
>>> +			size = xstate_sizes[i];
>>> +
>>> +			if (__copy_to_user(buf_fx + user_offset,
>>> +				     xsave + kernel_offset, size))
>>> +				return -1;
>>> +		}
>>> +	}
>>
>> Is this checking the right bitmap?
>>
>> The 'xsaves' documentation says: "If RFBM[i] = 1, XSTATE_BV[i] is set to the
>> value of XINUSE[i]".  Where "XINUSE denotes the state-component bitmap
>> corresponding to the init optimization".
>>
>> So shouldn't this be checking xsave->xsave_hdr.xstate_bv instead of
>> pcntxt_mask?  The will be equal unless the "init optimization" is in play.
> 
> Xsave->xsave_hdr.xstate_bv is equal to pcntxt_mask (see setup_init_fpu_buf()).

No.  I don't think it works this way.  xsaves *WRITES* to the
XSTATE_BV[] field in addition to reading it.  According to the SDM:
"execution of XSAVES writes the XSTATE_BV field of the XSAVE header (see
Section 13.4.2), setting XSTATE_BV[i] (0 ≤ i ≤ 63) as follows...
Execution of XSAVES performs the init optimization to reduce the amount
of data written to memory. If XINUSE[i] = 0, state component i is not
saved to the XSAVE area (even if RFBM[i] = 1)".

> And here XINUSE and RFBM are irrelevant because they are used in init or modified
> optimization during xsave*/xrstore*. We only copy out the xstates from kernel
> to user and XINUSE and RFBM are not in scope here.

I think they are in use.  The kernel created its buffer with 'xsaves' so
when it is reading the buffer it needs to take those optimizations in to
consideration.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ