microarchitectural security
The instruction set architecture (ISA) is a clean contract: it promises what each instruction computes, and deliberately says nothing about how fast it runs or what hidden machinery is involved (see instruction-set-architecture). Underneath, the microarchitecture — caches, pipelines, branch predictors, out-of-order engines — is a churning factory of optimizations that the contract hides. Microarchitectural security is the study of how that hidden machinery, even when every instruction's official result is correct, can leak secrets through its physical side effects: timing, power, and shared cache state.
The core insight is that the ISA's abstraction is a lie of omission, and attacks exploit exactly what it leaves out. Two programs sharing a cache leave traces in each other's timing: if a secret-dependent memory access loaded a cache line, a later access to that line is measurably faster, and an attacker who can time memory can read out a bit of the secret it was never given. Speculative and out-of-order execution make this far worse: the processor races ahead on guesses, touching data it should not, and although it discards the wrong-path results from the architectural state, the microarchitectural traces — a warmed cache line — remain and can be measured. Spectre and Meltdown are the famous examples (see spectre-vulnerability and meltdown-vulnerability).
The honest and uncomfortable lesson is that performance and security are often in direct tension here. The very features that make modern CPUs fast — caching, prediction, speculation, sharing resources between threads — are what create these channels. You cannot simply turn them off without giving up much of the speed, and many of the fixes (flushing predictors, partitioning caches, adding fences) cost real performance. This is a young field built on a sobering realization: some of these leaks are not bugs to be patched away but consequences of how fast computers are made to work, mitigated rather than fully cured.
Two virtual machines share a physical CPU and its cache. One runs a victim that accesses a secret-dependent address; the other runs an attacker that repeatedly times its own accesses. Every instruction's official answer is correct and the VMs are 'isolated' — yet by watching which of its cache lines became fast, the attacker reconstructs the victim's secret, purely from timing. No instruction result was leaked; the microarchitecture leaked.
Correct results, leaked secret: the ISA contract was kept, but the microarchitecture's timing told the tale.
These are not software bugs in the victim's code — the program can be perfectly correct and still leak. Microarchitectural security is hard precisely because the leak lives below the level any programmer normally reasons about.