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

211–220 of 262 posts

Re: More Intel speculative execution vulnerabilities

#211

Post by josteink »

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…

> This is troubling.

Only for people who for whatever reason still continue to buy Intel-based systems.

Re: More Intel speculative execution vulnerabilities

#212

Post by jdsully »

kllrnohj wrote: post #203
nolok wrote: post #157

Earlier quoted context omitted.

A single one might not be that big, but they add up (if there are several suchs checks to do in your speculated branch, instead of doing them when they appear during speculation intel chips pooled them up all at the end), and they disappear if the speculation was wrong (speculated the wrong branch ? Didn't lose any time on permission check). They're the >~10% of cpu perf intel chips have lost in the last few years wi…

> They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations. Given AMD's Zen 2 has comparable IPC to Intel at this point without doing the ACL check late it's not evident that the difference in when the ACL is done was a key efficiency gain.

They get that IPC on a better process. Shorter gate delays let you pack more into each cycle. IPC can't be divorced from process when comparing architectures.

Re: More Intel speculative execution vulnerabilities

#213

Post by monocasa »

snagglegaggle wrote: post #196
monocasa wrote: post #174

Earlier quoted context omitted.

DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. There's nothing about LUTs that are harder to make at scale than DSP slices. LUTs are just a little bank of SRAM, and SRAM is generally the most mature cells on a process node.

A lot of the inefficiency of FPGAs is signal routing. If you are very likely to implement X, Y, or Z, then it may just be more economical to put those into the FPGA as discrete circuits. At best maybe you can break them apart into common elements and provide those. There really isn't much need for LUTs any more, barring some fundamental change in data processing.

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

Re: More Intel speculative execution vulnerabilities

#214

Post by dragontamer »

monocasa wrote: post #209
dragontamer wrote: post #199

Earlier quoted context omitted.

It wasn't my intent to say that FPGAs were switching away from LUTs in general. But I expect that FPGAs of the datacenter to be more-and-more DSP-based into the future. Think of today's supercomputer problems: Deep Learning, 3d Rendering, Finite Element Analysis, Weather Modeling, nuclear research, protein folding, even high-frequency trading. What do they all have in common? They're all giant matrix-multiplication p…

Super computers and data centers are two different things with markedly different requirements. Also, deep learning isn't a great fit for FPGAs anyway. There's dedicated silicon that does a better job if you're looking for matrix multiplies per watt. Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in…

https://www.xilinx.com/support/documentation/white_papers/wp...

Xilinx absolutely markets these Alveo U200 FPGAs as deep-learning accelerators.

> Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in to get a reply out.

I'm not a HFT-user, but I've always assumed that simulating Monte-carlo Black Scholes was roughly what HFT-traders were doing. Maybe not Black-scholes itself, but maybe some other differential equation that requires a lot of Monte-carlo runs of.

Either way, Black-scholes (and other models) are partial differential equations, which are best simulated as a sequence of matrix multiplications. That's my understanding anyway.

Re: More Intel speculative execution vulnerabilities

#215

Post by segfaultbuserr »

willis936 wrote: post #201
gmueckl wrote: post #120

Earlier quoted context omitted.

The multiple splits and name changes didn't help brand recognition, at least on my end. I remember HP lab equipment being highly impressive and warranting its price. But I consistently fail to make the connection that Agilent amd Keysight products are the successors to that.

I agree. The rebrand to Keysight is the worst. Agilent was a good name by the time they split. Agilent still exists in medical but I know much less about that. I think everyone who works in test & measurement knows the big brands and knows keysight. All of the reps, culture, and products stayed the same. The rebranding I’ll never understand is Fujitsu -> Socionext.

> The rebranding I’ll never understand is Fujitsu -> Socionext.

I have to look it up... This is stupid. If I see a Fujitsu chip on a board, I know the brand and may find it interesting. But if I see a Socionext chip, I'll think it's some random U.S. startup from California.

I think there's a reason - Wikipedia says it's a joint venture of Fujitsu and Panasonic, so it makes sense for them to give it a new name, and it's common for these Japanese companies to choose a English name for global business (in the same way that NEC becomes Renesas due to the two reasons).

But what a terrible name!

Re: More Intel speculative execution vulnerabilities

#216

Post by aidenn0 »

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.

TL;DR: The market can stay irrational longer than you can stay solvent.

Re: More Intel speculative execution vulnerabilities

#217

Post by snagglegaggle »

monocasa wrote: post #213
snagglegaggle wrote: post #196

Earlier quoted context omitted.

A lot of the inefficiency of FPGAs is signal routing. If you are very likely to implement X, Y, or Z, then it may just be more economical to put those into the FPGA as discrete circuits. At best maybe you can break them apart into common elements and provide those. There really isn't much need for LUTs any more, barring some fundamental change in data processing.

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.

Re: More Intel speculative execution vulnerabilities

#218

Post by dragontamer »

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.

I'm not going to be surprised if FPGAs of the future start building in on-chip non-blocking CLOS-networks to more efficiently route messages across the chip.

https://en.wikipedia.org/wiki/Clos_network

Dedicated-hardware that serves a purpose. Sure, you can build a CLOS-network out of LUTs, but it'd be more efficient if you made dedicated hardware for it instead.

Re: More Intel speculative execution vulnerabilities

#219

Post by gpm »

paulddraper wrote: post #32
systemdtrigger wrote: post #20

One question- do these vulnerabilities , including spectre and meltdown only help in stealing information or can they also hijack your computer to do arbitrary things?

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

Re: More Intel speculative execution vulnerabilities

#220

Post by monocasa »

dragontamer wrote: post #214
monocasa wrote: post #209

Earlier quoted context omitted.

Super computers and data centers are two different things with markedly different requirements. Also, deep learning isn't a great fit for FPGAs anyway. There's dedicated silicon that does a better job if you're looking for matrix multiplies per watt. Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in…

https://www.xilinx.com/support/documentation/white_papers/wp... Xilinx absolutely markets these Alveo U200 FPGAs as deep-learning accelerators. > Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in to get a reply out. I'm not a HFT-user, but I've always assumed that simulating Monte-carlo Black Schole…

They're marketing towards that, but I can't think of any serious deep learning shops that are using them. Modern GPUs have them beat, to say nothing of dedicated ASICs. The one niche they might have I could see would be infernce on Zync-likes for non power constrained applications, but that's quite a tiny niche.

And there's cute tricks to avoid matrix multiplies in the critical path for HFT.

Post reply on HN