[Cryptography] Buffer Overflows & Spectre

[Jon Callas]

I understand what you’re saying, but here, irony perhaps, but not betrayal, no.

I’ve been dealing with this for a year now, and it’s not quite what your saying, if I understand you. It’s nothing to do with buffer overflows, but with memory disclosures. It’s a sidechannel or covert channel issue.

Your metaphor about automobiles doesn’t quite hit the mark. In the case of the emissions testing that was an intentional thing put in to fool regulations. CPU manufacture is not regulated at all, and Spectre is so unlike emissions or even braking that it’s hard to comment about what would tune the metaphor. It’s not fraud, by any sense, since there’s no intent there. Moreover, there are no direct analogues of such a problem to automotive technologies. (Note that I didn’t call it a bug; it’s not a bug, it is an emergent consequence of design.)

Out of order instruction execution first appeared in the IBM 360/91 back in 1968. In our world, it appeared in PCs with the PPC 603, and in x86 CPUs with the AMD K5 and the Pentium Pro. Back in the day, there were some Multics papers about covert channels (Paul Karger did some nice ones) related to speculative execution, but by and large no one really considered it an issue. It’s been a mainstay of CPU design for well over twenty years.

If one wants to rail about something, it would be the misplaced use of metrics and the truism that “if you can’t measure it, it doesn’t exist." We’re in this mess because we care about performance (which we can measure) more than anything like security (which we can’t). I think it’s far more like the present mess with C compilers where the compiler people have gone and created so much undefined behavior that C is no longer a low-level language. There was a time where the problem with C was that since there was little to no optimization in the compiler that it all fell to the author to write efficient code (which was often silly because the other major facet of C was its alleged portability). As C delivered on the portability promises and started getting into more optimization, that led us to the security problems of today where it is very hard to write a program with no undefined behavior. We’re up to nearly 200 different types of undefined behavior.

Anyway, getting back to this, the problem we face is how to make systems that are faster without these side effects. The promises that CPU designers have been giving us and also we demand is what gets hand waved as “Moore’s Law” a shorthand for seeing continuous, regular performance gains over time.

On top of this, there’s no easy way to fix pipelining to make this go away. Even getting rid of speculative execution doesn’t make it go away, since it is timings that cause the memory leak. Even getting rid of caches doesn’t fix the problem because RAM often has its own internal caches (which cause timing differences) and even bare RAM has timing differences caused by locality of reference. Getting rid of high-resolution clocks doesn’t fix it, either, because a spin loop is a close enough approximation to a clock to make it work.

The only real ways to get rid of this is to go back to an architecture where the CPU clock is the same as the memory clock, there are no speedups in memory fetching nor in pipelines, and likely more. I’ll bet even that doesn’t do it.

There are people thinking about things that could fix this, some of which are outré, and some are complete rethinks of computer architecture, like flat address spaces with memory tagging.

This is far, far worse than most people think because it goes to the very core of the fact that any sort of a distinguisher is a side channel.

	Jon