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

321–330 of 349 posts

Re: Downfall Attacks

#321

Post by kbenson »

throwaway892238 wrote: post #226
eternityforest wrote: post #221

Earlier quoted context omitted.

HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform. I'd rather we go the other way, and build…

If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree. Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads…

> If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree.

That is exactly what standardization means, by definition, both dictionary and colloquially.

Re: Downfall Attacks

#322

Post by locriacyber »

stevefan1999 wrote: post #242
broodbucket wrote: post #233

Earlier quoted context omitted.

Microarchitectural behaviour changes from generation to generation, and thus so do side effects. Fixing things by accident (and also introducing new problems by accident) are relatively frequent occurrences

Fix one big bug, get two small bugs...

We should just call them "slimes".

Re: Downfall Attacks

#323

Post by dormento »

CanaryLayout wrote: post #217

The NES incorporated a chipset that buried an entire 6502 inside. You can get a Rockchip ARM chip for the price of a pizza that incorporates mixed cores on the die. Maybe the chipmakers don't NEED to solve every edge case until the end of time, but delegate side channel attack mitigations like this back to the chipgobblers (us). Hear me out: Instead of making SMT an all-or-nothing pre oposition, we have "lousy cores"…

I think its a market thing.

You can have performance cores x efficiency cores.

You do now want to be the one who proposes trusted cores x "lousy" (untrusted) cores. The benefits, however many, would be lost in the discourse of "promoting insecurity". Such is life.

Re: Downfall Attacks

#324

Post by dcow »

autoexec wrote: post #285
dcow wrote: post #71

Earlier quoted context omitted.

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…

They do perform at the advertised speeds, just not in a multi-user soft context switched situations.

Re: Downfall Attacks

#325

Post by justinator »

BeeOnRope wrote: post #195
justinator wrote: post #174

Earlier quoted context omitted.

I'm in the camp that developers shouldn't be responsible for having a transcendental ability to predict future (example) security holes. If one appears, it's really the QA's job to document it and experiment with other similar vectors of attack. The developers are, you know: developing. Bring them back in when the security issues needs to be fixed, once it's found just how big the problem is.

Shouldn't the functions of "development" and "QA" both reside under the umbrella of the chip-maker though? In fact, chip-makers famously invest an insane amount of money into "QA" (aka "validation") and many features or lack thereof are often put down to the cost of QA rather than the cost of development.

>Shouldn't the functions of "development" and "QA" both reside under the umbrella of the chip-maker though?

Sure, umbrella, but different teams. What I'm trying to get across is that it's a good thing that the developers are not wearing the QA hat, so that the QA people are thinking in ways that aren't exactly parallel to the developers. You get close to your work, you sometimes forget that you're not look at the larger picture.

Think of it like if I was building a big secure wall in front of my house, but I neglect that it's easy to just walk to the opposite side to get in. Oh, whoops, I was too focused on the solution in front of me.

Just fundamentals is all.

Re: Downfall Attacks

#326

Post by buildbot »

kragen wrote: post #320
AgentOrange1234 wrote: post #310

Earlier quoted context omitted.

FWIW. Spectre/meltdown really caught the hardware development world off guard. Speculative execution was well-trodden ground and we thought it was fine. After these attacks, we had legacy designs that we needed to patch in a hurry, and the performance costs of not speculating were unfathomable. A lot of work went into mitigations like new kinds of barriers. But hardware designs are enormous and there is state lurking…

dan bernstein had pointed out the risk that speculative execution would lead to side-channel attacks years before, but there's a common pattern where security people point out a risk and then vendors dismiss it as impractical until it's demonstrated in practice

In computer engineering grad school, I mentioned to my PI that there was an upcoming hardware security flaw that I had heard about from … sources… and he quickly guessed it was speculative execution related without knowing anything more. I think people knew it was possibly dangerous, but the performance gains from speculative execution were huge enough nobody in Intel/AMD red-teamed the design basically.

Re: Downfall Attacks

#327

Post by pseudalopex »

CanaryLayout wrote: post #213
pseudalopex wrote: post #183

Earlier quoted context omitted.

Meltdown and Spectre affected ARM and POWER CPUs. Apple's included. PACMAN affected M1. The real problem is speculative execution seemingly.

Performance sorta hinges on it. It could be that the cheaper way the chipmakers deal with it is to phase out the 4core set and push the cores on a die higher, and to do that--incorporate an older core design into dedicated cores for untrusted code. This would also require changes at the OS-makers to tag thread forks for trusted and untrusted behavior. Essentially: instead of shutting down SMT for the entire machine,…

> Performance sorta hinges on it.

Yes. I did not mean to imply the real problem had a simple solution.

Re: Downfall Attacks

#328

Post by dijit »

flerchin wrote: post #313
dijit wrote: post #292

Earlier quoted context omitted.

> Has anyone ever found a speculation attack in the wild? I think the answer might be no. this is known as the Y2K paradox. The Y2K bug had the potential to be very dangerous, but due to a wide-reaching campaign and tonnes of investment in prevention, when the millennium came, it did so with very few issues (though there were still some ); leading many to speculate that the issues were overblown

It's also the anti-tiger rock. Tigers exist, and can kill you, so you'd better hold this rock at all times.

Yeah, but we have practically usable variants of meltdown and spectre.

the only reason its not useful to deploy them is due to a massive amount of herd immunity (and the fact you consume a lot of CPU when trying the attack making it clear - bad combo for an attacker)

Re: Downfall Attacks

#329

Post by yyyk »

peddling-brink wrote: post #236
yyyk wrote: post #196

Earlier quoted context omitted.

The chipmakers don't have an incentive to look too hard for speculation security issues beyond a bit of PR. If they succeed, they lose money and marketshare, while their 'insecure' opponents gain and at most patches later. And in fairness, a lot of these bugs are rather theoretical. Until buyers take these bugs much more seriously, this isn't going to change.

Clouds take these vulns seriously, and have a lot to lose, and have deep wallets. I'd be surprised if this topic didn't come up when large purchases are discussed. Not that there are many alternatives..

Big clouds have the exact same incentive issue - if a customer is really paranoid, the customer can pay the cloud extra and ensure their own exclusive infra. For regular users, the clouds can mitigate a bit at scale (but not care much about this in practice, it's not as important as cheaper faster processors).

Re: Downfall Attacks

#330

Post by bsder »

pnut wrote: post #314
bsder wrote: post #138

Earlier quoted context omitted.

The problem is that nobody wants to admit that the old, stodgy mainframe guys were right 30 years ago and that sharing anything always results in an exfiltration surface. Nobody wants to be the first to take proper steps because they have to either: 1) Partition hardware properly so that users are genuinely isolated. This costs silicon area that nobody wants to pay for. 2) Stop all the speculative bullshit. This thro…

Bad news, 1993 was 30 years ago. Maybe 50+ years ago at this point.

No, 1993 is about right. The mainframe guys were screaming their heads off as these dumbass, insecure, non-ECC x86 processors were eating up more and more computing--before that the mainframe guys kind of dismissed x86 as simply toys.
Post reply on HN