[Cryptography] Buffer Overflows & Spectre

[Jon Callas]

> On Nov 20, 2018, at 9:03 PM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> 
> Jon Callas <jon at callas.org> writes:
> 
>> On top of this, there’s no easy way to fix pipelining to make this go away.
> 
> "Don't allow malicious, attacker-controlled code to run on the same CPU/CPU
> cluster as your precious secret-containing code" would be a good start.

Yeah, that’s pretty much it.

Arbitrary, hostile code can dump all of memory. The end.

> 
> Maybe CPU vendors could break their existing products into two distinct lines,
> one for people who think that sharing their CPU with code from
> pavel at virusbucket.ru is a good idea (speculation disabled) and one for people
> who don't (normal operation).

That’s one issue; or it’s an issue that has different facets. If you’re running servers (etc.) then clients can spy on each other. If you’re running client software (oh, like a web browser running Javascript), then you have to be careful that the JS doesn’t manage to get a covert channel on other things.

I can think of other architectural changes one can make that would mitigate this, if we’re allowed to go back to square one on everything. You could, for example, separate out cores completely and have essentially one job-set per CPU and allow “swapping” across CPUs. You could come up with memory allocation and deployment schemes that get rid of the problems. They are all, however, unproven and they all lower performance. There are ways to tweak the existing architectures to get rid of the problems, but they all hurt performance, and even then they might not work, because we’re starting to understand that merely allowing two processes to share the same RAM opens up the potential for these side channels. It’s possible that the only *real* fix is single-threaded, clockless architectures. I don’t know, myself. It’s all a huge mess, and the more one studies it the more interesting it is, where “interesting” is a euphemism for “broken."

	Jon