Live data from Hacker News

Downfall Attacks

downfall.page

131–140 of 349 posts

Re: Downfall Attacks

#131

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…

The logic in this comment rubs me the wrong way. You could use the same train of thought to postulate programmers that have made 2 memory safety errors are nefarious instead of simply human.

When billions use something I expect them to find more problems, flaws, and exploits in it than the creator/manufacturer did. The presence of this does nothing to indicate (or refute) any further conclusion about why.

Re: Downfall Attacks

#132

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…

>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 machine-readable specifications for the low-level operations of these chips.

I hope you're not in charge of hiring QA. Bugs are often found by people who AREN'T thinking like the developers whichstart wearing blinders on how they're stuff should work and stop trying stupid things.

Re: Downfall Attacks

#133
post #105
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?

But wait, how is it even considered a processor bug ? You write data inside the registers, yes, other processes can read these registers. It always been like this, and is absolutely normal. It's the responsibility of the operating system to clear the registers if it is switching context.

[deleted]

Re: Downfall Attacks

#134
post #107

At this rate, with all these vulnerabilities and mitigations, we'll rollback CPU performance back at least 10 years.

The only 100% reliable way is to turn off branch prediction completely, and yes, this would make the processors at least 2 times slower, perhaps more.

Too bad that apparently nothing came out of the Mill architecture. My limited understanding is that this architecture would not have such vulnerabilities.

Of course it's possible it would have others :-) but being much simpler, at least conceptually, perhaps it would have less and easier to mitigate. Oh well.

Re: Downfall Attacks

#135
post #89
post #2

This is a huge performance hit - up to 50% it is claimed! 70% of modern intel processors are affected apparently as well.

It is kind of like thinking that it is a huge sale at a store when they say "Up to 70% off". And there are like two things in the whole store which are 70% off. I am always suspicious of "up to" claims.

I always translate such weasel words to their more straightforward equivalent. "Up to 70% off" means for me "Nothing in our store is discounted by more than 70%" :-)

Re: Downfall Attacks

#136

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…

This could be a case of survivorship bias - we don't know how many spectre-like bugs did get patched, because they never made it to the public

Or the problem could be with methodology, and the wrong people are in charge of the right people left, and so the mindset for testing is just wrong.

Also you’re dealing with a company that has been running to stand still for a long time. There’s been a lot of pressure to meet numbers that they simply cannot keep up with. At some point people cheat, unconsciously or consciously, to achieve the impossible.

Re: Downfall Attacks

#137

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…

You are describing a creator bias, there are probably a better name, where you think the ones who created something knows it best. For example, you could create a programming language, a game, or anything, and you think that you know it better then someone who use it for several hours every day. The larger the user base the less likely you are better or know it better then all users.

Re: Downfall Attacks

#138

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…

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 throws performance into rewind and will put chip performance back a decade or two that nobody wants to pay for.

Until people are willing to value security enough to put real money behind it, this will continue ad nauseam.

Re: Downfall Attacks

#139

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…

Re: Downfall Attacks

#140
post #112
post #36

Earlier quoted context omitted.

This is an unreasonable position. Vulnerabilities can be fixed

> This is an unreasonable position. Vulnerabilities can be fixed That's a highly optimistic position, to the point of being almost wishful thinking. The vulnerability being talked about today has been around since 2014 according to the report. Possibly being exploited for unknown number of years since. Sure, maybe we can workaround this one, now. Other similar ones to be published years into the future are also there…

The real problem here is the x86 architecture. We should stop using it. It's too complex, it's full of stuff made for backward compatibility purposes, it has too many instructions that may have unpredictable results, and for that exact reason it's extremely difficult to get things right. Somewhere in the thousands of instructions that it has you will surely find a bug.

We should move forward. Apple did a great job with the M{1,2} processors. Not only they are fantastic in terms of performance and energy usage, but also (to this moment) they don't seem to suffer from these issues. The reason is that the CPU is simpler, and a simpler thing is easy to design right in the first place.

Post reply on HN