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: <20150528150114.GA10146@gmail.com>
Date:	Thu, 28 May 2015 17:01:14 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Dave Hansen <dave@...1.net>
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

* Dave Hansen <dave@...1.net> wrote:

> On 05/28/2015 01:41 AM, Ingo Molnar wrote:
>
> > What you want here is to make the (in-memory) FPU state valid and current, 
> > before reading it, and the function to use for that is 
> > fpu__activate_fpstate_read() (available in the latest tip:x86/fpu tree).
> 
> Do we really want to unconditionally activate the FPU?
>
> Let's say supporting MPX didn't require eager mode and someone called 
> get_xsave_addr().  We would ideally want to keep the FPU inactive and just 
> return NULL.  Right?

So there's two distinct types of 'active' here:

  - active fpstate (in-kernel memory context buffer)
  - active fpregs  (in-FPU hardware registers)

fpu__activate_fpstate_read() will only activate the fpstate for reads (as the name 
suggests it).

In your hypothetical case, if it's called with lazy FPU state then the fpstate is 
active already, and the fpstate represents the 'real' FPU state of the current 
task - while the FPU's contents are still some previous task's FPU state. So we 
can return the contents of this task's fpstate just fine even if the registers 
themselves are not (yet) loaded with them.

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.

Furthermore, I don't think we want to extend lazy FPU use, in fact I'm considering 
getting rid of it altogether, even on old CPUs: the CR0 fault costs are horrible 
all across the CPU spectrum (even for legacy CPUs), and modern user-space makes 
use of the FPU all the time.

Yes, on older CPUs, if user-space does not use the FPU but context switches 
frequently, then the cost of always doing FPU save/restore is measurable, but the 
worst-case I've measured was something like a 10% increase in context switching 
cost.

Thanks,

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