Contributed by rueda on from the sedulously-mitigating-threats dept.
As part of ongoing mitigations against CPU vulnerabilities, -current has gained a new sysctl, "hw.smt", to control Simultaneous Multi Threading (SMT). This is disabled by default (only on Intel® CPUs, for now).
The full commit was:
CVSROOT: /cvs Module name: src Changes by: email@example.com 2018/06/19 13:29:52 Modified files: sys/arch/amd64/amd64: cpu.c sys/arch/amd64/include: cpu.h sys/kern : kern_sched.c kern_sysctl.c sys/sys : sched.h sysctl.h Log message: SMT (Simultanious Multi Threading) implementations typically share TLBs and L1 caches between threads. This can make cache timing attacks a lot easier and we strongly suspect that this will make several spectre-class bugs exploitable. Especially on Intel's SMT implementation which is better known as Hypter-threading. We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial. Since many modern machines no longer provide the ability to disable Hyper-threading in the BIOS setup, provide a way to disable the use of additional processor threads in our scheduler. And since we suspect there are serious risks, we disable them by default. This can be controlled through a new hw.smt sysctl. For now this only works on Intel CPUs when running OpenBSD/amd64. But we're planning to extend this feature to CPUs from other vendors and other hardware architectures. Note that SMT doesn't necessarily have a posive effect on performance; it highly depends on the workload. In all likelyhood it will actually slow down most workloads if you have a CPU with more than two cores. ok deraadt@
Stefan Sperling (stsp@) explained (elsewhere) that the last paragraph of the log message refers to OpenBSD's "giant-locked" kernel.
Update - Jasper Lievisse Adriaanse (jasper@) commented:
[...] Thanks to Ben Gras of VUSec for sharing an early version the research paper with us. More details will be made public soon as 'tlbleed'. [...]
Update - Theo de Raadt (deraadt@) provided a little more information:
[...] Thanks for saying that Jasper. And thanks to Ben for getting the paper to us. As demonstrated in the commit message, we hesitate to pass on more information. That remains Ben's thunder in Vegas. However we wanted to get a usable mitigation for the problem into public. Maybe Intel has solutions with less overhead. But Intel excluded us from conversation so we don't know what those solutions might be. So we follow a pattern of immediately releasing a rough solution, which we can retract if a cheaper solution becomes published. [...]
(Comments are closed)
By Alessandro Gallo (llgxela) on
Will this be backported to stable?
By chas (chas) on
While the kernel architects have likely thought through this much more thoroughly than I ever could, a few things spring to mind...
It would be nice if the scheduler could detect web browser processes or other untrusted programs and launch them in a "sanitize" mode, causing the kernel to erase caches before and after future time slices for all child processes (in addition to any sandboxing the browser parent process and the OS were already doing).
It might also make sense if only processes with the same UID could run on different SMT threads on the same core, rather than just turning them off completely. Perhaps a whitelist of allowed UIDs would not compromise security, but better safe than sorry in any case.
By Matthieu Herrb (mherrb) firstname.lastname@example.org on
here we go : https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_data_leak/