linux-kernel - Re: [PATCH 02/19] x86, fpu: Wrap get_xsave

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: <55674157.4070108@sr71.net>
Date:	Thu, 28 May 2015 09:24:55 -0700
From:	Dave Hansen <dave@...1.net>
To:	Ingo Molnar <mingo@...nel.org>
CC:	linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de,
	dave.hansen@...ux.intel.com, oleg@...hat.com, bp@...en8.de,
	riel@...hat.com, sbsiddha@...il.com, luto@...capital.net,
	mingo@...hat.com, hpa@...or.com, fenghua.yu@...el.com,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 02/19] x86, fpu: Wrap get_xsave_addr() to make it safer

On 05/28/2015 08:01 AM, Ingo Molnar wrote:
> But the real question is: can we support in-use MPX with asynchronous lazy 
> restore, while it's still semantically correct? I don't think so, unless you add 
> MPX specific synchronous restore to the context switch path, which isn't such a 
> good idea IMHO.

Right now, we assume that the first use of the FPU gets an #ND exception
to tell us that someone is using the FPU.  MPX doesn't generate #ND,
thus the need to do it eagerly.

On CPUs that support it we could, instead, do an xgetbv during the
context switch to ensure that all things having an xstate/xfeature but
that do not generate #ND exceptions are in their init state.  If they
are not in their init state, we exit lazy mode.

We could theoretically use the same kind of thing with the compacted
xsave format to ensure that we only allocate enough space for what we
*need* in the xsave buffer and not allocate for the worst-case.  AVX512
has 32x512-bit registers (2kbytes) and it would be a bit of a shame to
need to allocate ~3k of space.
--
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/