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

221–230 of 262 posts

Re: More Intel speculative execution vulnerabilities

#221

Post by pdimitar »

IntelThrowaway wrote: post #51
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.

One of the problems with Intel culture - especially under BK was that the philosophy was "Focus on our key goals to the exclusion of everything else". It was meant to keep focus and ensure we moved quickly. The problem with that is it meant we were entirely unresponsive. It doesn't matter if something important has come up because you've already agreed what the priority is, you've already committed to what you're goi…

That company culture and structure needs to change, and fast. Giants do fall.

Instead of focusing on a PR war and scrambling to salvage one fire after another, Intel needs to produce a strategy that will keep them in the game by actually providing value -- not by twisting the hands of big corps for lucrative long-term contracts.

Re: More Intel speculative execution vulnerabilities

#222

Post by monocasa »

snagglegaggle wrote: post #217
monocasa wrote: post #213

Earlier quoted context omitted.

That doesn't really follow given that LUT count has been increasing with Moore's law.

I see your point, but I think that is because of a lack of commitment to higher integration functional blocks. A lot of work done on a FPGA is very regular. I suppose LUTs could be the best way to do create the glue logic that basically amounts to signal routing and synchronization, but it seems unlikely.

If you can get by with higher level functional blocks sitting off of a network on chip, you go the direction of a modern SoC. The neat games you can play with routing those NoC packets around are close to what you're talking about.

Re: More Intel speculative execution vulnerabilities

#223

Post by paulddraper »

gpm wrote: post #219
paulddraper wrote: post #32

Earlier quoted context omitted.

To exploit these vulnerabilities, you already need (unprivileged, sandboxed) RCE. These vulnerabilities "only" steal information; however that information could of course be leveraged into privilege escalation or anything else.

This isn't true unfortunately. Being able to cause manipulate the control flow of code that already exists on the computer can be sufficient. See netspectre for an example that worked on real google cloud vms and local wired networks. http://www.misc0110.net/web/files/netspectre.pdf

Wow, that is impressive.

Yes in theory you could do that, but to actually exploit in practice I would have guessed couldn't be done.

Re: More Intel speculative execution vulnerabilities

#224

Post by bonzini »

mtgx wrote: post #60
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…

It certainly is, and that much was obvious as Intel "committed" to fixing Spectre V1 in software as opposed to hardware. Worse yet, it doesn't think a hardware solution is necessary. Except, that pretty much all recent Spectre-related bugs are variants of Spectre V1.

They are not. They are based on leaking microarchitectural state such as the contents of the store buffer, while spectrev1 is based on leaks from the branch predictor.

The difference is that the contents of e.g. the store buffer are short-lived, while branch prediction is by design learning behavior of the program for long term use.

It's not a coincidence that Spectre v1 affected all processors and not just Intel x86. Also Spectre v1 still has no widely-deployed hardware mitigation, while for all other vulnerabilities the processor could be patched to add a "flush the leaked state" instruction with a microcode update.

Re: More Intel speculative execution vulnerabilities

#225

Post by blaser-waffle »

nradov wrote: post #128
cookiecaper wrote: post #50

Earlier quoted context omitted.

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…

This is one reason why the current high stock market valuations for large, profitable tech companies are crazy. Eventually the corporate culture rots from the inside and they're overtaken by a disruptive competitor. Unfortunately there's no practical way for retail investors to take a short position on those stocks for 30 years in the future; regular options only go out about 3 years.

> Unfortunately there's no practical way for retail investors to take a short position on those stocks for 30 years in the future; regular options only go out about 3 years.

You don't, not if you're a small investor. You go index and hedge your bets that they're not all going to rot at the same time.

Re: More Intel speculative execution vulnerabilities

#226

Post by yvdriess »

nolok wrote: post #155
rrss wrote: post #135

Earlier quoted context omitted.

> going all in with lying in benchmarks against AMD I'm assuming this is referencing the "intentionally misleading benchmarks" piece in servethehome. It's worth reading the follow up, in which the author discovers their biggest complaint (older version doesn't have avx2 enabled by default on zen2) was not an issue because Intel manually enabled avx2. https://www.servethehome.com/update-to-the-intel-xeon-platin...

They request all benchmark done with SMT off, they insist on doing their bench without the security fixes for Spectres/Meltdown applied, they use dubious TDP counting, ... AMD has its fair share of issue in their own self published benchmarks, but at least when third party publish they're not forced to cripple other companies' chips.

As addressed, the benchmarks in question were for HPC, where turning off SMT and running without mitigations is standard.

Re: More Intel speculative execution vulnerabilities

#227

Post by wolf550e »

Twirrim wrote: post #181
wolf550e wrote: post #166

Earlier quoted context omitted.

L1TF was an incredibly stupid bug in Intel's L1 cache implementation. I very much doubt IBM's POWER chips had the same issue. Do you have any source for this?

Quoting from https://www.ibm.com/blogs/psirt/potential-impact-processors-... "On August 15, 2018, security vulnerabilities codenamed Foreshadow/L1TF (CVE-2018-3620, CVE-2018-3646 and CVE-2018-3615) were announced. Two of the vulnerabilities (CVE-2018-3620 and CVE-2018-3646) could potentially impact Power Systems. The Firmware and OS patches released by IBM in February and March 2018 to address the original Meltdown v…

Thank you!

L1TF is this: https://software.intel.com/security-software-guidance/insigh...

I'm surprised IBM did this. I thought better of them.

Re: More Intel speculative execution vulnerabilities

#229

Post by icedchai »

paulddraper wrote: post #223
gpm wrote: post #219

Earlier quoted context omitted.

This isn't true unfortunately. Being able to cause manipulate the control flow of code that already exists on the computer can be sufficient. See netspectre for an example that worked on real google cloud vms and local wired networks. http://www.misc0110.net/web/files/netspectre.pdf

Wow, that is impressive. Yes in theory you could do that, but to actually exploit in practice I would have guessed couldn't be done.

Don't get too excited. From the paper: "In the Google cloud, we leak around 3 bits per hour from another virtual machine." This is, of course, under ideal conditions.

Re: More Intel speculative execution vulnerabilities

#230

Post by hansendc »

voidmain wrote: post #111

Can we please have an architectural MSR to disable TSX?

The good news: There's a new MSR which lets you do this:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

The less good news: as far as I can tell, Intel did not commit to how architectural this will be going forward. Considering the role TSX has played in speculation-based attacks, it appears to me to be a generic mitigation that would be great to accompany TSX wherever it is available in the future. Now that MSR_IA32_TSX_CTRL is defined, it should be easier to implement going forward.

Disclaimer: I work on Linux at Intel.

Post reply on HN