Stream: git-wasmtime

Topic: wasmtime / issue #1032 Mitigating Spectre attacks

Wasmtime GitHub notifications bot (May 04 2022 at 20:09):

cfallin commented on issue #1032:

I'm doing some issue gardening here and I believe we have done most of the above by now: we have conditional move-based mitigations on heap accesses, table accesses, and branch table loads. We don't have any indirect predictor-specific mitigations yet, but we're working on incorporating hardware CFI techniques (see bytecodealliance/rfcs#17).

I'll leave it up to our processor-vendor folks whether they think we have sufficient mitigations now, or with the CFI features, to mark this issue "resolved" -- @akirilov-arm, @abrown, @uweigand, others, what do you think?

Wasmtime GitHub notifications bot (May 04 2022 at 20:09):

cfallin labeled issue #1032:

Hello,

You are probably well aware, but some mainstream compilers are emitting retpolines to help mitigate Spectre variant 2 attacks. Do you have any plans to add a similar capability to the cretonne code generator (and/or do you think it makes sense for cretonne to do this sort of thing)?

Thanks,
Jon

/cc @tyler @pchickey

Wasmtime GitHub notifications bot (May 04 2022 at 20:09):

cfallin labeled issue #1032:

Hello,

You are probably well aware, but some mainstream compilers are emitting retpolines to help mitigate Spectre variant 2 attacks. Do you have any plans to add a similar capability to the cretonne code generator (and/or do you think it makes sense for cretonne to do this sort of thing)?

Thanks,
Jon

/cc @tyler @pchickey

Wasmtime GitHub notifications bot (May 10 2022 at 18:54):

akirilov-arm commented on issue #1032:

Concerning the Arm architecture, Arm has published documentation on the various speculative execution vulnerabilities. Unfortunately the hardware CFI techniques that are discussed by the RFC proposal mentioned above do not really help with speculative execution attacks that target indirect branch predictors - they rely on instructions that raise processor exceptions, which in most implementations does not happen while executing speculatively; that is somewhat similar to the straight-line speculation vulnerability covered by the documentation.

As for the attacks that apply to conditional direct branches, e.g. bounds checks, according to Arm's guidance the conditional moves should be followed by the CSDB instruction in order to future-proof the mitigations (that barrier instruction executes as a no-op on processors that predate it).

Wasmtime GitHub notifications bot (Jul 27 2022 at 20:03):

akirilov-arm edited a comment on issue #1032:

Concerning the Arm architecture, Arm has published documentation on the various speculative execution vulnerabilities. Unfortunately the hardware CFI techniques that are discussed by the RFC proposal mentioned above do not really help with speculative execution attacks that target indirect branch predictors - they rely on instructions that raise processor exceptions, which in most implementations does not happen while executing speculatively; that is somewhat similar to the straight-line speculation vulnerability covered by the documentation.

As for the attacks that apply to conditional direct branches, e.g. bounds checks, according to Arm's guidance the conditional moves should be followed by the CSDB instruction in order to future-proof the mitigations (that barrier instruction executes as a no-op on processors that predate it).

Wasmtime GitHub notifications bot (Sep 16 2022 at 19:37):

akirilov-arm commented on issue #1032:

Recently I have done a little bit of research on Spectre-V2, and my conclusion is that on AArch64 the only efficient mitigation (so I exclude techniques such as retpolines) is provided by the FEAT_CSV2_2 extension to the Arm architecture. It specifies a system register, SCXTNUM_EL0, that can be used to associate a software-defined context number with branch prediction, and as a result branch predictions for one context are unable to influence speculative execution in another one. So, one implementation approach would be to reserve a context number, e.g. 0, for the WebAssembly runtime, and then come up with a number for each Wasm context that the runtime manages. On a transition from the runtime implementation to a Wasm module, for example, it would be necessary to execute:

msr scxtnum_el0, xn
isb

where Xn holds the context number associated with the Wasm module. Note that no changes to the code generated from WebAssembly are necessary. Depending on the threat model, it might also make sense for each Wasm module to get its own runtime context number (that is, the runtime is not always going to use 0), or even a (pseudo)random value (the PACGA instruction provided by the pointer authentication extension is an efficient way to obtain one). The hardware itself does not assign a special meaning to any context number value.

The FEAT_CSV2_2 extension is supported by recent processors such as Arm Cortex-A510, A710, A715, X2, and X3, and also Arm Neoverse N2. Unfortunately AFAIK the Linux kernel (as of version 6.0-rc5) does not expose an interface such as getauxval(AT_HWCAP2) to query about the availability of that extension.

We also have a similar attack to contend with, Spectre-BHB. The mitigation against it is to execute a small loop that would be located right next to the operation setting SCXTNUM_EL0 - the details are in the white paper that Arm has published about the attack. Future processors may have even more efficient mitigations - the white paper covers those too.

Last updated: Oct 23 2024 at 20:03 UTC