Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More Intel speculative execution vulnerabilities

mdsattacks.com

Post reply on HN
Print view View original

61–70 of 262 posts

Re: More Intel speculative execution vulnerabilities

#61

Post by fyfy18 »

cookiecaper wrote: post #50
segfaultbuserr wrote: post #31

Earlier quoted context omitted.

Hewlett-Packard was an electronic engineering, semiconductor, and computing company from the beginning (the first product they sold was an audio distortion analyzer, it used a creative circuit to achieve high performance at minimum cost), they used to do serious and innovative R&D. There were the glorious days when Hewlett-Packard makes state-of-art test equipment and semiconductor devices, developed in-house enterpr…

HP was the Google of its day when H & P were in charge. People either retire or die eventually. What happens to Google when time claims Larry and/or Sergei? Not trying to besmirch or minimize early HP by comparing to Google -- probably better to use Musk/SpaceX or something -- but IMO this is the key takeaway that doesn't seem widely discussed. Innovative companies have innovative leaders with expert-level knowledge…

What about companies like IBM? The company was originally foundered in 1911, but you could say their heyday wasn't until half a century later (or even more), after the original founder had left.

Re: More Intel speculative execution vulnerabilities

#62

Post by mrob »

systemdtrigger wrote: post #30
rocqua wrote: post #26

Earlier quoted context omitted.

It can be used to defeat ASLR, which is a way to make exploiting code harder. However, defeating ASLR just makes it easier to deploy an exploit against a program, but you still need the exploit. It doesn't immediately give code exec, but generally it wouldn't be very hard to turn arbitrary memory read capabilities into privilege escalation. As long as you know what the system is running.

So the sense I'm making is- that most of thesr attacks need to be supervised and need you to be a target in particular?

The attacker needs some way to execute code on your machine. The code doesn't need any special permissions, although attacks are more difficult (but not impossible) if it doesn't have access to high resolution timing information. You can be a target by visiting a webpage with JavaScript enabled.

Re: More Intel speculative execution vulnerabilities

#63

Post by ageofwant »

coldtea wrote: post #35
ageofwant wrote: post #10

Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels. - name: Disable CPU-sapping security mitigations become: yes lineinfile: path: /etc/default/grub line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off…

> No I don't give a fuck about the 'risk' this introduces Well, let's hope you're not powned because of this and get dragged into giving some fucks, for a 5-10% of performance hit you wouldn't notice anyway...

Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ? And they are not particularly unique.

Do you understand my risk and load requirements better than I do ?

Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ?

But thanks for your concern and all.

Re: More Intel speculative execution vulnerabilities

#64

Post by scandinavian »

dijit wrote: post #58
scandinavian wrote: post #48

Earlier quoted context omitted.

From the comment in your link: > It's missing the entire actual implementation of the Spectre attack, which requires analysis of read times to see if you're hitting the processor cache or not. "analysis of read times" is what the browsers "fixed" to mitigate the attacks (and site isolation later). Again, there has been no working attacks on updated browsers. Please feel free to link an example of one though, I will g…

The browser mitigation’s only work with the kernel mitigation’s. Neither is working well without the other. And yes. I’m very well versed on this topic.

>The browser mitigation’s only work with the kernel mitigation’s.

That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.

Re: More Intel speculative execution vulnerabilities

#65

Post by dd36 »

Jonnax wrote: post #6

So Intel failed to mitigate the vulnerability when it was first reported. Then they extended the embargo from May until November. And they still didn't fix it. What's going on with Intel? Like they're going all in with lying in benchmarks against AMD and straight up forgetting what has been reported as security issues.

That seems to be the new corporate PR move.

Re: More Intel speculative execution vulnerabilities

#66

Post by Mirioron »

xucheng wrote: post #52

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, l…

I wonder if it might not come to bite them though. Doing it this way means that the media will constantly keep talking about yet another vulnerability in Intel CPUs for years. There's a chance that Intel might and up picking a reputation like Flash did for being insecure.

Re: More Intel speculative execution vulnerabilities

#67

Post by jacquesm »

cookiecaper wrote: post #50
segfaultbuserr wrote: post #31

Earlier quoted context omitted.

Hewlett-Packard was an electronic engineering, semiconductor, and computing company from the beginning (the first product they sold was an audio distortion analyzer, it used a creative circuit to achieve high performance at minimum cost), they used to do serious and innovative R&D. There were the glorious days when Hewlett-Packard makes state-of-art test equipment and semiconductor devices, developed in-house enterpr…

HP was the Google of its day when H & P were in charge. People either retire or die eventually. What happens to Google when time claims Larry and/or Sergei? Not trying to besmirch or minimize early HP by comparing to Google -- probably better to use Musk/SpaceX or something -- but IMO this is the key takeaway that doesn't seem widely discussed. Innovative companies have innovative leaders with expert-level knowledge…

I would say H & P had a serious edge over the Google guys in the ethics department.

Re: More Intel speculative execution vulnerabilities

#69

Post by Grangar »

soulofmischief wrote: post #33
aeiou1234 wrote: post #3

another 0-4% performance hit for skylake

I'm glad I started off not overclocking my 6700k with the intent of cranking up the clock over time in order to maintain the same performance with regard to software bloat and mitigations like these. I got lucky and can hit 5Ghz safely, with a base of 4Ghz. Definitely jumping to AMD next time around though. My next upgrade was originally going to be dual Xeons but those Ryzen Pro 3000s are looking nice.

Yeah I'm looking into upgrading my 6500 to a Ryzen 3 3600. It's a shame there's no B550 boards yet.

Re: More Intel speculative execution vulnerabilities

#70

Post by ageofwant »

systemcluster wrote: post #54
coldtea wrote: post #35

Earlier quoted context omitted.

> No I don't give a fuck about the 'risk' this introduces Well, let's hope you're not powned because of this and get dragged into giving some fucks, for a 5-10% of performance hit you wouldn't notice anyway...

Anecdotally, the performance hit from the security mitigations since the Spectre/Meltdown publication has been very noticeable.

More anecdata: On my workloads, which involves moving large discrete image frames as part of a video inference ML pipeline through a message broker and other processing pipelines, de-mitigating decreased system loads ~25% on average. Some workloads up to 30% depending on inference model. So yes noticeable.
Post reply on HN