Everything we thought we knew about isolation is downstream of one week in January 2018.
Before that week, "the MMU will handle it" was a perfectly reasonable engineering position. The hardware privilege boundary was the solid floor under every design decision anybody made about isolation. Now the floor is a thing with known leaks, across essentially every speculating processor shipped for two decades. Not uniformly, as the Meltdown and Spectre split below shows, but industry-wide.
What broke¶
Speculative execution is a feature, and a very good one: predict the branch, run ahead, throw the work away if you guessed wrong. It is the central technique that made processors fast.
The assumption was that discarded work is architecturally invisible, and it was wrong in one specific way. Speculation leaves traces in microarchitectural state, mostly the cache. A load that "never happened" still evicted a cache line, and cache timing is measurable from userspace. The burglar did not get in, but you can still see his footprints in the flowerbed.
Meltdown uses that to read kernel memory from an unprivileged process on affected Intel parts: speculate past the permission check, touch the data, then read it back out through the cache side channel.
Spectre is the harder and more general problem. You train a branch predictor so that another context speculates down a path of your choosing. There is no single bug to patch; it is a property of the technique.
The mitigation, and the cost¶
KPTI (kernel page-table isolation) deals with Meltdown by unmapping kernel memory from the user page tables, which means a page-table switch on every syscall. It merged into the 4.15 cycle, just before rc6 (LWN). That cost is entirely workload-dependent: Google reported the impact as depending on the rate of system calls an application makes (Google), which is the correct way to describe it.
The figures flying around this fortnight are wild. Press reports of 5-30%, vendor statements that the impact "should not be significant", field reports converging on roughly 20% worst case for syscall-heavy database and web workloads and near-zero for desktop use. FreeBSD's own write-up was refreshingly blunt that PTI incurs a regression, some of which PCID work regains. For Spectre variant 2, Google's retpoline mitigation (LWN) is reported as having negligible impact across its fleet.
So a single percentage figure for this is meaningless, and almost every number quoted this month is either a syscall-bound worst case or a desktop best case, dressed up as a general one.
Why it changes architecture, not just patch cycles¶
Three consequences that will run for years.
Isolation got more expensive, so people will want it finer-grained. If you are paying for a boundary, you want it where the risk is, not at whatever granularity the hardware chose for you.
Shared tenancy has a new question. "Is a container enough?" was a pub argument. Co-tenancy with a cross-privilege side channel makes it an operational one. Our bet on the answer: something that puts a hardware boundary back under each tenant while keeping the start-up time and density that made containers win. A hypervisor stripped down until it costs almost nothing to boot, or a kernel interface narrow enough to reason about. We would not bet on which, but we will bet that most of the next five years of isolation engineering is this.
Hardware has stopped being a trust anchor by default. Expect a generation of mitigation to move into silicon, because the software workarounds are expensive and partial. Expect the harder shift to follow: a demand that the layer underneath you be verifiable rather than assumed. Buying a CPU on the vendor's word about its isolation properties has just been shown to be a position, not a baseline.
What the mitigations make possible¶
A boundary with a measurable price is a better engineering object than a boundary everybody believed in for free.
Once isolation has a number on it, you can spend it where it matters: this workload gets a hardware boundary and pays the measured price, that one gets a namespace and costs nothing, and here is the arithmetic. Most systems today apply one boundary everywhere because nobody knew the alternative's cost. The next few years should produce infrastructure where a regulated workload and a cache warmer sit on the same hardware under provably different isolation, which is cheaper and safer than the two-estates answer everyone reaches for now.
The toil this kills is the security argument conducted on intuition. "Is a container enough" has been unanswerable for five years because nobody could price either side. It is about to become a measurement.
Cheap verifiable isolation is also what makes shared infrastructure safe for people who currently cannot use it. A GP surgery, a law firm, a local authority: all are told to keep data on their own kit because the best answer anyone could give about co-tenancy was "probably fine". Replace that with a boundary you can test and the economics of small organisations running proper systems change completely.
Who got the fix first, and who cannot read it¶
Two things about this month should make every engineer outside a hyperscaler angry, and both are about access rather than the bug.
The embargo ran for roughly six months. Google's Project Zero reported this to Intel, AMD and Arm on 1 June 2017 (Project Zero), and the large cloud operators had working mitigations deployed across their fleets before the rest of us learned there was anything to mitigate. Defensible on disclosure grounds, and it still means the companies that most needed the protection had half a year of it while everybody else had none. If embargo access tracks market share, security scales with size.
The second is worse because it is permanent. The microcode patching your CPU's branch predictor is signed, encrypted and undocumented. You cannot read it, verify what it changed or build it yourself. You are applying an opaque binary to the most privileged component in your machine, from the vendor whose design error caused the problem, on their assurance. Two companies hold the only keys that can modify the hardware everyone's security rests on. Every other isolation argument sits on top of that.
If hardware trust has to be verified rather than assumed, the attestation machinery arriving over the next few years will itself be rooted in keys held by the silicon vendors and the platform operators. Done well, that gives you evidence about the machine you are running on. Done the way the incentives point, it gives three companies the power to decide which software may run and a cryptographic record of every machine that ran it. The difference is who holds the keys.
We run on hardware we own, patch kernels we can read and treat any isolation claim we cannot test as marketing. Trustworthy computing in which the only verifiable machine is a rented one is the wrong destination, and the open tooling for measuring your own boundaries needs to keep up.
Keep the measurement, not the panic¶
A boundary you cannot inspect is a boundary you are trusting on reputation.
Spectre has not made hardware untrustworthy. It has made explicit that hardware was always trusted without evidence, and that twenty years of optimisation was quietly spending a security property nobody was measuring. Rather like discovering the surveyor never looked at the foundations because the house was already standing.
Every strand of the isolation work now starting is a different answer to the same follow-up: so where do we put the boundary now, and how do we check it?