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  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:	Sat, 1 Feb 2014 11:46:15 -0800
From:	Linus Torvalds <>
To:	"H. Peter Anvin" <>
Cc:	Suresh Siddha <>,
	Nate Eldredge <>,
	Thomas Gleixner <>,
	Ingo Molnar <>,
	"the arch/x86 maintainers" <>,
	stable <>,
	Linux Kernel Mailing List <>,
	Maarten Baert <>,
	Jan Kara <>, George Spelvin <>,
	Pekka Riikonen <>
Subject: Re: [PATCH] Make math_state_restore() save and restore the interrupt flag

On Sat, Feb 1, 2014 at 11:35 AM, H. Peter Anvin <> wrote:
> This will obviously not protect eageronly features (MPX, LWP, ...) so this
> means those features are permanently unavailable to the kernel, even inside
> kernel_fpu_begin/end.  Now, currently I don't think we have any plans to use
> those in the kernel (at least not in a way where kernel_fpu_begin/end makes
> sense as bracketing), but it is something worth keeping in mind.

Hmm. If there are features that (silently) depend on the FPU state
being on, then the plain "stts" doesn't work at all, because we'd be
returning to user space too (not just kernel space) with TS turned

.. which *does* actually bring up something that might work, and might
be a good idea: remove the "restore math state or set TS" from the
normal kernel paths *entirely*, and move it to the "return to user
space" phase.

We could do that with the whole "task_work" thing (or perhaps just
do_notify_resume(), especially after merging the "don't necessarily
return with iret" patch I sent out earlier), with additionally making
sure that scheduling does the right thing wrt a "currently dirty math
state due to kernel use".

The advantage of that would be that we really could do a *lot* of FP
math very cheaply in the kernel, because we'd pay the overhead of
kernel_fpu_begin/end() just once (well, the "end" part would be just
setting the bit that we now have dirty state, the cost would be in the
return-to-user-space-and-restore-fp-state part).

Comments? That would be much more invasive than just changing
__kernel_fpu_end(), but would bring in possibly quite noticeable
advantages under loads that use the FP/vector resources in the kernel.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists