Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Downfall Attacks

downfall.page

Post reply on HN
Print view View original

281–290 of 349 posts

Re: Downfall Attacks

#281

Post by pjmlp »

david-gpu wrote: post #130
Method-X wrote: post #124

Earlier quoted context omitted.

Like how car companies will do a cost/benefit analysis to see if a recall is worth it.

Having worked in the industry, my gut feeling is that chipmakers don't invest all that much in looking for and preventing these sorts of attacks. When working on a new feature, you are desperately trying to deliver on time something that adds value in the sorts of scenarios that it was designed for. And that is already hard enough.

The industry as a whole is yet to have the same liability laws as the car industry.

When it comes, and it will come, that will change.

Re: Downfall Attacks

#282

Post by phire »

dmatech wrote: post #210
winternewt wrote: post #41

Earlier quoted context omitted.

The Spectre attack had to be patched in the kernel in a way that significantly slowed down execution on Intel CPU:s: https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...

What's interesting is that the FDIV bug from 1994 could also be worked around, but Intel recalled and wrote off those processors[1]. For their latest several problems, their response was more of a "sucks to be you". While they provided microcode updates and worked with OS vendors, there were performance impacts that materially affected the value of the chips. 1. https://www.intel.com/content/www/us/en/history/history…

The software workaround for the FDIV bug required the actual userspace software to be modified and recompiled. There was a decade of pre-existing software out there that would be hard to fix, especially in the days before most people had the internet.

There was nothing the OS could do to work around the bug, short of disabling the entire FPU and falling back to expensive software emulation of all floating point math.

The workarounds for all these speculation bugs can be mostly applied at the operating system and/or microcode level, and is comparably cheap.

Re: Downfall Attacks

#283

Post by CTDOCodebases »

CanaryLayout wrote: post #189
CTDOCodebases wrote: post #173

Earlier quoted context omitted.

And maybe just maybe when the Snowden revelations started to come out some people woke up and realised that the companies who design the processors used in the vast majority of computers are from the US. https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill...

Since Applied Cryptograhy and everyday since publication it's been well-known and well-understood that NSA's never-ending efforts to weaken systems to make it easier for them to do their work wrecks havoc and costs billions to everyone else. Luckily their attempt to get everyone to adopt a PRNG that was broken on-purpose was thwarted. But who's to say that any chipmaker gets bribed to backdoor their design to allow t…

Some people might say “don’t attribute to malice what can be attributed to incompetence” but introducing bugs via bribing an insider or even getting one of your people a job at Intel or AMD would be a very clever way to give yourself the keys to (nearly) all the castles.

Just don’t forget to patch the microcode on your own systems.

Re: Downfall Attacks

#285

Post by autoexec »

dcow wrote: post #71
2OEH8eoCRo0 wrote: post #42

Earlier quoted context omitted.

The mitigation here can incur a whopping 50% performance penalty. At what point can customers return these CPUs for either being defective or sue for false advertising? If they can't safely meet the target performance they shouldn't be doing these tricks at all.

Did processor companies ever advertise that processors guaranteed certain security properties of the software they execute? Aren't system designers at fault for coming up with the idea of a context switch and assuming that we can trust a processor not to leak details across artificial software constructed boundaries?

> Did processor companies ever advertise that processors guaranteed certain security properties

It's not the guaranteed security as much as the advertised speed that's the issue. If they put out a chip which could only be used at half the advertised speed or else it would catch on fire, nobody would argue that they should be let off the hook because they didn't guarantee that the chips were fireproof in their ads.

If the chips can't perform at advertised speeds safely during typical use they're not delivering what was advertised.

Re: Downfall Attacks

#286

Post by blowski »

IgorPartola wrote: post #219
zamadatix wrote: post #179

Earlier quoted context omitted.

I'm not sure I agree significant gaps in the playing fields are really there. By significant I mean something that explains it should be e.g. 10x harder or something to the point it's supposed to be suspicious how the ratio is indicative of something off. Sure, you don't get to see how they laid out the transistors of the CPU but that's not how these attacks work it's by some oversight in memory handling not that dif…

This reminds me of lock manufactures vs The Lockpicking Lawyer. He is able to pick nearly every damn lock out there, yet they have all the design resources and money to hire people like him to make better locks.

I had a failed startup where we warned our customers they were using suppliers without sufficient qualifications, insurance, etc. Nobody wanted the product, even for free. At a system level, they chose to use cowboy tradespeople and cover the risk with "plausible deniability", because the market wouldn't pay them to only use quality.

It's like a Gresham's law - eventually the lowest quality dominates the market, because that's what maximises profit.

Re: Downfall Attacks

#287

Post by entriesfull »

So this is literally the same thing as AMD's Zenbleed vulnerability? Ridiculous how these companies make so much money and are completely incompetent at handling security.

Theoretically, this can be mitigated permanently by disabling hyper-threading?

Re: Downfall Attacks

#288

Post by kristjank »

Negitivefrags wrote: post #33

Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. There are really only two common cases for this anyway. VMs and JavaScript. For VMs we just need to give up on it. Dedicate specific cores to specific VMs or at least customers. For JavaScript it’s a bit harder. Either way, we need to…

Do you really think that giving up on getting things done right is the way to progress computing? While AMD has it's own spectrum of problems and not-quite-there security features, most of their vulnyerabilities have been fixed in microcode shortly after disclosure.

We as an industry should stop excusing chipmakers from doing their jobs and reject broken products. It's brand loyalty all over again, like when Apple does something retarded like losing the headphone jack and the whole industry follows, breaking years of interoperability.

When the products/services we buy break, we should demand better, not lower our expectations.

Re: Downfall Attacks

#289

Post by mike_hearn »

BeeOnRope wrote: post #120

What I find odd is that after the initial Spectre attacks, there have been a long string of these attacks discovered by outside researchers and then patched by the chipmakers. In principle it seems like the chipmakers should hold all the cards when it comes to discovery: they are experts in speculative execution, know exactly how their chips work and have massive existing validation suites, simulators and internal ma…

One possibility nobody mentioned yet: the chip vendors don't invest a ton of time looking for them because they don't actually matter that much.

Bear in mind, security researchers are incentivized to find things to build their reputation. It's very often the case that they claim something is a world-shaking security vulnerability when in reality it doesn't matter much for real world attackers. Has anyone ever found a speculation attack in the wild? I think the answer might be no. In which case, why would chip vendors invest tons of money into this? Real customers aren't being hurt by it except in the sense that when an external researcher forces action, they're made to release new microcode that slows things down. Note how all their mitigations for these attacks always have off switches: not something you usually see in security fixes. It's because in many, many cases, these attacks just don't matter. All software running on the same physical core or even the same physical CPU is either running at the same trust level, or sandboxed so heavily it can't mount the attack.

Re: Downfall Attacks

#290

Post by dgb23 »

jl6 wrote: post #139
Negitivefrags wrote: post #33

Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. There are really only two common cases for this anyway. VMs and JavaScript. For VMs we just need to give up on it. Dedicate specific cores to specific VMs or at least customers. For JavaScript it’s a bit harder. Either way, we need to…

There’s a marketing opportunity here to put multi-core back in the spotlight. Most workloads have reached the point of diminishing returns for adding more cores to a CPU, but if it turns out we need more cores just so we can run more concurrent processes (or browser tabs) securely, then here come the 128-core laptop chips…

From a user’s perspective I often think that applications which run multiple processes, demand multiple threads and large chunks of memory are too entitled.

I know it’s a (not even) half baked thought. But there’s something to that. We never really think of “how many resources is this application allowed to demand?”

Software would be orders of magnitudes faster if there was some standard, sensible way of giving applications fixed resource buckets.

Post reply on HN