Bugzilla

Hyperthreading enables a number of timing attacks (e.g. PortSmash), including some new Spectre variants.  macOS now recommends that applications running untrusted code on a thread should call a new syctl that disables hyperthreading for that thread (preventing that thread from sharing a physical core with any other thread).  (The story for Linux/Windows is different, but requires no action from us, and if you're interested, ping me to discuss separately.)

The macOS security update containing the new sysctl is 10.14.5.  The WebKit patch which we want to basically copy that uses this sysctl is:
  https://trac.webkit.org/changeset/244233/webkit
The sysctls are used in CPU.cpp (which doesn't appear in the above diff view):
  https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/assembler/CPU.cpp?rev=244233

So we want to basically call `kern.tcsm_enable` on the main thread and any worker thread.  The JSC team reports a negligible slowdown from this in practice.

The only interesting bit is that this mitigation messes with the number-of-logical-cores count, which we use in various places and report to content via navigator.hardwareConcurrency.  In the above diff, WebKit seems to simply subtract 1 when the mitigation is active.  That seems off, at least for the purpose of navigator.hardwareConcurrency w.r.t workers.  I'd be inclined to just use the *physical* core count, when on macOS.  (Logical threads are only worth ~1.2 physical threads anyway.)

Ideally, we'd uplift this patch to FF67, for release in time for any upcoming public disclosures (to minimize risk, perhaps just the part that calls `kern.tcsm_enable`, the logical-core-count part could ride the trains).

Hyperthreading enables a number of timing attacks (e.g. PortSmash), including some new Spectre variants.  macOS now recommends that applications running untrusted code on a thread should call a new syctl that disables hyperthreading for that thread (preventing that thread from sharing a physical core with any other thread).  (The story for Linux/Windows is different, but requires no action from us, and if you're interested, ping me to discuss separately.)

The macOS security update containing the new sysctl is 10.14.5.  The WebKit patch which we want to basically copy that uses this sysctl is:
  https://trac.webkit.org/changeset/244233/webkit
The sysctls are used in CPU.cpp (which doesn't appear in the above diff view):
  https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/assembler/CPU.cpp?rev=244233

So we want to basically call `kern.tcsm_enable` on the main thread and any worker thread.  The JSC team reports a low (<=1%) slowdown from this in practice.

The only interesting bit is that this mitigation messes with the number-of-logical-cores count, which we use in various places and report to content via navigator.hardwareConcurrency.  In the above diff, WebKit seems to simply subtract 1 when the mitigation is active.  That seems off, at least for the purpose of navigator.hardwareConcurrency w.r.t workers.  I'd be inclined to just use the *physical* core count, when on macOS.  (Logical threads are only worth ~1.2 physical threads anyway.)

Ideally, we'd uplift this patch to FF67, for release in time for any upcoming public disclosures (to minimize risk, perhaps just the part that calls `kern.tcsm_enable`, the logical-core-count part could ride the trains).