Hacker News Reader

Comment by uniqueuid | Hacker News Reader

Oh no, not again.

If there are enough of these attacks that don't involve ARM (I know some do), then I see a bright future for ARM servers.

[edit]: Curious to see if Zen3 is also affected - if not, that would be great news.

View on HN

Check the list from the Linux kernel patches:

``` + VULNBL_INTEL_STEPPINGS(SKYLAKE_L, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(SKYLAKE_X, X86_STEPPING_ANY, MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(SKYLAKE, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(KABYLAKE_L, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(KABYLAKE, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(CANNONLAKE_L, X86_STEPPING_ANY, RETBLEED), + VULNBL_INTEL_STEPPINGS(ICELAKE_L, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(COMETLAKE, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(LAKEFIELD, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(ROCKETLAKE, X86_STEPPING_ANY, MMIO | RETBLEED),

+ + VULNBL_AMD(0x15, RETBLEED), + VULNBL_AMD(0x16, RETBLEED), + VULNBL_AMD(0x17, RETBLEED), + VULNBL_HYGON(0x18, RETBLEED), ```

(I believe that zen3 is not affected)

Via: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

In general, these attacks leverage the microarchitectural details of processors that implement speculative execution (which is nearly any modern processor). ARM processors can differ in their microarchitecture, so this particular exploit may or may not apply to them. It's not necessarily an "ARM" versus "x86" thing. (This specific exploit applies to a mitigation, retpoline, implemented in Linux. It appears that at least some ARM processors are vulnerable to the speculation attacks that make retpolines necessary in the first place: https://www.phoronix.com/scan.php?page=news_item&px=Google-L...)

Doesn't change the practical effect of being slightly safer than the neighbor.

The researchers have tried their method against AMD Zen 3, Intel Alder Lake and Coffee Lake Refresh (a.k.a. 9th Generation Core) and it did not work against those.

Intel Coffee Lake (a.k.a. 8th Generation Core) or older and AMD Zen 2 or older are vulnerable.

Where does it say that older (Intel 5th generation and earlier) versions are affected?

They have not tested CPUs older than AMD Zen 1, but based on the similar branch predictors they suppose that Bulldozer derivatives and Jaguar/Puma might also be vulnerable.

Similarly, on Intel they have not tested CPUs older than Kaby Lake, but due to the similar branch predictors they suppose that Skylake, Broadwell and Haswell might also be vulnerable.

Older CPUs than that might not have indirect branch predictors or the indirect branch predictors might be too simple, so this attack method might not be applicable.

I'm probably doing it wrong, but I'm getting SIGILL on Haswell for ret_bti and break_kaslr from the demo: https://github.com/comsec-group/retbleed

Though it seems like the code is not portable (?) between CPU microarchitectures.

Since the attack method depends heavily on details of the indirect branch predictor obtained through reverse engineering, it is very likely that the code must be adapted to each different microarchitecture.

The demo code probably also works in Skylake, which is almost identical to Kaby Lake, but for Haswell and Broadwell it probably must be modified, even if it is expected that this should be possible.

IIRC there are some stepping on Coffee Lake Refresh to support additional mitigation. I wonder what exactly chip used.

Would be interested to know too, the PDF (page 12, https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf) shows "Intel Core i9-9900K Coffee Lake Ref" but does not list the stepping.

Per https://www.intel.com/content/www/us/en/developer/topic-tech... (click 2022 tab), there's C and D steppings of 9900k. Note Intel recommends some software mitgations for both steppings.

(It looks like the kernel decided it was too confusing to handle different steppings and is applying the mitigation to all: https://lore.kernel.org/lkml/20220712183239.024698478@linuxf... so maybe doesn't matter either way.)

Doesn't appear to be, additionally Windows deployments are not affected.

Per Intel - "Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users."

It appears to be an attack specifically on the retpoline approach the Linux used to prevent the original specter attacks. Given it appears that Linux is the only OS that took that approach they’re the only one vulnerable? (The article explicitly calls out Linus ignoring warnings about this possibility)

Linux claimed it was not practical. Is this attack actually practical? Are 200-3kb/s sufficient for a realistic attack?

> Are 200-3kb/s sufficient for a realistic attack?

Yes.

So how many seconds would it take to leak your password at that rate?

Per the article 5-7 minutes for the root hash on the effected AMD systems?

I'm guessing that's also not doing any kind of actual targeted traversal because if you can just do a heap walk you don't need anywhere near that amount of data.

First dialup connections were 1200bps. Earlier adhoc connections were lower.

Someone should create an index of "Linus said this attack was impractical/ unimportant". I can think of a number of great examples off the top of my head.

Reply on news.ycombinator.com