Live data from Hacker News

Intel Responds to Security Research Findings

newsroom.intel.com

141–150 of 245 posts

Re: Intel Responds to Security Research Findings

#141

Do we know the actual bug yet? I sort of assumed it was a timing attack on KASLR rather than a leak of traditional kernel data. Although I guess that there would have been cheaper mitigations like mapping an empty page to all of the other KASLR slots rather than doing a full world switch in that case...

It's true nobody knows what the actual bug is, but I was working with what Ars Technica described: "If the problem were just that it enabled the derandomization of ASLR, this probably wouldn't be a huge disaster... The industry reaction... suggests that it's not just ASLR that's defeated and that a more general ability to leak information from the kernel has been developed." https://arstechnica.com/gadgets/2018/01/wh…

I guess I've stopped reading security articles by Peter Bright ever since he spent a whole series of articles shitting on project zero for disclosing vulnerabilities after the 90 day disclosure window when Microsoft had just been sitting on the bug.

https://arstechnica.com/information-technology/2015/01/googl...

Re: Intel Responds to Security Research Findings

#142
post #128

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

I would not be surprised at all, considering the patch I saw for the AMD processors was literally a one-line if statement around the set cpu insecure flag that added a check for AMD processors.

Google is failing me or I'd post a link.

Re: Intel Responds to Security Research Findings

#143

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…

In the case of asymmetric competition, a company with vastly more resources might curate a list of undisclosed problems with competitors' products, for when a major event like this strikes, they can drag along the underdogs. The optics are different if 1) the dominant player can pretend it's "working together" with the other vendors, 2) the dominant player condescendingly points out mildly related issues in competitors' product, and 3) the name of the alternatives keeps getting linked in a "we're in the same boat" way.

I'm not suggesting this is the case here at all, as it's unlikely that Intel identified this precise issue with AMD long ago and haven't checked their own vulnerability (though there's always a chance that an issue is found by company A when analyzing the strengths and weaknesses of company B's products, which then turns out to apply for their own products too). But I wouldn't be surprised if somehow there were some loosely related AMD issues that came to light now, and it's impossible to tell if those would be current finds or older ones.

Given Intel's dominant position, they may come out ahead in P&L or gross margin terms even if it turns out to be a clearly Intel issue, as the perceived or real loss of performance may trigger an upgrade spree, sold unit counts inevitably dominated by Intel purchases.

AMD has just started to catch up in overall performance, and in the worst case bug impact to Intel, they may even get competitive single-threaded performance. Also, there has been speculation that Apple has been evaluating ARM processors for some future laptops, and a sudden drop of the baseline is an interesting turn of events.

While this in theory benefits the underdogs, financially Intel may well come out ahead due to their market hegemony.

Re: Intel Responds to Security Research Findings

#144
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 might mean this one:

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

Re: Intel Responds to Security Research Findings

#145
post #75

Earlier quoted context omitted.

That's a tweet of someone using the bug to defeat KASLR.

I'm fairly sure he's actually reading from the syscall table. He already defeated KASLR when he typed /proc/kallsyms. That aside, I don't think KASLR would be important enough to rush KPTI like it has happened now and to even enable it by default, given its drawbacks.

Sorry, I'm being imprecise. Yes, they're reading from kernel memory. But the specific thing they're reading is useful as a KASLR bypass.

I think I understand that the subtext of this thread is: can you only bypass KASLR with it, or can you read pretty much anything from kernel memory? And yeah: it sure seems like you can work out arbitrary kernel values; it's hard to think of a way this bug could work where you can figure out the symbols of specific kernel functions, but not arbitrary values in the kernel.

Re: Intel Responds to Security Research Findings

#146
post #105
post #88

Earlier quoted context omitted.

But the story seems to only have broken to "mainstream" yesterday and has gained a lot of attention in the last 24 hours.

Sure. Catching mainstream media off guard is different from Intel though. There is no way this caught them by surprise. If anything it reads like it was very carefully crafted by lawyers to make sure they don't get sued to hell for a defective product. (It's not but lawyers are gonna lawyer)

They may not have realized it would make it to the media; until this week there was not much chatter, and then today Intel's stock is trading lower while every other chipmaker is trading higher. Their PR team may not have been prepared for that situation, and they may be worrying about CTOs giving more serious thought to AMD (or even non-x86 chips) for their data center upgrades.

Re: Intel Responds to Security Research Findings

#147

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…

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

I was making reference to this [1].

The original fix had a comment that literally said, "/* Assume for now that ALL x86 CPUs are insecure */" They've since added a check to exclude AMD processors.

[1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...

Re: Intel Responds to Security Research Findings

#148

What a scummy, dishonest response. - Saying it's not a 'bug' or 'flaw' = lie. - Cold naming AMD and ARM in the post, I'm certain not just to throw their names in the ring but also for SEO ranking and relationships. - Failing to address the root cause, how it came to be and provide other technical references. And let's not forget - Intel's CEO sold his stock. -- * Note: "AMD chips are affected by some but not all of t…

[deleted]

Re: Intel Responds to Security Research Findings

#149

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 known at the time they were designed.

(I don't have any information that could confirm/deny this, it's just how I interpret their verbiage).

I don't get the sense that they are trying to deceptively contradict only part of the previous statement.

Re: Intel Responds to Security Research Findings

#150

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…

You might mean this one: https://lkml.org/lkml/2017/12//27/2

Yeah.

I just found it in their git repo, looks like it was added today. https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...

Post reply on HN