Live data from Hacker News

Intel Responds to Security Research Findings

newsroom.intel.com

71–80 of 245 posts

Re: Intel Responds to Security Research Findings

#71
post #11

Wouldn't it be wonderful if we could buy the latest Xeons at a 30% discount? ;-)

That's why they're the dominant player. Because even when a horrible defect is exposed people still desire the product over the competition.

To be fair, this bug looks like it mostly affects systems that run lots of untrusted code -- e.g. cloud services. If you are only running code you wrote, that does not require many syscalls (compute heavy), in your own data center (or whatever), discounted Xeon chips that suffer from the flaw could be a good deal.

Re: Intel Responds to Security Research Findings

#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 operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.

This is deceptive. It very quickly acknowledge the confidentiality aspect, but then claims that is "operating as designed" and then immediacy try to damage control by pointing out what the exploits cannot do (corrupt/modify/delete).

> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

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.

> Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. 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.

This is deceptive. It immediately mentions AMD to give the impression that AMD also suffer from the problem.

It then goes on with a straw man about performance impacts ("contrary to some reports").

And then mentions "average computer user" whereas the real problem is obviously not average computer users. Again, deceptive.

Re: Intel Responds to Security Research Findings

#74

Earlier quoted context omitted.

The mitigation (KAISER) is being enabled for ARM as well as Intel x86 in the Linux kernel.

> The mitigation (KAISER) is being enabled for ARM as well as Intel x86 in the Linux kernel. Is there a commit you can point to? Or a LKML discussion about this?

https://lwn.net/Articles/740393/

Re: Intel Responds to Security Research Findings

#75
post #65

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

Bigger than KASLR it seems. https://twitter.com/brainsmoke/status/948561799875502080 Not good.

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

Re: Intel Responds to Security Research Findings

#76

Earlier quoted context omitted.

The mitigation (KAISER) is being enabled for ARM as well as Intel x86 in the Linux kernel.

> The mitigation (KAISER) is being enabled for ARM as well as Intel x86 in the Linux kernel. Is there a commit you can point to? Or a LKML discussion about this?

https://news.ycombinator.com/item?id=16058454 mentioned in one of the other threads on this topic

Re: Intel Responds to Security Research Findings

#77
post #64

Earlier quoted context omitted.

We know that AMD is not affected: https://lkml.org/lkml/2017/12/27/2

We know that people think that AMD is not affected by this permutation of the attack. Intel may know differently; I'd withhold sweeping claims.

You think Intel considers AMD vulnerable while AMD considers itself not vulnerable? That's quite an assumption to ask of us.

Re: Intel Responds to Security Research Findings

#78
post #10

It comes across as fairly defensive. Presumably the statement was hastily put together, but it's not really the tone you want to strike when you have a lot of worried customers wondering what is going on. > Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers. A rather bizarre s…

It's odd that they named AMD and ARM, but did not name Apple and Microsoft, isn't it?

Re: Intel Responds to Security Research Findings

#79
post #75
post #65

Earlier quoted context omitted.

Bigger than KASLR it seems. https://twitter.com/brainsmoke/status/948561799875502080 Not good.

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

It looks like he's reading actual data from kernel space.

Re: Intel Responds to Security Research Findings

#80
post #75
post #65

Earlier quoted context omitted.

Bigger than KASLR it seems. https://twitter.com/brainsmoke/status/948561799875502080 Not good.

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.

Post reply on HN