Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Responds to Security Research Findings

newsroom.intel.com

Post reply on HN
Print view View original

221–230 of 245 posts

Re: Intel Responds to Security Research Findings

#221

Post by mehrdadn »

tedivm wrote: post #218
mehrdadn wrote: post #216

Earlier quoted context omitted.

> When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed. Well (and the irony is not lost on me here), this wasn't part of the definition of a semantic dispute that you just presumably quoted... it was just something you tacked onto it afterward. And the entire problem is that to you a semantic dispute might imply the original issue is being obfuscated, whereas to th…

> ...you cannot seriously expect this to be a convincing argument without offering your own kosher definition (read: semantics) of "bug". It's kind of hilarious that the only reason you can claim this is because of your selective editing. The whole statement you are responding too is this- > In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors…

Shoot, apologies for that, this was a silly reading error on my part... I quickly read that comment while outside and didn't realize 'redcalx' was referring to the user above, and instead somehow my brain just glossed over that part as a typo.

Disregard that part of my comment and look at all the rest of what I've actually been saying. The problem I have been trying to point out with the definition (as in the last comment, but I'll repeat here) is that the definition of a "bug" might be "just semantics" to you, but that doesn't make it irrelevant; those semantics make all the practical differences here. If you consider any undesirable behavior in unintended situations to be a "bug", then it sure sounds good, but won't get you anywhere, given that practically anything you buy can be used in weird ways with unforeseen (and hence unintended) consequences. If you consider a "bug" to be a deviation from the manufacturer's specified behavior, then it's obviously more limiting, but I would expect it's closer to the semantics a court would use to decide whether to hold the manufacturer responsible.

Re: Intel Responds to Security Research Findings

#222

Post by strmpnk »

gshulegaard wrote: post #182
bjornedstrom wrote: post #73

This is probably one of the poorest and most defensive PR pieces I've read from a company in a long time, and it does not really make me sympathetic to them at all. > Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operat…

> This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point. This is excellent analysis. I guess my follow up question is has there been anything to suggest that AMD/ARM are or are not vulnerable in a similar manner? I…

The patch that was under question was related to a workaround for Meltdown, which makes AMD's note regarding the lack of necessity in agreement with the paper.

The Spectre paper seems to be a bit less specific on how platforms might differ under explotation but very clearly states that it was verified to be possible. Workarounds for that problem will likely be much more application specific from what I can tell, but I have only skimmed that paper so far.

Re: Intel Responds to Security Research Findings

#223

Post by foxylad »

haberman wrote: post #149
bjornedstrom wrote: post #73

This is probably one of the poorest and most defensive PR pieces I've read from a company in a long time, and it does not really make me sympathetic to them at all. > Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operat…

I could be wrong, but I take the "bug/flaw" language to mean this: the processor is doing exactly what it was designed to do (unlike the Pentium FDIV bug, for example). A new class of exploit was recently discovered, and these CPUs are vulnerable to this new exploit. But there was no bug in how these CPUs were implemented, and the only design flaw is that they failed to withstand a new class of exploit that was not k…

My limited understanding is that the vulnerability is due to kernel memory protections not being applied during speculative execution, when the CPU is trying to second guess what the next instructions might be.

Unless you are in PR, any reasonable person would expect a CPU touted as having kernel memory protection to protect it under all circumstances. I'm sure that the people who wrote the speculative execution code would have included that protection had they thought of it, and all developers would class it's omission as a bug. So yes, this is yet another example of awful PR, trying to cover up a serious mistake with careful language that makes it seem not their fault.

My policy when I make a mistake is immediate disclosure, along with two commitments: to put the mistake right, and to amend processes to prevent similar mistakes in the future. It isn't clear how Intel can put this right, but perhaps a good discount on replacement parts might help. And they can certainly implement processes to catch such omissions in the future.

So this press release (particularly combined with reports of execs selling stock) are appalling. Intel have badly damaged their brand, and I'll never buy another Intel processor again.

Re: Intel Responds to Security Research Findings

#224

Post by strmpnk »

strmpnk wrote: post #222
gshulegaard wrote: post #182

Earlier quoted context omitted.

> This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point. This is excellent analysis. I guess my follow up question is has there been anything to suggest that AMD/ARM are or are not vulnerable in a similar manner? I…

The patch that was under question was related to a workaround for Meltdown, which makes AMD's note regarding the lack of necessity in agreement with the paper. The Spectre paper seems to be a bit less specific on how platforms might differ under explotation but very clearly states that it was verified to be possible. Workarounds for that problem will likely be much more application specific from what I can tell, but…

Update: AMD has an official statement with a clear outline of the discussed vulnerabilities: https://www.amd.com/en/corporate/speculative-execution

Re: Intel Responds to Security Research Findings

#225

Post by smaddox »

BuildTheRobots wrote: post #211
arghwhat wrote: post #187

Earlier quoted context omitted.

From what I can gather, one of the 3 issues found is Intel-only, very bad and very easy to exploit, and can be patched with a large performance hit. Another is harder to exploit, and has no known workaround (likely requiring new silicon to fix), and affects basically all micro-architectures in use today, including AMD's x86 silicon. The third, I know nothing of.

Ah, it must be serious, there's now a branded website [1] for it ;) I believe the Intel only issue is called "Meltdown" and the second is called "Spectre"; the attack website [1] has details of both. [1] https://meltdownattack.com/

Reading the Meltdown paper [1], it's not clear why I keep seeing people say it's Intel only. The paper says quite clearly that other vendors' processors could be affected:

"Instead, Meltdown exploits side-channel information available on most modern processors, e.g., modern Intel microarchitectures since 2010 and potentially on other CPUs of other vendors."

[1] https://meltdownattack.com/meltdown.pdf

Re: Intel Responds to Security Research Findings

#226

Post by foobarian »

martin1975 wrote: post #138
Nition wrote: post #111

Earlier quoted context omitted.

Yeah, I had to read the “bug” or “flaw” part twice to be sure they're not saying it isn't a bug or flaw, they're only saying it isn't unique to Intel. And then as you say, they immediately mention AMD to imply that everyone has the issue, but they also avoid actually saying that. Your excellent analysis of what they're really saying reminds me of user thaumaturgy's analysis of Adancing Our Amazing Bet[1]. [1] https:/…

Bet you a dollar some lawyer had to vet that three times over before they published it.

Bet you another dollar it was more than one lawyer.

Re: Intel Responds to Security Research Findings

#229

Post by pksadiq »

smaddox wrote: post #225
BuildTheRobots wrote: post #211

Earlier quoted context omitted.

Ah, it must be serious, there's now a branded website [1] for it ;) I believe the Intel only issue is called "Meltdown" and the second is called "Spectre"; the attack website [1] has details of both. [1] https://meltdownattack.com/

Reading the Meltdown paper [1], it's not clear why I keep seeing people say it's Intel only. The paper says quite clearly that other vendors' processors could be affected: "Instead, Meltdown exploits side-channel information available on most modern processors, e.g., modern Intel microarchitectures since 2010 and potentially on other CPUs of other vendors." [1] https://meltdownattack.com/meltdown.pdf

> "Instead, Meltdown exploits side-channel information available on most modern processors, e.g., modern Intel microarchitectures since 2010 and potentially on other CPUs of other vendors."

But their website faq says[0]: every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). .... Currently, we have only verified Meltdown on Intel processors....

[0] https://meltdownattack.com/#faq-systems-meltdown

Re: Intel Responds to Security Research Findings

#230

Post by gshulegaard »

strmpnk wrote: post #222
gshulegaard wrote: post #182

Earlier quoted context omitted.

> This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point. This is excellent analysis. I guess my follow up question is has there been anything to suggest that AMD/ARM are or are not vulnerable in a similar manner? I…

The patch that was under question was related to a workaround for Meltdown, which makes AMD's note regarding the lack of necessity in agreement with the paper. The Spectre paper seems to be a bit less specific on how platforms might differ under explotation but very clearly states that it was verified to be possible. Workarounds for that problem will likely be much more application specific from what I can tell, but…

Finally clarified this on my own and came back here to update a final time...but yeah this is the right answer.
Post reply on HN