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

131–140 of 245 posts

Re: Intel Responds to Security Research Findings

#131

Post by qubex »

gnicholas wrote: post #70
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…

> 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? Another possible interpretation: the early patches will create performance issues, but we'll issue subsequent patches that will make the performance issues less noticeable. Not saying this is…

That's probably a more accurate interpretation, but the wording is maddeningly ambiguous... just the fact that we can sit here and posit such wildly divergent interpretations is testament to how utterly woolly the statement itself is.

Re: Intel Responds to Security Research Findings

#132

Post by jsteemann »

thezilch wrote: post #69
brndnmtthws wrote: post #2

> Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time. Given the lack of any facts, evidence, or details in the press release, how is anyone supposed to take Intel seriously?

Devils advocate. Workload dependence... average user... not significant: A lot of users probably see "30%" and will assume the worst. There really isn't a lot of evidence of how much an average consumer will be affected. Pretty sure your average consumer isn't running pgbench all day. Hell, I'm willing to bargain 90% of servers (I really want to say more) are over-provisioned by 30% or more. Mitigated over time: Kern…

Given the potential slowdowns to be expected by the kernel fixes, I am not expecting a jolly January.

I work for a database vendor.

Re: Intel Responds to Security Research Findings

#133

Post by betterunix2 »

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…

https://lkml.org/lkml/2017/12/27/2

It makes reference to the nature of the bug and explains why AMD's chips are not affected (from an AMD engineer).

Re: Intel Responds to Security Research Findings

#134

Post by makomk »

matt4077 wrote: post #60
AshleysBrain wrote: post #21

> Intel believes these exploits do not have the potential to corrupt, modify or delete data. Reading from kernel memory [edit: from unprivileged apps] is still a severe security issue though, right? This sounds like they're trying to downplay that hard, especially with the "operating as designed" phrase. > Recent reports that these exploits are caused by a “bug” or a “flaw” [Unprivileged] reading from kernel memory i…

> do not have the potential to corrupt, modify or delete data. I believe the point of this sentence was simply to distinguish malicious read access (possible) from any modifying access (impossible). > Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. I believe the second half of the sentence is far more important, i. e. the attempt to broaden the news…

Your typical system has a rather large number of pieces that rely on that protection against read access in order to keep an attacker from obtaining information that would allow malicious corruption, modification, and deletion of data. Intel are being weaselly.

Re: Intel Responds to Security Research Findings

#135

Post by samstave »

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…

Uh... they don’t say the exploits don’t allow for READING of data...

That’s the most concerning thing then

Re: Intel Responds to Security Research Findings

#136

Post by JurgenKlein »

AshleysBrain wrote: post #21

> Intel believes these exploits do not have the potential to corrupt, modify or delete data. Reading from kernel memory [edit: from unprivileged apps] is still a severe security issue though, right? This sounds like they're trying to downplay that hard, especially with the "operating as designed" phrase. > Recent reports that these exploits are caused by a “bug” or a “flaw” [Unprivileged] reading from kernel memory i…

While I agree with most of the analysis, I don’t see any issue with the “operating as designed”. I mean, it is operating as designed. Really, I think they screwed up here. Instead of saying it’s an accident or a mistake, they are saying it’s the result of a careful and deliberate design choice.

That is lawsuit fodder.

Re: Intel Responds to Security Research Findings

#138

Post by martin1975 »

Nition wrote: post #111
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…

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.

Re: Intel Responds to Security Research Findings

#139

Post by IshKebab »

vhold wrote: post #82
myth_buster wrote: post #37

Intel believes these exploits do not have the potential to corrupt, modify or delete data. Followed by... Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. This press release is a minefield. There are whole paragraphs devoted to say nothing.

Somebody please correct me if I'm wrong, but I believe they're basically saying "These exploits do have the potential to read data."

Yes as far as we know it allows user-space code to read kernel memory, but not modify it. It affects Intel but not AMD according to them (not sure why Intel says otherwise).

Details in this blog post from several months ago: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...

They didn't get it to work but obviously someone else has.

Re: Intel Responds to Security Research Findings

#140

Post by IshKebab »

int0x80 wrote: post #121
vhold wrote: post #82

Earlier quoted context omitted.

Somebody please correct me if I'm wrong, but I believe they're basically saying "These exploits do have the potential to read data."

There are not saying it explicitly, which they should.

Yeah, sort of "Don't worry I'm not going to shoot you in the torso, arms or legs."
Post reply on HN