(Edit: It seems this analogy may be overly kind to Intel. Read all the replies to this comment for more information.)

This is not really like that. The dangers of speculative execution were known before, and, separately, the processor itself provided memory isolation capabilities. That the processor would ignore its own memory isolation principles when speculating about the next instruction to execute is a critical base of these vulnerabilities.

Now Intel has his own Grenfel tower.

Probably best to just defenstrate this analogy.

Goodness you just described my current work situation that's causing me to rip my hair out. This is a deeply human problem, and I've spent a year trying to mitigate it, but each time the discussion comes up I leave the conference room feeling like certain actors have a personal financial stake in wool fibers.

(No I don't work for Intel)

Edit: Elsewhere I found a link to ARMs page where they breakdown exactly which of their processors are vulnerable to both Metldown and Spectre and it looks like quite a few of them are vulnerable to one or both of them.

In Intel's case, even though the operation is correct, it's the actual design that's flawed.

"Well, that's an interesting hack, I guess you can! But everything works as designed, so there's no flaw!"

Could be not worth making a public stink, could be weaponizing the exploit, could be coordinated disclosure.

/s

[Urban legend, afaik, cats can't right themselves with less than the seventh floor height to fall..]

The problem is they land with legs extended down from floors 1 to about 7 (bad: impact is transmitted up through shoulders and hips), while higher than about floor 7 they spread their legs out and attempt to parachute (better: impact is uniform over entire ventral surface, terminal velocity is lower, mortality rate drops).

Source: am DVM and interned at AMC in Manhattan.

Mortality rates.. Got it ,:-$ so, marketing for 7th floor Homes with kitty life policy in the service charge bill technically not the Blatant fraud I assumed, and if the building manager had run into trouble the lives of many injured kitties luckily lookalike to the residents could be the hardest sentencing hearing for any animal lover judge. English cities badly need dog license reintroduction. Asked to help a former neighbor become tramp beg court to return his dog. Second I met the man, who certainly was denied due process and on paper atrociously mistreated, he introduced the dog, unknown potential dominant bulldog mongrel, getting it to l so and lock it's jaw on his agitated arm. I passed him again, alone in rain, dog coat sodden, he was high and drunk careless no train still disgorge the fool he requires. Dogs need sorting out in London before brexit chaos

http://www.nytimes.com/1989/08/22/science/on-landing-like-a-...

[1]: https://www.youtube.com/watch?v=RtWbpyjJqrU

I mean in cities I keep imagining much greater extent of elevation, moment we figure how. Above the smog line... I'm sure I was in 94 but 16 same place, in the middle, ugh.

Could it become unlawful to rent (Live in generally) homes without harmful particle filtration?

I'm thinking of renting out my filters just before tenant viewings, because this eliminates the obviously fresh air chill, takes out fat or any food Smell beyond the kitchen, let's a visitor smoke even..(friend closed rental dear by offering a cigarette excused by filters, it's your residence now) but from flu season to the decoration next door, the cost needs a artificial boost. Wish was a swapHN channel..

http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect...

Sounds like a bug to me. The PR team must have had fun trying to find a way to downplay this one...

One way to interpret the statement is that the chip design which they utilized is widely available and understood by everyone in the chip community to be good chip design, thus we aren't at fault, because everyone is doing it.

To reiterate those types of arguments are a very serious logical fallacy and unsound argument called appealing to common practice.

They should fire their PR team.

Far from being at risk of being fired their whole PR department is probably swelled by ranks of excruciatingly expensive corporate emergency consultants and experts paid precisely to output this kind of menial drivel.

How were they supposed to avoid an exploit that no one would discover for years? And exactly how is "appeal to common practice" a fallacious or unsound argument?

Exactly how much performance -- meaning, how much market share -- is Intel supposed to sacrifice to avoid the possibility of introducing unforeseen bugs?

Also, appealing to common practice doesn't make logical sense.

Here: https://en.wikipedia.org/wiki/Appeal_to_tradition

It is hazardous to apply logical arguments blindly in illogical contexts, such as competitive markets.

Again: mitigating all possible bugs isn't free. Exactly how much effort and expense is worthwhile, and how do you know beforehand?

A malicious process allocates a 256 member array. Then it creates a conditional where the speculatively executed part writes a byte at offset array + kernel_memory_value. The speculative branch is executed but then backed out, but the byte in the array was touched so it is in cache now. Then the malicious process reads all of the members of the array and looks for one that returns much faster than expected (is in cache) and they know the value of that byte. Rinse and repeat to read the rest of the kernel memory. It's not going to give you MB/s of throughput, but it's plenty fast to read some key material or process tables or anything like that.

It's a very impressive attack. My hat is off to whomever thought it up.

Or maybe the idea is speculative execution itself was a dream of the NSA that was Inception-planted into the brains of CPU designers in the 90s; who knows what the theory-of-the-hour is regarding 3-letter-agencies and their capabilities.

Ultimately I think what we're really learning is that guarding against things like microarchitectural attacks on contemporary superscalar, OoO CPUs is going to be an uphill battle that we didn't ever think of due to incidental complexity (among other reasons), and will serve as a new class of attacks. Who knows how long this bug class will exist; we've killed some. What's also likely is that, like most security failures in the industry, this is a result of various things like basic lack of forethought/ill considered design, as opposed to plants (3 letter agencies aren't responsible for the vast majority of security failures you see, it's simple mistakes). But peddling conspiracy theories involving them gets you upvotes, so, you know...

The crux is:

array[value_of_kernel_memory_byte] = 1;

So it speculatively indexes into the array by the value stored at that memory address and writes the byte. Then to figure out what the value is you just have to see which element in the array is cached.

array[value_of_kernel_memory_byte] = 1;

This assignment gets rolled back like it's supposed to. It's when reading the array after the rollback that the exploit measures that a read to array[value_of_kernel_memory_byte] is faster than the rest because that index is already in the cache.

Is it a valid legal defence to say, that was just marketing lies so don't take it seriously?

There actually is a recognized defense to fraud claims along those lines. The concept is called "puffery": https://definitions.uslegal.com/p/puffery/

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.

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...

Oh, right, ycombinator's URL parser is broken. I fixed the link to work around the buggy parser....

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.

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.

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.

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.

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.

That's a philosophical stance known as "positivism."

Who do you think wrote the spec here?

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.

With each day passing this looks more and more like the Diesel scandal. Is it OK if all big players do it?

So people can leverage the poopy design of your chip to steal compromising information? And it's okay because the chip is functioning as it should?

It shows how deeply embedded the idea of maintaining proper design and processes is over, going back to the drawing board and designing a secure chip.

Literally, prioritize proper design over security and maybe even performance in some cases. Which is interesting because you'd figure at some point, the customer would be considered in the design.

Like are Intel chips designed by robots or something?

That's how Master Lock stays in business.

Our service works just ask expected without any flaws. Our ushers check for proper tickets after the presentation has finished, that way we know who should and should not have access to the theatre.

But shouldn't you check before hand?

Again our service works ...

So people made workarounds for those two workarounds: software patches.

Maybe even more other people will find (or make?) workarounds for those software patches?

Will we witness an semi-endless cycle of workarounds until the current design specifications are slowly becoming worthless?

Or will we suddenly witness new updated (patched?) design specifications (with some extra free features we never knew we wanted) and all buy new hardware?

So Intel has learned nothing and will be prone to similar mistakes in the future.

And btw, did you notice that huge amount of people disagrees already with you, simply putting your stock 8% down in two days?