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

141–150 of 349 posts

Re: Downfall Attacks

#141

Post by BeeOnRope »

infinityio wrote: post #123
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…

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

I considered this, but we have pretty good evidence that the chipmakers have not been busily secretly patching Spectre attacks:

1) Microcode updates are visible and Spectre fixes are hard to hide: most have performance impacts and most require coordination from the kernel to enable or make effective (which are visible for Linux). There have been a large number of microcode changes tied to published attacks and corresponding fixes, but no corresponding "mystery" updates and hidden kernel fixes to my knowledge which have a similar shape to Spectre fixes.

It's possible they could wait to try to bundle these fixes into a microcode update that arrives for another reason, but the performance impacts and kernel-side changes are harder to hide.

2) If this were the case, we'd expect independent researches to be at least in part re-discovering these attacks, rather than finding completely new ones. This would lead to a case where an attack was already resolved in a release microcode version. To my knowledge this hasn't really happened.

Re: Downfall Attacks

#142

Post by duped »

rvnx wrote: post #105
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?

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.

> But wait, how is it even considered a processor bug ?

These side channel attacks allow an attacker to read registers from other processes before any context switching has occurred, or independently of any context switching (even if the OS has been written to correctly clear state).

Re: Downfall Attacks

#143

Post by BeeOnRope »

hinkley wrote: post #136
infinityio wrote: post #123

Earlier quoted context omitted.

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.

> Also you’re dealing with a company that has been running to stand still for a long time

I'm not just talking about Intel, but also Arm and AMD. As far as I know none of these has obviously been making proactive Spectre fixes.

Re: Downfall Attacks

#144

Post by BeeOnRope »

zamadatix wrote: post #131
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…

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.

I think the comparison between CPU and software exploits holds at a very high level, but in the case of software the gap between internal and external researches seems lower. Much software is open-source, in which case the play field is almost level and even closed source software is available in assembly which exposes the entire attack surface in a reasonably consumable form.

Software reverse-engineering is a hugely popular, fairly accessible field with good tools. Hardware not so much.

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

To be very clear none of these errors have been found by billions of random users but by a few interested third parties: many of them working as students with microscopic funding levels and no apparent inside information.

I'm not actually suggesting that the nefarious explanation holds: I'm genuinely curious.

Re: Downfall Attacks

#145

Post by alerighi »

SoftTalker wrote: post #25
stalfosknight wrote: post #10

I'm getting annoyed with all of these yawning security holes in Intel's CPUs. I'm tempted to replace my Intel MacBook Pro with an Apple Silicon model sooner than I normally would.

I'm not sure what evidence there is to think that Apple's chips are any better. And that's not really a dig at Apple; these are just very complicated devices and especially with the optimizations that CPUs need to make to run today's software with acceptable performance, it can become very hard to foresee all possible attacks and vulnerabilities.

x86 architecture is now proven to be a minefield. It has too many instructions, being a CISC instruction set (something that was obsolete in the 90s but was keept for backward compatibility with older software). This means that to make efficient CPU the manufacturer has to do a ton of optimizations. These optimizations have resulted in most of the bugs we have seen.

Contrary ARM or other RISC instruction set are more simple. Being more simple they rely on compilers being more smart to generate optimized programs (something we have to this day). For this processors are more simple and straight forward, they don't need all the complexity of an x86 CPU. For this reason they are also more efficient since they don't waste resources doing useless operations.

Of course vulnerabilities can be everywhere (there were a few also on M1, tough not as impressive like these one, they were mostly stuff nearly impossible to exploit|). But recent times proved that particularly on x86 chips this is a real issue.

Re: Downfall Attacks

#146

Post by hinkley »

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…

This seems like a job for Arm or RISC-V or ???

Sacrifice IPC/core to reduce gates per core, stuff more cores into a square centimeter, pin processes to cores or groups of cores, keep thread preemption cheap, but let thread migration take as long as it takes.

Arm already has asymmetric multiprocessing, which I feel like is halfway there. Or maybe a third. Fifteen years ago asynchrony primitives weren’t what they are today. I think there’s more flexibility to design a core around current or emerging primitives instead of the old ways. And then there are kernel primitives like io_uring meant to reduce system call overhead, amortizing over multiple calls. If you split the difference, you could afford to allow individual calls to get several times more expensive, while juggling five or ten at once for the cost of two.

Re: Downfall Attacks

#147

Post by BeeOnRope »

hackermatic wrote: post #125
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…

A fundamental problem is that the attack surface is so, so huge. Even if their security researchers are doing blue-sky research on both very small and very broad areas of processor functionality, they're going to miss a lot. And in line with that and >Maybe they _did_ and are well aware of all these attacks but to save face and performance hits they simply hold on to them hoping nobody makes them public? ... maybe th…

> A fundamental problem is that the attack surface is so, so huge. Even if their security researchers are doing blue-sky research on both very small and very broad areas of processor functionality, they're going to miss a lot.

Sure. If they had patched a bunch of Spectre vulnerabilities and independent researchers had discovered a few more that would be one thing, but as far as I can tell they have patched _zero_ while independent researches have found many and it has been years since the initial attack. Many of these follow very similar patterns and "in what cases is protected data exposed via speculative execution" is something that an architect or engineer could definitely assess.

Re: Downfall Attacks

#148

Post by kzrdude »

See this LWN story: https://lwn.net/Articles/940783/

on Linux, any cpus that don't have updated microcode will have AVX completely disabled as a mitigation for this issue. That's rather harsh if you ask me and would be very noticeable. Now I'm interested in finding out if I can get updated microcode..

Re: Downfall Attacks

#150

Post by palcu »

bironran wrote: post #115

Worth to note that GCP has this patched ( https://cloud.google.com/support/bulletins#gcp-2023-024 )

My adjacent teams in London who work in SRE on Google Cloud (GCE) got some well deserved doughnuts today for rolling out the patches on time.
Post reply on HN