From what I understand of this set of bugs, is that code executed by the branch prediction logic can access privileged memory that it normally wouldn't have access to. And that the CPU can't generate a protection fault, because it isn't known at that time if the code really would have tried to access that memory.
So would it be possible (through a microcode update) to mask the memory values, so that ANY read from privileged gets a NULL value returned?
Or could that cause issues, due to the fact that a branch that doesn't currently have access to a memory segment, may be granted legitimate access to it by the time it would normally be executed?
The bug where speculatively-executed code can access privileged memory is Meltdown, and it doesn't affect AMD systems since apparently they did the sensible thing and blocked even speculative access to unauthorised memory addresses. Unfortunately, Meltdown apparently can't be fixed in microcode on affected Intel CPUs, so they're stuck with a performance-killing workaround that AMD CPUs don't need.
I don't see where the contrary is stated; in a nutshell their architecture is not sensible and deeply flawed in regard to security, if they can't check that without throwing all the perf out the window.
No, my point was, AMD performance in this situation may simply be worse because they didn't have time to implement this efficiency. Not because AMD was somehow prescient about the security issue.
A fence of some kind that stops the speculation on access to protected address space would be better. Trying to stub out values would mean you have to throw the speculation out anyway, and a fence could be setup to prevent access. This might still allow an attack on kaslr since you could use the timing of the speculation to determine if a fence got hit or not.
It it's just one of timing attacks possible on x86. Cache miss timing has been used in the past to create covert channels and exfiltrate keys. Memory controller issues have been explored too. Modern general purpose CPUs sacrificed some security for performance.
There are few security or performance guarantees. It is not an architecture geared to realtime and fully deterministic operation.
> Modern general purpose CPUs sacrificed some security for performance.
I don't think that's a fair way of stating it. I think it's a case of independent performance improvements in branch prediction, cache architecture and out-of-order instruction retirement that on their own have negligible security impact but when combined in a single system reveal emergent behavior.
Privileged memory access only happens in meltdown, spectre is much more difficult to prevent (seems impossible short of killing speculation altogether) but can only access arbitrarily in its own address space.
Spectre is simple to prevent: just don't modify the cache while speculating and the CPU can still do all the same branch prediction and speculative execution pipelines that exist today.
It doesn't even have to be that drastic, the CPU can still fetch any memory that's not calculated. Both sides of a non-computed jump for instance, or the next line of an array that's being scanned in order.
Some memory references would be sequential instead of overlapped, but it wouldn't be the end of the world.
What I'm saying is that speculative execution without modifying the cache is safe from a Spectre reading arbitrary memory, the main concern.
So start from there. That's not a terrible starting position, with all of today's predictive logic and speculative pipelines working at full speed on the fastest codes and partially working as codes use more uncached memory accesses.
Then you add back in things like speculatively prefetching code and global variables (addresses hardcoded in the instruction not calculated) and you're nearly back to 2017 performance. The problem is widespread and severe, but we're not going back to some dark ages of computing.
So would it be possible (through a microcode update) to mask the memory values, so that ANY read from privileged gets a NULL value returned?
Or could that cause issues, due to the fact that a branch that doesn't currently have access to a memory segment, may be granted legitimate access to it by the time it would normally be executed?