Hacker News Reader

Comment by ejcx | Hacker News Reader

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 right but that's not a problem...

Short and sweet and has it all. If anything, it is a day late but monstrous organizations probably had a lot of bureaucracy to cut through.

People are so reactionary and quick to throw any company with a security issue under the bus, without ever having been on the other side of the table. The reality is issues happen to everyone and Intel wants to fix it.

View on HN

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.

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

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/

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

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

...which was linked-to from this article: https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...

It's also manipulative, mentioning AMD and ARM for no other reason to make people think those also have the flaw.

ARM may have a flaw: https://lwn.net/Articles/740393/

ARM 64 does have the flaw. The tricksy wording is probably that AMD does manufacture some ARM 64 chips, so perhaps they were involved in that fix.

Which is still intentionally misleading on Intel's part.

> Admits responsibility and says their current course of action

And specifically avoids mentioning that reading data is possible:

> Intel believes these exploits do not have the potential to corrupt, modify or delete data.

That's not taking responsibility. That's downplaying that the flaw exists.

A flaw their key competitor doesn't have, but they go on to mention several times just after they say things like " with many different vendors’ processors and operating systems — are susceptible to these exploits."

The entire thing has been written to be misleading. To pretend that the bug doesn't exist, and that AMD have it too, which is false.

I don’t agree with you but your point is both defensible and well-argued, and I applaud that. That’s what civilised debate should be all about, right?

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

There are other issues Intel does not fix (backdoorable hardware outside of the control of the owner). This is part of Intel's image. So, there's that.

Reply on news.ycombinator.com