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

51–60 of 245 posts

Re: Intel Responds to Security Research Findings

#51

Post by dmitriid »

Corporate-speak -> human-speak:

- Yes, the flow/bug exists

- We don't yet know if it can be successfully exploited at scale.

- It's quite possible that other CPU designs are affected as well, we don't have concrete data though. AMD and ARM have already started looking into the issue.

- Patches will be coming from as many manufacturers and as many OS-vendors as we can convince this is serious on a short notice.

- The patches do affect performance, often significantly, but there's nothing we can do in such a short period of time. We can only hope we can come up with better solutions down the line.

Re: Intel Responds to Security Research Findings

#52

Post by BoorishBears »

aceofspad4s wrote: post #25
bkeroack wrote: post #14

Earlier quoted context omitted.

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.

Not disagreeing, but why do you say that?

Re: Intel Responds to Security Research Findings

#53

Post by thehardsphere »

monocasa wrote: post #45

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

Actual information about the bug itself is still embargoed. Most people are assuming it's the attack you suggest based on recent commits, but it's a guess.

Re: Intel Responds to Security Research Findings

#54

Post by arghwhat »

aceofspad4s wrote: post #23
thg wrote: post #12

> Intel believes its products are the most secure in the world https://security-center.intel.com/advisory.aspx?intelid=INTE...

"The most secure in the world" does not mean "flawless". Thinking like that is pretty dangerous (and silly)

True, but no one claimed that. We are, however, claiming that Intel is not the most secure in the world.

This, prior issues as linked, Intel ME, tons of undocumented instructions—some which mess up the system—, etc.

Re: Intel Responds to Security Research Findings

#55

Post by cesarb »

> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.

A possible reading of "not a bug or a flaw" could be "works as designed", or better, "works according to the spec". The spec probably never considered cache timing side-channels (if that's what the issue is) as something to be defended against.

Re: Intel Responds to Security Research Findings

#56

Post by thg »

aceofspad4s wrote: post #23
thg wrote: post #12

> Intel believes its products are the most secure in the world https://security-center.intel.com/advisory.aspx?intelid=INTE...

"The most secure in the world" does not mean "flawless". Thinking like that is pretty dangerous (and silly)

I haven't seen any articles about AMD PSP security vulnerabilities yet, but there's a new one about IME every other month. If Intel truly is the most secure in the world, why are their CPUs riddled with security bugs big enough to drive trains through (IME has de facto become a integral part of Intel CPUs) and where are the news about non-Intel CPUs with similar bugs?

Re: Intel Responds to Security Research Findings

#57

Post by ejcx »

mintplant wrote: post #47
mey wrote: post #8

Earlier quoted context omitted.

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.

If you have malicious applications running on your laptop you have bigger problems already...

Re: Intel Responds to Security Research Findings

#58

Post by cjbprime »

2trill2spill wrote: post #41
davesque wrote: post #29

Earlier quoted context omitted.

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.

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

Re: Intel Responds to Security Research Findings

#59

Post by MBCook »

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.

Intel may have code that shows PoC on other brands/ISAs.

But if they do they haven’t shared it.

Re: Intel Responds to Security Research Findings

#60

Post by matt4077 »

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…

> do not have the potential to corrupt, modify or delete data.

I believe the point of this sentence was simply to distinguish malicious read access (possible) from any modifying access (impossible).

> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.

I believe the second half of the sentence is far more important, i. e. the attempt to broaden the news story to include other chip vendors. The scare-quotes around "bug" may suggest that Intel thinks they correctly implemented Tomasulo’s algorithm, and any flaw would not be theirs–which actually goes well with the second half of the sentence.

The part on performance is probably correct: Consumers might not notice any hit in performance. Gaming seems not to be impacted, and CPUs tend to be under-utilised anyway.

Overall, I think this statement is obviously damage control, but there really isn't anything wrong with the content from a consumer user of an Intel CPU. Basically: don't freak out, install patches, stay tuned.

The tone is actually refreshingly to-the-point. At least they are not taking us on a voyage to Qualityland.

Post reply on HN