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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 22 Apr 2015 17:34:31 -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 05:06 PM, Yu, Fenghua wrote:
> 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.

Do we *need* to fill every field in the user buffer?  I don't think
that's a given.  The xstate_bv that we copy out to userspace would
clearly spell out which fields we've populated.  Leaving the rest zeros
might be OK.

> So there should be a problem to use pcntxt_mask here.

I'm not convinced.  Let's step through this.

1. kernel does an xsaves
2. Due to the 'init optimization' xstate_bv != pcntxt_mask, and some
   fields of kernel xsave buffer are untouched
3. Kernel looks at pcntxt_mask, which means it copies untouched xsave
   buffer fields out to userspace

If those untouched fields of the xsave buffer are in the "init state",
then we've got no problem.  But, are those "untouched since (1)" fields
in the kernel xsave buf *GUARANTEED* to be in the init state?

What stops this sequence of events from happening?

1. task sets xsave fields to non-init state
2. kernel 'xsaves' xsave fields to fpu.state->xsave
3. userspace gets all xsave fields to init state again
4. kernel calls 'xsaves' again, but 'xsaves' declines to  fill the
   fpu.state->xsave fields because of the init optimization, leaves some
   xstate_bv bits = 0.
5. Signal handling code looks at pcntxt_mask, copies stale
   non-init-state fields from (2) out to userspace
6. Userspace sees wrong fields.  Boom.

--
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/