Intel Issues Updates to Protect Systems from Security Exploits

Re:Intel Issues Updates to Protect Systems from Security Exp... by dekhn on Thursday January 04, 2018 @01:31PM (#16072750)

My interpretation is that they not calling this a bug or a flaw, but a logical consequence of the design, and does not represent a flaw because the original specification didn't specify the implementation be resistant to this kind of attack.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by dmannorreys on Thursday January 04, 2018 @01:45PM (#16072891)

A bug is a bug regardless of what the original specification mentioned.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by dekhn on Thursday January 04, 2018 @02:06PM (#16073084)

I don't agree. If a spec leaves out details, the impelmentors are free to make reasonable decisions on how to implement it. It's more likely the spec didn't really have much to say about promises on the visible effects of speculative execution (the specs are often highly detailed about what side effects can be visible, this is a consequence of modern complex processors, which have very subtle designs).

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.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by rnhmjoj on Thursday January 04, 2018 @06:32PM (#16075113)

I think the specification has a problem if a conformant implementation has a problem, particularly if it's a security one. There should be as little as possible left free to the implementors.

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.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by dekhn on Thursday January 04, 2018 @06:45PM (#16075186)

Every design is a tradeoff and spec authors don't want implementators to have their hands tied fixing every last problem.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by dmannorreys on Thursday January 04, 2018 @02:18PM (#16073190)

Are you saying a bug cannot exist unless some functionality is specifically mentioned in the specification, and broken in reality?

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by dekhn on Thursday January 04, 2018 @03:15PM (#16073665)

From the perspective of Intel, as well as most of the microprocessor industry, yeah. Even "broken in reality" is arguable: while this is indeed an exploit, choosing performance over security (when the resources to implement a chip are finite) is a legitimate design tradeoff.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by stcredzero on Friday January 05, 2018 @01:50PM (#16080637)

Are you saying a bug cannot exist unless some functionality is specifically mentioned in the specification, and broken in reality?

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

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by jsjohnst on Thursday January 04, 2018 @02:55PM (#16073477)

> If a spec leaves out details

Who do you think wrote the spec here?

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by dekhn on Thursday January 04, 2018 @03:03PM (#16073555)

system architects at intel, obviously.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by jsjohnst on Thursday January 04, 2018 @03:40PM (#16073877)

Ok, so your saying Intel wrote a poor spec and implemented to that spec, so no fault of theirs because “we implemented to the spec”?

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by dekhn on Thursday January 04, 2018 @06:44PM (#16075180)

I didn't say it was no fault of theirs. But it does really matter, to Intel, and their (large-scale) customers in terms of liability.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by erikj on Thursday January 04, 2018 @03:48PM (#16073931)

So Intel is still liable then.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by ionforce on Thursday January 04, 2018 @04:00PM (#16074027)

Right, so the mismatch here is whether or not the CPU is being pitched as wholly secure. If it is "mostly secure with insecure performance enhancements" or really "mostly secure with performance enhancements that have an unspecified level of security", then... It's "not a bug".

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.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by wtetzner on Thursday January 04, 2018 @01:59PM (#16073018)

So it's a bug in the specification.

[ Parent | on HN ]

Re:Intel Issues Updates to Protect Systems from Security Exp... by laythea on Thursday January 04, 2018 @01:54PM (#16072969)

so it is a flaw in the spec then.

[ Parent | on HN ]