The Next Vulnerability: Looking Back on Meltdown and Spectre One Year Later
rambus.com
rambus.com
We could have found the spectre exploit 20 years ago. To me, the fact that we didn't until now is maybe the most interesting thing.
Some aspects of these were known 20 years ago.
http://www.cse.psu.edu/~trj1/cse543-f06/papers/vax_vmm.pdf section VI.E)
I suspect it's because there was still plenty of far simpler and more obvious exploits to look at.
Back then, people were smashing the stack for fun and profit. Think about it! Executable stack! No canary! No ASLR! Can't be more fun.
Is this a thing? I have not heard of anyone working on trying to replace x86 with RISC-V because of Spectre…
But probably nothing of enough volume to be notable.
Risc-V would be unlikely, since there's not yet real server class silicon.
Not a hardware guy or a driver programmer but I believe this area stands to get some innovation.
Speculation and branch prediction is not going away. On the contrary is going to get more and more sophisticated.
What needs to die is the belief that you can rely on just software (i.e. memory safety) for isolation between trusted and untrusted code[1].
[1] Yes, meltdown bypasses hardware protection, but that's an intel specific fuck up, not inherent issue with speculation.
I don't understand how you came to this conclusion. How does spectre indicate that you can't rely on software for isolation?
> meltdown bypasses hardware protection, but that's Intel specific
It's not Intel specific. Certain ARM and POWER architectures are also vulnerable.
Spectre bypasses hardware protections too, just in a more subtle way.
Given if f(A) B else C, one cannot safely assume that B only gets executed when A resolves to true. It is not reasonable to expect programmers to produce safe code in an environment where they have to doubt if statements.
This could be solved without any major overhauls in hardware, by just updating it to make speculative execution actually speculative and not commit any side effects until it knows it went down the correct branch.
This comment:
> What needs to die is the belief that you can rely on just software (i.e. memory safety) for isolation between trusted and untrusted code
is an argument that doubting if statements should be acceptable, and that the assumption that only B has architecturally visible side effects when A is true is not sound. I disagree strongly with that.
You should be able to rely on software checks for some things. Going forward, the solution is not to rewrite software to not depend on software mechanisms (e.g. bounds checks) for protection (unclear what would be used instead...) but to fix the hardware so these software mechanisms work.
What needs to "die" is not "belief that you can rely on just software," but hardware that violates fundamental guarantees.
It sounds like we agree on this, I just wanted to make my point clear since I see now that my original comment was not clear.
FWIW, this is essentially the argument Torvalds made when Intel tried to add feature flags for non-broken speculation.
Even otherwise strictly in order designs, when aiming for high performance incorporate some form of memory speculation (scout threading, run ahead execution).
Edit: to be precise they can, for example, see the transition from exclusive to shared.
Not notifying other CPUs seems pointless because before committing you would have to do a round-trip to the other core to verify whether the data is still valid making the prefetching pointless.
A more practical solution is probably to have protection boundaries within the cache, like http://people.csail.mit.edu/vlk/dawg-micro18.pdf.
There are also chips like the GA144, which has 144 cores:
https://www.rs-online.com/designspark/hands-on-with-a-144-co...
That is definitely true. We need a bit more security in the hardware. I am not saying we should go back to 300MHz CPUs just for the sake of security but surely there's a spectrum where Spectre / Meltdown / Rowhammer attacks are impossible and we still have very fast processors and RAM.
Note that 2+ decade old 200mhz pentium pro is very likely as vulnerable to spectre as the current generation. Frequency doesn't really factor in it.
The issue is the basic spectre v1 vulnerability, the bound check bypass, is so firmly rooted in the basic mechanism of speculative execution that it is very unlikely to be fixable. But it only affect,as a first approximation, processes that try to execute code with different trust domains in the same address space. The existing software mitigations appear to help, address spac separation is probably a safer long term solution.
There are simple in order CPUs that have a small speculation window and are, in practice not affected, but it is not a given that an high performance in order core is safe. Denver (an inorder VLIW design) is affected; I can't find anything about power6 (the last inorder CPU competitive with OoO).
This is wrong, even as an approximation. This comment, as well as your other comments on this thread, indicate that you misunderstand spectre v1. Some of the initial proofs of concept of spectre v1 demonstrated the attack with both victim and attacker in the same process, but that is not necessary, and the original materials disclosing spectre make that clear.
The paper [1] describes spectre v1 as a technique in which "conditional branch misprediction can be exploited by an attacker to read arbitrary memory from another context, e.g., another process" [emphasis mine]. The others go on to describe a proof of concept in which a vulnerable code sequence is inserted in the kernel via ebpf, but the attacker is in user space: "we use the eBPF code only for the specu- latively executed code. We use native code in user space to acquire the covert channel information."
It's not clear whether spectre v1 style attacks within a single process can be prevented by hardware, but spectre v1 attacks in which an attacker process manipulates a vulnerable gadget in a victim process certainly can be.
Running untrusted code in the same process as trusted code has always been dodgy, and now will probably need speculation barriers at bounds checks. But the most worrying part of spectre v1 is how it can be used to bypass process (and user/kernel) isolation, and that can and should be fixed.
If you don't believe me, perhaps the document making its way into the kernel source (and the review comments) will make things clear: https://lkml.org/lkml/2018/12/21/577
If you are still not convinced, take a look at these patches merged into Linux to mitigate a vulnerability you are arguing doesn't exist: https://lkml.org/lkml/2018/1/5/769
Spectre V1 can be exploited by simply passing parameters to code that runs in another process. It does not require that the attacker can run code in the victim process.
For that, see https://en.m.wikipedia.org/wiki/Gustafson%27s_law.
Exactly this, yes. But for that we need a language that enforces and guarantees pure functions and disallows global state mutation. For now C is king in systems programming but I wonder if certain chips are made with a very different idea from the get go, then can we have a systems functional language?
I also am not very informed on this front, never had enough time to dig deeper. (I did like the idea of the LISP machines several decades ago though.)
MIPS R2000 from 1986 could do simple form of speculative execution.
If the "privileged data" they read was, say, the root password which they used to gain root access and then started snooping around the system as root or modifying parts of the filesystem, that could be easily detected.
If the exploit itself was performed over the network or if the privileged data they read was transferred over the network, that might also be detected, depending on how it was sent and where it was sent to.
If they tried to launch attacks or probes from the exploited system they could be detected at well.
Network intrusion detection systems and host detection intrusion systems could both help here.
From what I've seen, every major high-end CPU architecture is affected, because they all rely on speculation. Of course, some low-end CPUs (such as ARM Cortex-M cores) don't have speculation, so they aren't vulnerable. But on the high-performance front, I haven't seen a credible alternative that wasn't vulnerable to speculative execution side-channels. Which one am I missing?
The Mill makes the current OOO look bad (Intel, AMD, others). It is striking to see that "experts", on this page and the writer of the article, act as if it didn't exist.
The Mill can save Intel, or destroy it, Intel decides that. The pos-x86 nears and time is running out. Intel needs a new architecture and RISC-V is only part of the answer.