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]
Message-ID: <55383E17.4010408@intel.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ