Spectre, Meltdown & related issues

[Niels Dossche]

Note: I'm not sure about all of this.
Using classification of https://arxiv.org/pdf/1811.05441.pdf

Processes

Processes can run in the same hardware protection domain, or in a seperate domain. In case of the same domain, we rely on software isolation.
We give each process a 4GiB slice, to be used as a data heap. Processes can only address in this slice because memory accesses are represented as a "64-bit heap offset" + "32-bit user offset". We control the 64-bit offset, so it is impossible to address outside of your own slice. The code the processes are executing is located elsewhere in memory.

Spectre-PHT, Spectre-BTB, Spectre-RSB, Spectre-STL

Microcode and compiler mitigations inside Cranelift may help (Cranelift currently doesn't do that)?

Meltdown

Meltdown-US (original meltdown)

This is about leaking kernel memory. As far as I know, you need to be able to construct an address pointing to the kernel memory you want to leak. Due to the way processes are set up, this is not possible.

Meltdown-P

?

Meltdown-GP (Rogue System Register Read, Spectre variant 3a)

Architecture system registers cannot be represented in WebAssembly. System registers are accessed inside the kernel itself, so I'm not sure if that can be used in a way.

Meltdown-NM (Lazy FP State Restore)

Solution: Always restore the FP state, don't use the lazy restore mechanism.
Most applications nowadays use SIMD optimisations anyways, so the impact is not too bad.

Meltdown-RW (Read-only Protection Bypass, Spectre variant 1.2)

Does this require the creation of an arbitrary pointer, or can it be exploited in another way?

Meltdown-PK

?

Meltdown-BR

Software doesn't have direct access to the instructions required to trigger a "Bound Range Exceeded" exception. If this is ever exposed, the kernel will have to be involved, so this could maybe be mitigated there?

Microarchitectural Data Sampling

The vulnerabilities need (at least) microcode updates.