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

41–50 of 245 posts

Re: Intel Responds to Security Research Findings

#41

Post by 2trill2spill »

davesque wrote: post #29
ejcx wrote: post #16

Lots of people being critical of this response. I think it's pretty good, and have been on the disclosing side of this equation many times. Admits responsibility and says their current course of action (working with key stakeholders). Addresses concerns of the workaround. Has a timeframe for future updates. Has a call to action for what you should be doing next. To those of you pointing out that this is PR, you're ri…

I do agree that there are passages in this press release that are totally justified e.g. their calling attention to the fact that other processor vendors have probably been incorporating this flaw into their designs for a while. However, their seemingly innocent mentioning of AMD as being a vendor with which they are coordinating to resolve this issue appears to unfairly (and probably deliberately) implicate AMD in a…

> their calling attention to the fact that many other processor vendors have been incorporating this flaw into their designs for while.

You have a source for this claim? Because besides for Intel's press release I can't find any evidence that other manurfacture's processors are vulnerable to this bug.

Re: Intel Responds to Security Research Findings

#44

Post by justincormack »

2trill2spill wrote: post #22

> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Isn't the quote above which is from the Intel press release a blatant lie? All the articles I have seen say this only affects Intel processors. Not AMD processors nor, ARM, MIPS, SPARC or PowerPC chips. Did I miss something or is Intel lying in it's press release.

There are suggestions it applies to Arm, as there is an arm64 patch for Linux although it hasnt been merged yet I don't think (although the performance hit for the fix might not be as bad).

Re: Intel Responds to Security Research Findings

#45

Post by monocasa »

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

Re: Intel Responds to Security Research Findings

#46

Post by thezilch »

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…

Not defending Intel here, but devils advocate...

You will find many clients asking how to disable, for example, the Linux patch. Linux is releasing with a flag to disable it, so there is some merit. Why would you want that? There are a lot of times you trust everything running on your box and don't need to take the perf hit.

Intel (and possibly other archs/families) found a perf win that ends up having security implications. A perf nonetheless. If you're willing to bet on your userspace not reading kernel pages, does Intel have a feature for you!

Re: Intel Responds to Security Research Findings

#47

Post by mintplant »

mey wrote: post #8
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?

Considering Intel's dominance in the server space, I don't anyone is worried about the average user here

I mean, I am. I have a really nice laptop that I'd rather not have to replace.

Re: Intel Responds to Security Research Findings

#48

Post by blattimwind »

ghrifter wrote: post #39
aneutron wrote: post #34

Earlier quoted context omitted.

> Reading from kernel memory is something of a flaw, no? Fair point about not being Intel specific though. Well the concept is not, but the company who's processors run most of the worlds' databases was PoC'ed, so ....

Source please?

https://twitter.com/brainsmoke/status/948561799875502080

Re: Intel Responds to Security Research Findings

#49

Post by betterunix2 »

thehardsphere wrote: post #38
2trill2spill wrote: post #22

> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Isn't the quote above which is from the Intel press release a blatant lie? All the articles I have seen say this only affects Intel processors. Not AMD processors nor, ARM, MIPS, SPARC or PowerPC chips. Did I miss something or is Intel lying in it's press release.

We won't know until we know what the actual bug is. All we know is that people are writing patches for Intel chips, and what those patches do. It's very possible that other processors are affected by the same issue in some different way that doesn't require this set of patches to mitigate.

We know that AMD is not affected:

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

Re: Intel Responds to Security Research Findings

#50

Post by pas »

qubex wrote: post #24
rpns wrote: 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…

“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…

Process Context ID for TLB entries to make the flipping efficient - if results in constant time failures, will solve the perf issue.

PCID is in Intels since Westmere.

Post reply on HN