CacheOut: Leaking Data on Intel CPUs via Cache Evictions • Hacker News Board

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#31

Post by simias » Mon, Jan 27, 2020, 9:19 PM UTC

temac wrote: post #20

makomk wrote: post #9

Earlier quoted context omitted.

Mostly, it seems to be a difference in design philosphy - AMD processors prevent speculative reads of data that shouldn't be accessible almost everywhere, whereas Intel ones allow them pretty much everywhere. This particular attack requires TSX which AMD processors don't have, but I don't think it'd work on AMD processors anyway because they're not missing the security check that Intel ones are. If I remember rightly…

It is known since... forever?, that one should not speculate across security boundaries. This was not enough to avoid Spectre, but this was largely enough to avoid TONS of security vulns Intel is also susceptible to. Somebody messed-up big time. Or from a business point of view did they? Intel current problems are manufacturing and the continuously lower power of their "legacy" processor (except due to manufacturing…

>It is known since... forever?, that one should not speculate across security boundaries.

... if you value security over raw performance. Clearly Intel has decided at some point that it was worth playing with fire in order to get ahead in benchmarks. In their defence it seems to have worked reasonably well for them for quite a while.

>The people most annoyed are the users.

I wish, but I wonder how much of that is true. Are most users even aware of these problems? They get patched automatically by OS vendors and then most of the time they won't hear about them anymore. I think the "nobody gets fired for choosing Intel" will probably still prevail for quite some time.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#32

Post by cptskippy » Mon, Jan 27, 2020, 9:21 PM UTC

emn13 wrote: post #8

I mean, you gotta appeciate their efforts to make something so technical approachable by the general population, including gems like this in their Q&A: :-D: What is an operating system? An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface, which can be used by the software running on top of it. Furthermore, the operating system decide…

> An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface

So uh... that's a reference to the IME right? Not the user's installed OS.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#33

Post by scandinavian » Mon, Jan 27, 2020, 9:25 PM UTC

jandrese wrote: post #29

scandinavian wrote: post #27

Earlier quoted context omitted.

>but the instant it's in a rootkit everybody will be able to do it. This makes no sense. If you have the privileges to install a rootkit, there is no need to use any speculative execution exploit.

The first feature of a rootkit is to get root access. A userspace kernel-information leak utility would be very useful for this step.

Okay, we have differing definitions of what a rootkit is it seems.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#34

Post by cosmiccatnap » Mon, Jan 27, 2020, 9:27 PM UTC

jdsully wrote: post #24

loeg wrote: post #18

Earlier quoted context omitted.

"Should" as in, I think the earlier vulnerability was damning enough that people /should/ have disabled TSX entirely. If they have not already, they /should/ now.

TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it off globally doesn't make much sense. Unlike hyperthreading use of TSX can be decided on an app to app basis. As core counts increase spinlocks and other synchronization primitives simply become too expensive. We'll need transactional hardware support eventual…

That's putting alot of faith in the OS and it's ability to sandbox correctly.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#35

Post by cosmiccatnap » Mon, Jan 27, 2020, 9:30 PM UTC

eyegor wrote: post #5

kohtatsu wrote: post #2

Did AMD design their processors with these side channel attacks in mind, or is it a matter of where the security research is focused?

Amd still has almost no server marketshare. This attack specifically leverages tsx, which is an Intel set of transactional extensions to the cpu microcode. Intel has since published microcode updates to enable you to disable tsx.

Not sure you've been keeping up but in 2020 most major server makers have switched or at least offer an epyc varient because the price/performance is better even without Intel's constant security woes

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#36

Post by cesarb » Mon, Jan 27, 2020, 9:31 PM UTC

Tuna-Fish wrote: post #22

jnordwick wrote: post #19

Before people get all nutty as usual: This is another TSX (transactional memory) issue, and you can disable TSX without much of a problem. The attacker basically needs to be running a binary on the machine (not JS in a browser or anything). The leakage is extremely slow, about 225 byte/minute for ASCII text (a 4k page in 18 minutes). I'm not sure if that was an exact recovery either, just a probabilistic one. With no…

> It seems to be able to only be able to control the bottom 12-bits of the address to recover (but I didn't fully get why) 2^12 = 4096, or the x86 page size in bytes.

And as for why the page size is relevant for the L1 cache: Intel (and AMD, and most other modern CPUs) use a VIPT (Virtual Indexed Physical Tagged) L1 cache, where the virtual address (before the page table translation) is used to index the cache (this is faster since it can be done in parallel with the TLB lookup to get the physical address). To prevent the confusing situation where the same physical address has more than one index in the cache, only the bits of the address which do not change between the virtual address and the physical address can be used; these are the bits which correspond to the offset within the page.

(As an aside, this also limits the size of the L1 cache, which is why it hasn't grown much despite the L2 and L3 cache growing a lot; an 8-way set-associative VIPT cache with a 4KiB page size is limited to 32KiB, absent tricks like page coloring. Perhaps this will change if 64-bit ARM servers become popular, since they can only address the largest amount of memory when using a 64KiB page size, and this would make enterprise distributions default to that page size.)

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#37

Post by baybal2 » Mon, Jan 27, 2020, 9:32 PM UTC

Again, I reiterate: it's not humanly possible to make performant, general purpose CPU that is 100% safe from instruction level attacks.

Untrusted code execution must go, that's the only way.

The genie is out of the bottle now. There will be more and more practical instruction level attacks with each year now.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#38

Post by loeg » Mon, Jan 27, 2020, 9:34 PM UTC

jdsully wrote: post #24

loeg wrote: post #18

Earlier quoted context omitted.

"Should" as in, I think the earlier vulnerability was damning enough that people /should/ have disabled TSX entirely. If they have not already, they /should/ now.

TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it off globally doesn't make much sense. Unlike hyperthreading use of TSX can be decided on an app to app basis. As core counts increase spinlocks and other synchronization primitives simply become too expensive. We'll need transactional hardware support eventual…

It is dangerous to treat the security domain as app-to-app instead of whole-machine given the scope of vulnerability. If your TSX workload runs on dedicated machines and/or you're ok with the reduction in kernel defenses, sure, enable it. But the default should be "off."

Scaling workloads does not require transactional memory and certainly doesn't require a vulnerable implementation of it. HTM might be the easiest way to scale a relatively naive algorithm, but the most scalable synchronization is none at all (or vanishingly infrequent) — and that works just fine with conventional locks and atomics (both locked instructions and memory model "atomics" such as release/acquire/seq_cst semantics).

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#39

Post by loeg » Mon, Jan 27, 2020, 9:35 PM UTC

cosmiccatnap wrote: post #34

jdsully wrote: post #24

Earlier quoted context omitted.

TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it off globally doesn't make much sense. Unlike hyperthreading use of TSX can be decided on an app to app basis. As core counts increase spinlocks and other synchronization primitives simply become too expensive. We'll need transactional hardware support eventual…

That's putting alot of faith in the OS and it's ability to sandbox correctly.

Especially when this publication shows that sandboxing correctly isn't possible with TSX.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#40

Post by chmod775 » Mon, Jan 27, 2020, 9:35 PM UTC

cptskippy wrote: post #32

emn13 wrote: post #8

I mean, you gotta appeciate their efforts to make something so technical approachable by the general population, including gems like this in their Q&A: :-D: What is an operating system? An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface, which can be used by the software running on top of it. Furthermore, the operating system decide…

> An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface So uh... that's a reference to the IME right? Not the user's installed OS.

No they're speaking of the (user installed) OS.