Re: Was Intel Aware?
That is, an area marked unusable that actually is still good. Effectively invisible, but still accessible to those parts of the system that are informed about the "good bad spots".
That's how i imagine one could fix this problem, together with another system of pseudo-randomly storing the vulnerable data in pseudo-randomly different spots.
No, that wouldn't help.
This is really quite complicated, but: The issue with Spectre is that while speculative execution discards incorrect results, it has side effects on system state. When spec-ex loads data from memory into cache, that changes the contents of that cache line and the address it's associated with. An unprivileged process can't read those contents - that's essential to virtual memory in a multiprocessing system with process isolation, like every modern general-purpose OS. But an unprivileged process may be able to figure out something about the address the cache line is associated with.
How? With a cache timing attack, for one. Cache timing is one of many side-channel attacks against CPU microarchitectures. Basically, you try to read a particular address and see how long it takes for the load to complete. If it's fast, then you know that address was already cached.
Cache timing leaks information - it lets the attacker find out something about what addresses have recently been cached. That may not seem relevant, but if you're a security engineer, you know that any information leak has the potential to serve as a side channel that reveals some secret information.
For one Spectre variant, you find a piece of code that does an indirect load based on an address you (the attacker) supply. That is:
1. You run the code, supplying address X.
2. The code loads value V1 from X.
3. The code uses V1 to retrieve some value V2 from another location. There's a set of possible V2 addresses, and they depend on V1.
For example, consider a bytecode interpreter which does something like:
result = Functions[*X](...);
that is, it looks at the byte at X, and uses that to index into an array of function pointers.
Now: The attacker wants to know what byte is at some address A, but doesn't have read permission for that virtual address. So he passes A to that block of code. The CPU speculatively executes up through the point of retrieving the function address from the array slot. Then the attacker users cache timing to figure out which function address was loaded. That tells the attacker the value of the byte at A. (The attacker has previously done some setup work.)
That's greatly oversimplified, but it's the basic idea for that form of Spectre.
So having unreadable memory (which we already have), or moving sensitive data around (which we already do), don't help. It's the speculative load and its effect on the cache which matter.