More Intel speculative execution vulnerabilities • Hacker News Board

Re: More Intel speculative execution vulnerabilities

#191

Post by paulddraper » Wed, Nov 13, 2019, 5:14 PM UTC

zzzcpan wrote: post #109

wolf550e wrote: post #55

Earlier quoted context omitted.

There used to be a time when people thought relying on if statements for security was enough and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs. Now we know better. 1 - https://en.wikipedia.org/wiki/Singularity_(operating_system)

> and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs WebAssembly doubles down on it today. Technically, though, software isolated lightweight processes within the same address space is still a very real possibility, it's just that isolation is up to the compilers now that have to emit spectre-proof code, so no native blobs. Which, let's get real, has to happen sooner or la…

> hardware can't be trusted

"Spectre-proof" code are specific workarounds for hardware bugs, not protection against all hardware security issues.

Re: More Intel speculative execution vulnerabilities

#192

Post by duxup » Wed, Nov 13, 2019, 5:19 PM UTC

I recall a Google security blog that spoke more generally that with so many layers of code that you don't know what they're doing the result is that effectively they consider any speculative execution that exists at the time of writing the blog may be a potential vulnerability.

Re: More Intel speculative execution vulnerabilities

#193

Post by zzzcpan » Wed, Nov 13, 2019, 5:19 PM UTC

paulddraper wrote: post #191

zzzcpan wrote: post #109

Earlier quoted context omitted.

> and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs WebAssembly doubles down on it today. Technically, though, software isolated lightweight processes within the same address space is still a very real possibility, it's just that isolation is up to the compilers now that have to emit spectre-proof code, so no native blobs. Which, let's get real, has to happen sooner or la…

> hardware can't be trusted "Spectre-proof" code are specific workarounds for hardware bugs, not protection against all hardware security issues.

Obviously. Hardware can't be trusted to do secure isolation, this is the context here.

Re: More Intel speculative execution vulnerabilities

#194

Post by OrangeMango » Wed, Nov 13, 2019, 5:20 PM UTC

annoyingnoob wrote: post #170

Is disabling hyper-threading a via work-around for these vulnerabilities?

My understanding is that this works for many (but not all) of the vulnerabilities. Interestingly, in the past few years Intel has dramatically increased the number of non-SMT processors on their product list.

If that is going to be your personal way of mitigating the issue, you've got a choice of 4, 6, and 8 core parts at a significant discount compared to their HyperThreaded variants.

Re: More Intel speculative execution vulnerabilities

#195

Post by monocasa » Wed, Nov 13, 2019, 5:25 PM UTC

dragontamer wrote: post #179

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.

> DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers. > There's nothing about LUTs that are harder to make at scale than DSP slices. Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a…

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.

Re: More Intel speculative execution vulnerabilities

#196

Post by snagglegaggle » Wed, Nov 13, 2019, 5:27 PM UTC

monocasa wrote: post #174

dragontamer wrote: post #163

Earlier quoted context omitted.

FPGAs are significantly slower and significantly more expensive than dedicated hardware. The FPGAs used for data-center usage don't even use LUTs primarily anymore, because fully configurable LUTs are too slow and too expensive to manufacture at scale. Instead, data-center sized FPGAs use "DSP Slices" primarily (yeah, LUTS exist but its mostly DSP Slices). They're very expensive ( https://www.digikey.com/product-deta…

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.

Re: More Intel speculative execution vulnerabilities

#197

Post by mandevil » Wed, Nov 13, 2019, 5:36 PM UTC

segfaultbuserr wrote: post #148

mandevil wrote: post #131

Earlier quoted context omitted.

It would be insider trading if the person you purchased from had a duty to the company to keep the secret (they worked for the company and learned of the vulnerability in the normal course of their job, say). If they are an independent researcher and you are an independent researcher, trade away. Then it is just like using satellites to find out that a shopping mall's parking lot is empty on a big shopping day- trade…

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.

Re: More Intel speculative execution vulnerabilities

#198

Post by [deleted] » Wed, Nov 13, 2019, 5:40 PM UTC

monocasa wrote: post #195

dragontamer wrote: post #179

Earlier quoted context omitted.

> DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers. > There's nothing about LUTs that are harder to make at scale than DSP slices. Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a…

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.

[deleted]

Re: More Intel speculative execution vulnerabilities

#199

Post by dragontamer » Wed, Nov 13, 2019, 5:47 PM UTC

monocasa wrote: post #195

dragontamer wrote: post #179

Earlier quoted context omitted.

> DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers. > There's nothing about LUTs that are harder to make at scale than DSP slices. Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a…

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 problems at their core... fundamentally built up from the multiply-and-accumulate primitive.

EDIT: The only real exception is maybe EDA. I don't know too much about those algorithms involved, but IIRC it involves binary decision diagrams (https://en.wikipedia.org/wiki/Binary_decision_diagram). So some problems aren't matrix-multiplication based... but I dare say the majority of today's supercomputer problems involve matrix-multiplication.

Re: More Intel speculative execution vulnerabilities

#200

Post by tracker1 » Wed, Nov 13, 2019, 5:49 PM UTC

kevin_thibedeau wrote: post #187

AJ007 wrote: post #87

Earlier quoted context omitted.

In this case, the FBI and SEC may need to investigate precisely what is going on. If Intel is doing partial fixes it knows of other things that aren’t being disclosed there could be criminal activity occurring. Additionally, this had big implications for cloud providers. If additional liabilities of data leaks are foisted on companies, insurance companies and corporate counsel may just say no more using amazon, googl…

> here could be criminal activity occurring. More likely some agencies don't want their exploits to stop working.

Which is sad... It wouldn't bug me nearly as much if they (NSA etc) had a sunset/disclosure policy of a reasonably short timeframe (say 60 days or so) for disclosure to the org that makes the software/hardware.

I can understand a state agency keeping a security flaw a secret to exploit in the near term... but stockpiling for years only to let stuff leak eventually is just irresponsible.

Note: I'm not saying that I like state sponsored hacking, only that I understand it being a reality and pragmatically wish they struck a better balance.