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

201–210 of 245 posts

Re: Intel Responds to Security Research Findings

#201

Post by rbanffy »

AsyncAwait wrote: post #170
rbanffy wrote: post #114

Earlier quoted context omitted.

People who need to get absolutely the most bang for the buck have no ties to any given supplier. Cray deployed one of the first Opteron-based supercomputers. Intel got lots of datacenter business simply by having a better (as in "better suited to our demands") product than anyone else in the segment. AMD has a short time window to make some large sales. They have until Intel ships a microcode fix or a new line of pro…

> They have until Intel ships a microcode fix Sounds like microcode fix isn't possible.

Then the next generation it is.

It's a 5-30% performance boost without even a major change. :-(

Re: Intel Responds to Security Research Findings

#202

Post by zde »

redcalx wrote: post #186
haberman wrote: post #177

Earlier quoted context omitted.

Yeah I agree there is a line there somewhere. If someone sells you a safe and it can be opened with a ballpoint pen, that seems like a flaw. If someone sells you a safe and it can be opened with a military grade laser, that's sort of expected. If someone sells you a safe and it can be opened with a cheap consumer gadget, but that gadget is complex and was unforeseen when the safe was designed, what do you say about t…

> I guess overall I think this is fair to call a "flaw" but not a "bug." Yes I agree, it's not a bug in the sense of a silly mistake that slipped through development and testing. It's a flaw / attack-vector that no-one thought of... until now.

Reminds me of dieselgate. "Our product is ok unless operated out of spec" didn't work, iirc.

Re: Intel Responds to Security Research Findings

#203

Post by nebulous1 »

mehrdadn wrote: post #197
nebulous1 wrote: post #185

Earlier quoted context omitted.

Wait, what? If this allows code running in ring 3 to read from ring 0 protected memory then it's not an issue due to a lack timing guarantees, even if its internally caused by a timing issue. Now the speculation about the underlying problem could be way off, but if not it would be hard to see how Intel would argue that it isn't a bug.

> If this allows code running in ring 3 to read from ring 0 protected memory then it's not an issue due to a lack timing guarantees, even if its internally caused by a timing issue. I was never saying "the lack of timing guarantees was [or wasn't, for that matter] an issue" in itself. I said "given the lack of timing guarantees, this behavior is perfectly correct and compliant with their specs [as far as I know]". Yo…

So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3, thereby rendering the concept of memory read protection useless by design?

Re: Intel Responds to Security Research Findings

#204

Post by angelsl »

mywittyname wrote: post #123
qubex wrote: post #24

Earlier quoted context omitted.

“Workload dependent” clearly implies (despite the spin they are trying to put on it) that some users will be worse off than others. What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch? Quoting ARM and AMD is really a bit pathetic too, IMHO, especi…

> Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw. The official fix for this in the Linux kernel has a comment that literally says to assume all x86 processors suffer from the same issue and will disable KPTI for all x86 processors, including AMD. There's an AMD-specific patch that I saw floating around that keeps the setting enabled for AMD pro…

You mean enable KPTI.

Re: Intel Responds to Security Research Findings

#205

Post by mehrdadn »

redcalx wrote: post #164
haberman wrote: post #149

Earlier quoted context omitted.

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…

It's kind of semantics though isn't it? If I write a piece of software that follows the spec and fulfils the customer's need, but then someone tries to do something with it that we hadn't thought of and that results in a security hole... around here we call that a bug, a flaw, something we missed. Maybe it's reasonable to have not spotted the bug, but that wouldn't make it not a bug/flaw.

> It's kind of semantics though isn't it?

I never understood how this sentence became a defense. Yes, yes it is. It is semantics. Everything is semantics. The difference between getting fired and getting laid off is semantics, and everybody cares about it and recognizes it. The difference between "I'll pick you up at 5pm" and "I promise I will pick you up at 5pm even if my car breaks down and the train gets derailed" is semantics. Calling something "semantics" isn't a defense to your argument; it's often more like a concession. (And the difference between a defense and a concession is, as I'm sure you realize, also semantics...)

Re: Intel Responds to Security Research Findings

#206

Post by Strudelnoggin »

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.

That same lawyer no doubt had to tell them that the following statement wouldn't fly without the addition of the word "believes":

"Intel believes its products are the most secure in the world [ . . . ]"

Re: Intel Responds to Security Research Findings

#207

Post by mehrdadn »

nebulous1 wrote: post #203
mehrdadn wrote: post #197

Earlier quoted context omitted.

> If this allows code running in ring 3 to read from ring 0 protected memory then it's not an issue due to a lack timing guarantees, even if its internally caused by a timing issue. I was never saying "the lack of timing guarantees was [or wasn't, for that matter] an issue" in itself. I said "given the lack of timing guarantees, this behavior is perfectly correct and compliant with their specs [as far as I know]". Yo…

So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3, thereby rendering the concept of memory read protection useless by design?

> So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3.

Assuming by "read" you mean "inferred", yes, I'm not aware of any such guarantee, but again, I of course have't read everything they have published, so by all means prove me wrong.

Re: Intel Responds to Security Research Findings

#209

Post by mannykannot »

mannykannot wrote: post #26

Interesting use of language: 'Recent reports that these exploits... are unique to Intel products are incorrect... Intel is committed to product and customer security and is working closely with many other technology companies, including AMD...' Someone new to the issue might think AMD also has this problem. Similarly (replacing the first elision in the above quote): 'Recent reports that these exploits are caused by a…

Correction: it seems that AMD processors are also vulnerable to one variant of this type of attack, which either mitigates or refutes my first complaint. AMD is crying foul, claiming that Intel is creating a bogus equivalence, as the risks are not comparable, but it is itself using awkward phrasing: "AMD is not susceptible to all three variants" rather than the more straightforward "AMD is susceptible to only N of the three variants."

Re: Intel Responds to Security Research Findings

#210

Post by omeid2 »

qubex wrote: post #128
mywittyname wrote: post #123

Earlier quoted context omitted.

> Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw. The official fix for this in the Linux kernel has a comment that literally says to assume all x86 processors suffer from the same issue and will disable KPTI for all x86 processors, including AMD. There's an AMD-specific patch that I saw floating around that keeps the setting enabled for AMD pro…

I don't know if it's possible to see who contributed that patch (yet), but I’m cynical enough to half-expect that the “assume all x86 processors are insecure” patch might come from an Intel engineer...

the patch was by Thomas Gleixner[0], who is not an Intel Engineer.

AMD has since pushed a patch to "not enable PTI on AMD processors" [1]

[0] https://patchwork.kernel.org/patch/10138833/

[1] https://patchwork.kernel.org/patch/10142563/

Post reply on HN