The thing is, Intel et al are pushing LAM as a counter to SPECTRE.

This paper is pouring cold water over it saying "hey you know your supposedly SPECTRE-proof CPUs? You've just opened up a whole new class of EXPLOITABLE vulnerabilities".

SLAM is so-called because it's an attack on LAM. And the paper is saying "no it's not a theoretical attack no-one knows how to exploit. This will work!". Intel et al haven't addressed that because this exploits a new side channel that no-one saw.

Cheers,
Wol

Posted Dec 9, 2023 11:39 UTC (Sat) by fw (subscriber, #26023) [Link]

I'll take what you said as a little hyperbolic, but there may be some benefit to _security_ aware process scheduling. Maybe this isn't workable as I am not an expert in SPECTRE or other CPU hardware issues, but couldn't some of the mitigation slow downs be avoided if the kernel avoided running workloads in different security zones on the same CPU cores or sharing affected resources, treating your 16-core system more like a network of 16 mutually untrusting independent systems? VM hardware keeping a customers workloads on the same socket/cores so you can't use these techniques to access other customers data? Or just futher partitioning the hardware such that each CPU socket and RAM set is even more independently its own system with a more OS-controlled access between NUMA nodes? Such that single-process speed is hardly affected, but message passing between processes/VMs/nodes has more scrutiny/overhead?

It's just a thought from a layman.

Posted Dec 8, 2023 12:10 UTC (Fri) by farnz (subscriber, #17727) [Link]

You need CPU vendor support for security-aware process scheduling; the underlying issue with Spectre-type vulnerabilities is that the CPU will execute code that accesses a shared resource (such as the memory controller) speculatively, then roll back the result because speculation turned out to be a dud. However, a consequence of executing that code is that the behaviour of the shared resource as seen from another point in the system is measurably perturbed, and this applies whether that resource is L1D cache, a DRAM controller, a NIC, or other shared resource.

There is a point at which the resource perturbation becomes sufficiently hard to measure that the side channel exists, but is not useful; if the side channel's data rate is 1 bit per century, for example, then it's essentially useless in practice, even though it exists in theory.

Invisible speculation as mentioned by anton is a permanent fix, but it adds significant cost to the hardware (since you now need copies of hardware structures to store speculative state), while also reducing performance (since you need to avoid most forms of resource contention, but part of the gain of speculation is that it lets you issue requests to shared resources earlier, causing contention that's usually valuable).

Posted Dec 8, 2023 14:49 UTC (Fri) by corbet (editor, #1) [Link]

Your suggestion sounds a lot like core scheduling; that addresses some Spectre attacks but not all of them.

Short of completely flushing all of the processor's caches and prediction tables on every context switch, which would probably be so slow as to cause palpable lag on every keystroke, I doubt partitioning based on the existing concept of processes as security boundaries could ever be made 100% airtight.

Posted Dec 7, 2023 16:48 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

SLAM: a new Spectre technique

Posted Dec 7, 2023 17:06 UTC (Thu) by farnz (subscriber, #17727) [Link]

You don't need 100% airtight; you have two goals:

1. Slow down the side channels to a rate where extracting useful information in reasonable time is not possible. Being able to extract a private key if you can saturate the processor for 1,000 years is not a useful attack.
2. Ensure that, in as far as possible, the side channels follow along with the architectural state transitions of the program, so that the side channels are predictable from the program binary. This means that, for example, a side channel caused by the program choosing to use a 16×16 ↦ 32 multiply for some data, and a 32×32 ↦ 32 multiply for other inputs is out of scope, since that's visible from the program binary, but one caused by the processor identifying that the inputs both fit in 16 bits and using a 16×16 ↦ 32 multiply when the program used a 32×32 ↦ 32 multiply instruction is in scope.

We don't care about perfect partitioning - we only care that the failure of the partitioning is caused by architecturally visible state transitions, and not by hidden speculative transitions that get unrolled. And part of the pain is that there is no existing concept of security boundary that works here; my compiler, my text editor, my linker and my terminal are all inside one security boundary despite being many processes, while each tab in my browser is typically in its own security boundary, even if some of the work is done by a thread shared by multiple tabs.

Ultimately, the goal is to be able to prove once that a given binary image meets a set of security guarantees, and to not be caught out when a new microarchitecture comes out and does things differently. That means that, when I'm crossing a security boundary, I need to be careful not to create a new side channel that's not visible in the architecture model of the world - and any failed speculative execution is a big pain there, because (by definition), it's executing code that's not visible in the architecture model.

Speculating across security boundaries may be an important part of currently-practical speculation exploits, but I'm not sure it's fundamental to speculation vulnerabilities in general. The way I see it is:

You can have side channels that have nothing to do with speculative state, e.g. if there's an instruction that consumes more power when processing a non-zero register value, and code on the other side of a security boundary that can read the CPU's temperature to determine recent power usage. That's a much less convenient and lower-bandwidth channel than shared L1 cache state, but in principle it should still work. There are also side channels that cross boundaries outside of the CPU, like with NetSpectre. Shutting down all side channels seems an impossible task, so we have to assume they exist.

Code with access to sensitive data can transmit that data over a side channel, violating the security boundaries. Without speculation, that can be done deliberately (e.g. attacker-controlled code that is given access to sensitive data inside a sandbox) or unwittingly (e.g. non-constant-time crypto algorithms). In the former case, that's a bad system architecture - you shouldn't trust sandboxes that much. In the latter case, it's simply a software bug, and it's the software developer's responsibility to fix their code.

I think the fundamental problem with speculation is that in the latter case, fixing your code is not sufficient, because the CPU is not actually executing the code you wrote; it's executing a guess at what you wrote. No matter how careful you are to write constant-time constant-power constant-memory-access-pattern code that doesn't transmit over any side channels, the CPU might decide to execute some arbitrarily different code that does transmit, and you have very little visibility or control because it's usually an undocumented microarchitecture detail. Software developers can't be expected to fix bugs in code that was never written.

It's much easier for an attacker to trick the CPU into executing dangerous unwritten code when there is cross-security-boundary speculative-execution state (branch target buffer etc), but that's not fundamental either: Spectre-V1 did not rely on that. Spectre-V1 just passed some carefully-crafted valid input across a well-defined security boundary, and the correctly-written code on the other side of that boundary had its control flow and memory access patterns influenced by that input - which is perfectly normal behaviour for any non-trivial API - in a way that speculatively executed some unwritten code that copied sensitive data into a side channel.

In Spectre-V1 that API was eBPF, which gives the attacker an unusually high level of control, making the attack much easier. And eBPF gives an obvious place to define a new security boundary, preventing it accessing sensitive data from outside its sandbox, if that was technically possible. But I don't see a fundamental difference between eBPF and any other bog-standard API that processes untrusted input, where in general it's infeasible to define a security boundary between that API and all sensitive data (given the API might need to use some of that data itself), and where you could get unlucky with speculative execution on some current or future microarchitecture. Perhaps it's very unlikely that anyone will find a practical exploit for those APIs - but the components of Spectre were already known and not considered practical to exploit, until Spectre proved it was, so that's not much of a guarantee.

So, I don't think security boundaries are the real issue here; strengthening the boundaries might be a useful mitigation but won't fully solve the problem. Software developers not being in control of what code the CPU executes, and therefore not being in control of its side-channel behaviour, is the fundamental issue.

Posted Dec 7, 2023 18:34 UTC (Thu) by anton (subscriber, #25547) [Link]

Yes, you can mitigate non-speculative side channels by writing constant-time constant-memory-access code for accessing the secrets (I don't think that CPU manufacturers have defined constant-energy operations); this mitigation is practical for cryptographic code, where the code dealing with the keys is small. It is impractical for other code. However, we don't know a good hardware way to eliminate the side channels in hardware, so that is a problem that we accept.

Speculation means that all code in the address space can be used to access the secret and reveal it through a side channel (Spectre); this means that, without hardware fix, we have to put mitigations in all code, which has only been done in the kernel (and we have to hope that they put in enough mitigations, because they applied them selectively to reduce the slowdown).

But, in contrast to classic side channels, there is a way to fix Spectre in hardware that costs little performance and an acceptable amount of silicon: Divide the microarchitectural state into a speculative and committed state just as we have done with the architectural state since the mid-1990s; and when a speculation turns out to be wrong, squash the speculative microarchitectural state just like we have been doing for the architectural state. This is known in the literature as "invisible speculation". There is also a need to avoid a resource-contention side channel between the speculative and the committed world, but that is also doable.

Now all we need is that some CPU manufacturer actually implements these concepts, and we, the customers, need to buy the resulting CPUs.