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

21–30 of 245 posts

Re: Intel Responds to Security Research Findings

#21

Post by AshleysBrain »

> 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 is something of a flaw, no? Fair point about not being Intel specific though.

> any performance impacts are workload-dependent, and, for the average computer user, should not be significant

Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"...

> However, Intel is making this statement today because of the current inaccurate media reports.

This and similar sentences has a strange tone to me, it sounds almost grumpy. I guess it got rushed out.

Re: Intel Responds to Security Research Findings

#22

Post by 2trill2spill »

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

Re: Intel Responds to Security Research Findings

#24

Post by qubex »

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, especially if it turns out that AMD chips are immune to the flaw.

Re: Intel Responds to Security Research Findings

#25

Post by aceofspad4s »

bkeroack wrote: post #14
rbanffy wrote: 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.

They would have to screw up really bad for people to go to AMD. I think that may never happen.

Re: Intel Responds to Security Research Findings

#26

Post by mannykannot »

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 “bug” or a “flaw”... are incorrect.'

So, working just the way you want it to, eh, Intel? But then, why would you describe them as exploits?

Re: Intel Responds to Security Research Findings

#27

Post by tgarma1234 »

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…

Because let's be honest: when I bought my XEON and i5 processors, performance wasn't the issue that made me pick Intel over AMD. PUH-LEASE. This is the worst kind of customer service malarky I have read in a while.

We are not average computer users.

Re: Intel Responds to Security Research Findings

#29

Post by davesque »

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 all of this. I feel this was an attempt to divert attention to their competitor even though their competitor's products don't suffer from this problem. I'm guessing their marketing department gave this a once over.

Re: Intel Responds to Security Research Findings

#30

Post by qubex »

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…

I’m with you that this is corporate-speak panicked PR damage containment at its finest, but reading from kernel memory is only a flaw if you aren’t the kernel. ;)
Post reply on HN