Hacker News Reader

Comment by amluto | Hacker News Reader

Linux hasn’t used CR0.TS for some time. I removed it a while back because manipulating TS is very very slow.

(I am not part of any process with respect to this, embargoed or otherwise.)

Edit: the upstream commit is 58122bf1d856a4ea9581d62a07c557d997d46a19, called “x86/fpu: Default eagerfpu=on on all CPUs”, and it landed in early 2016. Greg K-H just submitted backports to all older supported kernels.

View on HN

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

AFAIK the entire idea dates back to the days of the 80286/80287 (and 80386/80387) when accessing the coprocessor was slow, and a TSS switch (Linux used it until the late 1990s) set that bit for you.

Wasn't 212b02125f3 ("x86, fpu: enable eagerfpu by default for xsaveopt") sufficient protection for everyone on a modern CPU?

That commit disables the lazy mode by default on processors supporting the XSAVEOPT instruction. But, it's possible to override that default with the eagerfpu= kernel command-line option, or that a hypervisor has masked out support for that instruction even on hardware with XSAVEOPT support.

The point is: although relatively unlikely, it is still _possible_ that you need some mitigation even if you have newer hardware (Sandybridge or newer is where XSAVEOPT first showed up, I believe).

Disclaimer: I work on Linux at Intel.

Eagerfpu seems to mitigate it, but some confirmation would be good here.

Reply on news.ycombinator.com