OpenBSD Journal

SMT Disabled by Default in -current

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:	kettenis@cvs.openbsd.org	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)


Comments
  1. By Alessandro Gallo (llgxela) on

    Thank you,

    Will this be backported to stable?

  2. 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.

  3. By Matthieu Herrb (mherrb) matthieu@openbsd.org on

    here we go : https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_data_leak/

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]