Hacker News Reader

Comment by xucheng | Hacker News Reader

> 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, leaving the public with a false sense of security. Slapping a year-long embargo after another (many news cycles apart) and keeping vulnerabilities (too) many people are aware of from the public for a long time is still a viable strategy.

This is troubling.

View on HN

Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything, just two or three additional unpatched PoCs with full source code would be enough.

However, unlike buffer overflow exploits, most researches on CPUs are conducted within academic institutions, doing this certainly breaches the code of conduct. Also, CPUs are the most critical components of all computers and their vulnerabilities are difficult to fix, doing this would put a lot of users under immediate risks, unlike a root exploit, which is less risky and can be fixed within a week. Doing Full Disclosure of hardware exploits that users can not fix is much more ethically problematic than software exploits.

But leaving the users in the dark and allowing Intel to delay its fixes by not to exert pressure is obviously irresponsible, which is the original argument for full disclosure.

So I'm not sure. Perhaps Google's Project Zero is a good model and a good compromise between resposible/full disclosure - embargo for 90 days, full disclosure later, all information becomes public after 90 days and no extension is allowed, period. For CPUs, perhaps we can use 180 days.

Somewhat tangential point: having a single technological leader is a significant risk. Thankfully AMD is hitting its stride again and seems to be at least somewhat immune or less susceptible to this class of attack. Apples arm processors are approaching x64 performance in some cases.

Imagine if Intel had squashed the competition only to find their architecture is a security risk. As it is now, it really sucks to know that yet another cpu power robbing patch is coming. As a processor monolith they could set back most operations 10 years plugging security flaws. At least I feel like I have a few replacement options. However the skeptic in me feels like it’s only a matter of time that other platforms are researched with equal scrutiny.

If the vulnerability pipeline is a few years deep and AMD wasn't considered a worthwhile target a few years ago, we might not want to interpret a lack of AMD vulnerabilities as evidence that they are immune.

AMD was always a worthy target because they sold a lot of cost-effective mid and low range CPUs to Dell and friends. They have been absent from the peak performance market for a while but that's a small fraction of computers. After all, AMD didn't go out of business, and they had to be selling a lot of CPUs.

But isn't that not where the worry is? Isn't it cloud computing and server spaces where the real damage can be done here?

No, these vulnerabilities potentially let userspace code escalate privileges, which could lead to ransomware or credential exfiltration. Stealing bank account passwords clearly does damage, and various governments have paid ransoms on the order of $100,000 to recover encrypted files.

I’d argue that side-channel attacks are less of a problem in the server space because servers generally don’t download untrusted code from the internet and execute that code blindly (assuming you aren’t running other peoples’ VMs).

> assuming you aren’t running other peoples’ VMs

That's the problem right there: the vast majority of workloads in the cloud runs on shared hosts.

AWS/GC dedicated host pricing is not actually that crazy of a markup (around 50% last time I investigated), but that's still very noticeable at scale, and billing granularity is by the hour.

I agree public cloud needs mitigations to be secure. But a significant number of workloads (~50%?) run on-prem or in private clouds. Those generally host "more trusted" code.

True, but only if you trust all your services equally, or restrict each host to a single one.

Otherwise you lose a security boundary.

> assuming you aren’t running other peoples’ VMs

But that’s exactly what cloud does.

My second thought - Perhaps embargo with limited length can help, but it only solves the problem of endless embargo. But the following remains unaddressed...

> Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis

Being PoC-oriented means that even if there is full disclosure, Intel is still going to patch PoCs in an ad-hoc manner, rather than a full fix.

Also, if you have full disclosure of a potential problem without PoC, it doesn't solve the problem - Intel can choose to ignore it by not doing a careful root-cause analysis, and fix the problem if there is any.

> Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything

At the risk of sounding pedantic, that's not 'full disclosure', that's 'responsible disclosure' - https://en.wikipedia.org/wiki/Responsible_disclosure

Is it?

I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero is responsible disclosure because the information is released after the problem is patched. I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".

> I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero

Good point.

> I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".

If you aren't disclosing everything you have, it's not full disclosure, it's some other disclosure model.

I think we're just arguing semantics though, as I fully agree with your earlier paragraph, that hardware vulnerabilities are trickier than software vulnerabilities regarding disclosure, and that Project Zero is doing roughly the right thing.

I wish FPGAs were fast enough because I don’t see how else this problem can be solved. Easy to issue a patch that fixes logic implemented in FOGA. Impossible to fix hardware rooted issues unless they work around it at a huge performance cost, if at all possible.

Not an EE so I’m just dumping my thoughts.

One problem of FPGAs is that the absolute dependence on proprietary tools from the vendor, the hardware industry is much more closed in comparison. By using those tools, you have to agree the terms and conditions such as the following (this one is from Xilinx),

> By using this software, you agree not to: [...] display the object code of the Software on any computer screen.

From a security perspective, it doesn't inspire confidence, there's no ability to do an independent verification, something like doing a reproducible build with an compiler which source code is open to audit. There's no equivalence of GCC or LLVM for FPGA.

Fortunately, there are some people working on it, just saw it on the homepage, although it's a long way to go... https://news.ycombinator.com/item?id=21522522

I'm not an EE, just my 0.02 USD.

> By using this software, you agree not to: [...] display the object code of the Software on any computer screen.

I.e. ... I can print it? Good.

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-detail/en/xilinx-inc/A-U200-...) and require a very specific set of skills to work with.

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 DSP Slice.

Synthesize a 32-bit wallace-tree multiplier for instance, and you'll use thousands of LUTs (maybe 2000ish). However, reserve a DSP-slice for a 32-bit multiply routine, and you'll only use ONE slice.

However, those multipliers on the DSP-slice could be "wasted" if you didn't need that many multipliers. Maybe your arithmetic is primarily addition and subtraction. In any case, when most people talk about "Reconfigurable FPGAs", they're talking about the LUTs which can be the building block of any logic. They aren't talking about DSP-slices, which are effectively prebuilt ALUs connected in a mesh.

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.

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.

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.

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.

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.

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.

I wouldn't be surprised if some do that under the hood already. The cadence hardware emulators for sure do, but they're not quite FPGAs.

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.

The cynic in me thinks a good capitalist would try to sell the discovery to the highest bidder. In this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short on Intel stock. I imagine the payoff would be in the millions of dollars in both cases, and I doubt either scenario is even illegal.

> a good capitalist would try to sell the discovery to the highest bidder.

Not all security researchers are doing it for the money, 0day markets always exist. Malicious people who wish to use the vulnerability for profit wouldn't disclose the vulnerability to begin with. So it's not a new problem.

> this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short

But your comment is insightful - Intel's case is unprecedented. Due to the huge impact of the vulnerabilities, the threat is not coming from the blackhat sellers or black market buyers, but Intel. Intel itself can simply pay researchers with an NDA to keep their mouths shut, while still doing nothing. The impact of the vulnerabilities is also high enough to move the stock market, allowing insider trading.

If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading.

Here's an example of Gotham City Research trying this approach and failing: https://www.thedrum.com/news/2017/09/21/criteo-counters-frau...

(Not a lawyer)

Yeah. Someone actually tried this with AMD last year, but the security vulnerability they found was a lot less important than their breathless press release claimed and the markets basically shrugged. There was some funny business there too, with them paying third-party security researchers to confirm the bugs based on a more technical report the rest of us didn't get to see and the actual publicly-announced description they were used to lend credibility to being kept from them.

Sounds like "Markets can stay irrational longer than you can stay solvent" would apply here

The problem in the Gotham case I linked was that markets didn't consider the news to be as significant as Gotham expected them to.

The goal with this strategy is to find serious issues that will rightly cause investors to immediately decrease their estimate of the value of the company.

>If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading.

Thanks for the information, never thought about that. On the other hand, would purchasing information about a flaw and using the information to bet the stock constitutes insider trading?

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 all you want.

If they signed a NDA to cash in on the bug bounty and then sold it to you, I think they are vulnerable to breach of contract, but I don't think you are legally vulnerable, however this is not legal advice, I am not a lawyer, and do you want to go through the expense of finding out?

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: take all these trades as inputs, calculate its output - current price.

Makes perfect sense to me now. I now realized I've some serious misunderstanding of insider trading. Thanks for clearing it up for me.

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.

Insider information is not about the information itself, but rather the source of the information. The exact same piece of information could be insider information or not depending on who you heard it from. Think of it like a watermark or stain on the information. When the information is generated within the "insider" circle, it is permanently stained until that information is made public. Legally, this stain remains no matter how many hops it goes through. However, if the same information is generated by an "outsider" that figured it out, that same information is not stained.

Example: Your neighbor Alice is a hotshot executive at BigCorp. If Alice comes over to your BBQ and starts telling you about how bad their upcoming quarter is going to be, that's probably tainted information. However, if your other neighbor Bob comes to your BBQ, and starts talking about how grumpy Alice has been, and she's always grumpy like this when BigCorp is about to have a bad quarter... That's fair game. Same information, different sources.

That said, in the US I think there must be some indication or reasonable expectation that you knew or were willingly blind to the non-public status of the information.

If the person you bought it from would have been allowed to trade on it, that should be ok.

Security researchers aren’t hedge funds, most aren’t swimming in cash, and can’t borrow millions on a whim. Also, pouring your life savings into a bet like this is probably dumb.

A security researcher could partner with an investment fund, however. I agree this is too risky to be a good idea for most individual researchers to use directly.

Also not a lawyer, but check what country you're in before you try this. In countries like the UK, many more things are insider trading than in the US.

Sorry, yes, only trying to talk about the US here

Delaying the fixes is probably making them more money, if they lose a few more percent of performance they lose the number one position on all possible use cases/workflows , the PR hit will be huge, people could demand refunds or compensation (I mean you just sold them an expensive product without disclosing it is insecure and it will lose it's performance)

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.

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, google cloud, azure, etc.

> 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.

Or like java applet. Oracle has killed java applet by not handling security issues in a responsible manner.

Java applets died primarily due to the terrible user experience and inconsistent browser support. Security issues were less of a factor.

To be fair the entire approach was flawed and should have been abandoned in favour of SELinux plus something like seccomp years before.

Selinux, apparmor, etc. are not viable security solutions for pretty much anything, because they are too coarse grained. Seccomp that blocks everything, but leaves just a couple of syscalls to interact with an external proxy process is closer to what could have worked, which is basically a sandbox.

How do you feel about openbsd's pledge()? I would really like something as simple as that on linux...

seccomp actually has that ability to allow only small portion of selective operations.

Block everything except io is just one of its blocking mode.

And the list is even configurable. Docker do use such ability to filter out sys-calls that shouldn't be used in the container.

Sun...

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.

> This is troubling.

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

Reply on news.ycombinator.com