Security vulnerabilities¶

Modern processors are marvels of engineering that achieve extraordinary performance through techniques so clever they occasionally create security holes you could drive a coach and horses through, assuming the coach and horses were made of malicious code and interested in stealing cryptographic keys. The industry spent decades optimising for speed while treating security as something to consider after performance, reliability and cost were sorted, which worked adequately until researchers discovered that many of the optimisations were simultaneously elaborate mechanisms for leaking information to anyone who asked the processor politely.

Spectre and Meltdown, disclosed at the start of 2018, were the wake-up calls. It was rather like discovering that The Patrician’s Palace, assumed secure because of the guards and the complicated locks, had hollow walls accessible from the buildings next door. The walls performed their architectural function excellently. They just did not perform their security function at all, and nobody had checked whether the two might conflict.

How speculation betrays¶

Speculative execution lets a processor run instructions before knowing whether they should run, discarding the results if the guess was wrong. The performance case is excellent, since the guesses are right most of the time. The security problem is that discarded work leaves traces: speculatively touched data lingers in caches, and an attacker measuring cache timing can read, indirectly, memory that architecture says is protected. Meltdown used this to cross the boundary between user programs and the operating system; Spectre, subtler and more general, trained the processor’s branch predictor to speculate down paths of the attacker’s choosing. The abstraction, that instructions either execute visibly or not at all, turned out to be false in the side channels, and security had been resting on the abstraction.

Paying for it afterwards¶

Fixing hardware after deployment offers only bad options: disable the optimisation and lose the performance it bought, or patch around it in microcode, operating systems and compilers, each layer adding overhead that can reach double digits for system-call-heavy workloads. Cloud computing felt it hardest, because multi-tenancy assumes strong isolation between customers sharing a processor, and side channels ignore that assumption; providers disabled features, rescheduled workloads, and quietly revised the economics of sharing. And the original pair proved to be a category rather than a couple: transient-execution variants, store buffer leaks and sampling attacks have arrived steadily since, each with its own patch and its own tax. Every mitigation is a tacit admission that the performance had been borrowed from security all along, with interest accruing silently, which makes this the section’s purest specimen of technical debt: incurred invisibly at design time, discovered by researchers, repaid by everyone else.

The slower lesson¶

Newer processor generations carry hardware mitigations for the known attacks, and security has moved earlier in the design process, a genuine cultural shift with an obvious caveat: the mitigations address the vulnerabilities that are known. Speculative execution existed for two decades before anyone published what it leaked, which suggests the interesting question is not whether current designs contain equivalent surprises but who finds them first. The economics have not changed underneath: customers buy performance, vendors compete on benchmarks, and security remains abstract until a named attack with a logo makes it concrete. The tension cannot be engineered away. It can only be managed, imperfectly, by people who remember the last time.

The clerk’s note¶