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

201–210 of 262 posts

Re: More Intel speculative execution vulnerabilities

#201

Post by willis936 »

gmueckl wrote: post #120
willis936 wrote: post #114

Earlier quoted context omitted.

HP? You mean Agilent-Keysight-HP? :p They’ve split up into companies that are widely successful in each of their individual fields.

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.

Re: More Intel speculative execution vulnerabilities

#202

Post by kllrnohj »

rrss wrote: post #137
wolf550e wrote: post #9

Earlier quoted context omitted.

AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.

AMD processors were also vulnerable to spectre v2. I don't know the status of the mitigations or whether it was fixed in zen 2. EDIT: I found the list I made a few months back. no guarantees, but i think it is mostly accurate. Meltdown: Intel, IBM, some ARM Spectre v1: Intel, ARM, IBM, AMD Spectre v2: Intel, ARM, IBM, AMD Spectre v3a: Intel, ARM Spectre v4: Intel, ARM, IBM, AMD L1TF: Intel, IBM Meltdown-PK: Intel Spe…

spectre v2, like v1, isn't one that is "fixable." The mitigations (retpoline & microcode updates) are essentially additions that are added in places where security checks are done to just disable speculation for that particular check. But you still have to choose when & where to use those or even if you opt to use them at all.

There are no sweeping fixes for either v1 or v2, and there probably won't be for a long time at best.

But the positive news is that v1 & v2 only matter at all if you do in-process sandboxing of untrusted code. Which most things don't do, so most things are not at any risk from it.

Re: More Intel speculative execution vulnerabilities

#203

Post by kllrnohj »

nolok wrote: post #157
koheripbal wrote: post #149

Earlier quoted context omitted.

I wonder what the performance costs of those ACL checks are.

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.

Re: More Intel speculative execution vulnerabilities

#204

Post by segfaultbuserr »

mandevil wrote: post #197
segfaultbuserr wrote: post #148

Earlier quoted context omitted.

So utilizing information discovered or obtained from independent researches from public sources and personal expertise to trade is not inside trading, albeit how your conclusions are asymmetrical, inaccessible to others, or how impactful they are - since it's inherently no difference from any other type of market analysis, and it's literally the job of financial analysts. And it's also the function of the market: tak…

Check out Matt Levine's Moneystuff email newsletter- it is what clarified this for me, and is amusing every day. Not even any ads or upsell to a pay-for subscription. I suspect if this is a thing you are curious about you will enjoy it.

Subscribed via RSS! Thanks.

Re: More Intel speculative execution vulnerabilities

#205

Post by nolok »

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.

I was not talking about intel's 10% lead over AMD, I was talking about chips from 3-4 years ago, when tested again now with mitigations, perform 10% worse or more in affected workload (see https://www.phoronix.com/scan.php?page=article&item=intel-ic... for exemple)

Re: More Intel speculative execution vulnerabilities

#206

Post by coldtea »

yifanl wrote: post #136
coldtea wrote: post #99

Earlier quoted context omitted.

Incompetence as in "they're incompetent engineers", and if so, compared to what baseline? Or incompetence in as "they weren't capable of doing it"? The latter is very probable. The former could underestimate the difficulty of such fixes...

The two statements are identical, competence is always within a given context.

It's precisely because "competence is always within a given context" that the two statements are not identical.

Incompetent can mean "as to the particular project context" (i.e. they could be great engineers that din't manage to deliver the fixes for this issue), or "as to their general professional capacity" (i.e. they are lesser engineers).

Re: More Intel speculative execution vulnerabilities

#207

Post by nieve »

epsilon_greedy wrote: post #152
jhalstead wrote: post #134

Earlier quoted context omitted.

Dumb question: Can you clarify what ZBB'd means in this context? I've never seen it before. There's a wiki page [0] with various meanings for the abbreviation, but nothing seemed to fit. Maybe Zero-based budgeting? [0] https://en.m.wikipedia.org/wiki/ZBB

Zero-based budgeting. It effectively means that a project is no longer getting funded or staffed and is therefore dead.

I have to wonder how many bitter Pyrrhic victory jokes get made by victims of poor implementation based on the creator's last name - Pyrrh. I've seen too many companies destroyed by superficially attractive budgeting schemes, even with how much tech has started to acknowledge perverse incentives they seem to get overlooked. The worst I had direct experience with was a company where they moved to all income being credited to marketing & bizdev and all other parts of the company being treated as losses to be minimized. We were both advertising supported (and thus needed content to sell anything) and had professional products that required analysts, but they when the market started looking rougher they kept the sales & ad people and concentrated layoffs on people who produced things or ran the infrastructure.

Ultra-simplified bookkeeping interpreted through the lens of too much coke nearly destroyed them. The dotcom bubble was a very strange time.

Re: More Intel speculative execution vulnerabilities

#208

Post by [deleted] »

yifanl wrote: post #183
diffeomorphism wrote: post #182

Earlier quoted context omitted.

No, the second is "incapable" and suggests that even a "great" engineer could not have done it. The first one says that a "competent" engineer could have. Big difference.

A great engineer can still be incompetent in the face of a difficult (or poorly specced) task.

[deleted]

Re: More Intel speculative execution vulnerabilities

#209

Post by monocasa »

dragontamer wrote: post #199
monocasa wrote: post #195

Earlier quoted context omitted.

Your original post is making it sound like FPGAs are switching from LUTs to DSP slices in the general case, which is blatantly not true. Yeah, it uses less resources to use a DSP slice instead of synthesizing a multiplier, bit that's because a DSP slice is just an 18x18 MAC. It's not replacing LUTs for general logic.

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 to get a reply out.

Re: More Intel speculative execution vulnerabilities

#210

Post by yifanl »

coldtea wrote: post #206
yifanl wrote: post #136

Earlier quoted context omitted.

The two statements are identical, competence is always within a given context.

It's precisely because "competence is always within a given context" that the two statements are not identical. Incompetent can mean "as to the particular project context" (i.e. they could be great engineers that din't manage to deliver the fixes for this issue), or "as to their general professional capacity" (i.e. they are lesser engineers).

Fair point. I read both statements in the context of the particular hardware bugs Intel's trying to fix, but I can see how my comment is quite vague.
Post reply on HN