linux-kernel - RE: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use user_xstate

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3E5A0FA7E9CA944F9D5414FEC6C712205C8CF9CF@ORSMSX106.amr.corp.intel.com>
Date:	Thu, 23 Apr 2015 00:06:51 +0000
From:	"Yu, Fenghua" <fenghua.yu@...el.com>
To:	"Hansen, Dave" <dave.hansen@...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

> From: Hansen, Dave
> Sent: Wednesday, April 22, 2015 12:34 PM
> 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/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.
> 

We need to copy ALL of supported xstates to user. Using xstate_bv only copies
partial xstates that are in non-init status.

Xstate_bv only has xstates that are in non-init status. The xstates that are in
init status will not be copied to user if using xstate_bv. In this case, the xstates
that are in init status will be all zeros in the user buffer (remember we clear
the user buffer before). That's incorrect.

If pcntxt_mask is used to copy xstates, all of supported xstates either in init or
non-init status will be copied correctly to the user buffer. All of other parts in
the user buffer will be zeros.

So there should be a problem to use pcntxt_mask here.

But I agree the init_xstate_buf was not initialized correctly earlier in the boot
time. But that's a separate issue to be fixed in a different patch.

Thanks.

-Fenghua