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

121–130 of 245 posts

Re: Intel Responds to Security Research Findings

#121

Post by int0x80 »

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

There are not saying it explicitly, which they should.

Re: Intel Responds to Security Research Findings

#122

Post by rocqua »

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…

> says their current course of action (working with key stakeholders)

"Working with key stakeholders" is not stating your course of action. At best, it is stating you are taking any action at all. I suppose that it is good that Intel has faith the stakeholders they are talking to are the important ones.

Re: Intel Responds to Security Research Findings

#123

Post by mywittyname »

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…

> 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 processors, but I'm not sure if it made it into the mainline.

Re: Intel Responds to Security Research Findings

#124

Post by shock »

tedunangst wrote: post #91
cjbprime wrote: post #77

Earlier quoted context omitted.

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

Would not be the first time vendor X knows vendor Y is vulnerable even as vendor Y denies it.

Now my interest is piqued: what instances of `vendor X` and `vendor Y` do you know of?

Re: Intel Responds to Security Research Findings

#125

Post by betterunix2 »

cjbprime wrote: post #77
eropple wrote: post #64

Earlier quoted context omitted.

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.

It was an AMD engineer, and he referred to specific details about a microarchitecture bug that seems to be important in this attack. So we are really being asked to believe that Intel's PR team knows more about AMD's microarchitecture than AMD's engineers (or that AMD's engineers are secret PR agents).

Re: Intel Responds to Security Research Findings

#127

Post by dmitrygr »

> Intel believes these exploits do not have the

> potential to corrupt, modify or delete data.

That's strange, because I am pretty damn sure that with a working read_kernel_byte(u64 addr) primitive, I can gather enough info to corrupt, modify, or delete a lot of things.

Re: Intel Responds to Security Research Findings

#128

Post by qubex »

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…

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

Re: Intel Responds to Security Research Findings

#129

Post by userbinator »

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.

If the general consensus that it's a timing attack related to speculative execution is correct, then Intel is correct to say that --- any CPU which does speculative execution in the aggressive manner that (most of --- AFAIK they still have some low-power non-OoO cores) Intels' do will be affected similarly.

There's this interesting post on RISC-V from roughly the same timeframe, that suggests it's not immune either: https://groups.google.com/a/groups.riscv.org/forum/#!msg/isa...

Post reply on HN