Well, that's true (at least for the spectre attack). It's not a bug in Intel products. It's a bug in any CPU that uses branch prediction (please correct me if I'm wrong, this is my current understanding)
More precisely, there is only a PoC for Intel at this time. AMD processors are believed to not be vulnerable. Some ARM processors _are_ believed to be vulnerable.
> for most CPUs you can attack userspace processes with these techniques
Spectre can attack the kernel as well, at least according to http://www.tomshardware.com/news/meltdown-spectre-exploits-i... . It's just harder to use than meltdown.
AIUI, Spectre can be used to attack the kernel, only if you can get code running in kernel-space, via, e.g. eBPF.
Oh, right, ycombinator's URL parser is broken. I fixed the link to work around the buggy parser....
Spectre variant 2 attacks vulnerable indirect jump code patterns that exist in the kernel (or some other process), but doesn't require running the attacker's code.
Spectre variant 1 allows you to infer the contents of memory in the same address space, so that's the one where you'd use eBPF to attack the kernel.
Meltdown (variant 3) if I understand correctly can infer memory contents of other address spaces without relying on any assumptions about the code running in the other address space.
https://security.googleblog.com/2018/01/more-details-about-m...
It's a bunch of bullshit trying to dance around the fact that Intel shipped faulty products for years. The fact that other similar products may also be faulty isn't a valid excuse.
I am not angry at Intel and in general think they do a good job, but trying to dodge blame here comes off sounding pathetic.
Actually exploiting the information leakage isn't easy; and its compounded by the secrecy surrounding cpu internals. So I think they definitely deserve some blame here. Yes, the PoC is new. But the attack surface was widely known more than a decade ago, and they chose to punt the issue onto software; a solution that was unlikely to really hold water.
From the abstract:
> Information leakage through covert channels and side channels is becoming a serious problem, especially when these are enhanced by modern processor architecture features. We show how processor architecture features such as simultaneous multithreading, control speculation and shared caches can inadvertently accelerate such covert channels or enable new covert channels and side channels.
They were cutting corners; that deserves some opprobrium - especially given their market-dominating position over this timespan.
It would only be correct to say "This is not a bug or a flaw exclusive to Intel products"
A bug would occur in the case where the specification specified that there were no visible side effects from these mispredicted speculative executions, and the processor implementor failed to implement that part of the specification. This is a big deal because if it's a bug, Intel is liable.
It's likely all processors with these kinds of features, the specs will get updated to be more specific about these kinds of side effects.
That's a philosophical stance known as "positivism."
Who do you think wrote the spec here?
The KRACK attack from a couple months ago it's due to the fact the WPA2 specification was ambiguous about what values to accept. Most implementations allowed decrypting traffic and a few even hosts impersonating other hosts but they were perfectly conformant. I would say there is a flaw in the WPA2 specification.
There are always going to be unintended consequences but this one about effects of branch prediction seems, ironically, quite predictable.
It's a huge lapse in customer trust, for sure. But if you're just going to play that semantics game...
I think the good point here is whether or not Intel engineers knew of patterns like this (they should have) and is it negligent or unethical to release products that have these vulnerabilities built in. Insecure (or "undefined") by intention or by coercion.
This is after all what the real execution does; when you try to load from a memory address that you are not allowed to, it does not cause a memory load, it does not affect the cache and it does not continue executing instruction but instead generates a page fault. We skip the page fault thing in speculative execution, obviously, but we shouldn't continue normal control flow.
I'm sure that is a lot more difficult to implement in silicon and may end up negating the performance benefits of speculative execution, but right now it feels like not having the memory protection in place in speculative execution is a performance hack that exploded in all our faces.
(The exploit involves reading an off-limits location in the speculative branch, then reading a legal location based on the off-limits value; so unless the entire cache was flushed the attack would still be possible.)
Even if speculative loads do not modify the cache, you could still have a side channel by analyzing the memory bus contention.
IMO there is no way to get rid of these timing attacks entirely without getting rid of SMT and speculation.
This would allow keeping the performance of speculative execution in the vast majority of cases, while also fixing the kind of potentially leaking double-indirections that Spectre variant 1 can exploit.
Spectre variant 2 needs to be fixed by isolation of the branch prediction structures, i.e. tagging the BTB and others with the PCID and privilege level.
That's sadly not enough.
There are also potential speculation-based side-channels that are unrelated to cache: timing the idiv operation whose latency "depends on number of significant bits in absolute value of dividend." Furthermore there are many ways to measure contention on the execution ports which can leak information about the speculative execution.
You mention idiv, which is an interesting example. Is it actually observable? Without hyper-threading, almost certainly not, because the execution unit reservations should be dropped as soon as the speculated branch is resolved. With hyper-threading? Perhaps, but it shouldn't be too hard to fix if a non-speculated thread always takes precedence over a speculated one, which makes sense anyway.
In both cases there may be leaks in practice, but those should be fixable relatively easily in hardware, and we've already established that hardware fixes are required anyway.
Another case to think about are dependent conditional branches, since those could affect the instruction cache.
It does seem like a good idea to have a strict barrier instruction against speculative execution just to have a fallback mitigation.
Because eviction is a side-channel too.