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

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

#131

Post by heavyset_go » Tue, Jan 28, 2020, 7:30 PM UTC

userbinator wrote: post #81

heavyset_go wrote: post #44

Earlier quoted context omitted.

> Untrusted code execution must go, that's the only way. This is how you get corporate rule over what can and can't run on machines you own. Safer architectures can be developed, without handing over control to a third party.

This is how you get corporate rule over what can and can't run on machines you own. He isn't necessarily talking about the "untrusted by corporates" situation, maybe just "untrusted by the user". (Personal pet peeve about "trusted" and "untrusted" --- never neglecting to mention the by who!? )

Every consumer-facing trusted computing platform only allows keys from corporate entities, and usually only software signed with approved keys from said entities are allowed to run.

I can't get behind trusted computing until there is a strong movement and culture behind allowing user freedom on trusted computing platforms. As it stands, that isn't the case at all. Just look at the iPhone and Notarization on the Mac.

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

#132

Post by floodyberry- » Tue, Jan 28, 2020, 7:35 PM UTC

rurban wrote: post #121

floodyberry- wrote: post #104

Earlier quoted context omitted.

Which would be more difficult, reading the secret at some point before the memory was cleared, or reading it _after_ the memory was cleared, but _before_ the cache was overwritten?

The secrets stay in the cache much longer, and are rarely evicted to the heap at all.

Cryptographic operations can take hundreds of thousands of cycles during which the values can be freely read. The cache will stay stale after the values have been cleared for _longer_ than that?

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

#133

Post by shakna » Wed, Jan 29, 2020, 12:02 AM UTC

rurban wrote: post #120

shakna wrote: post #99

Earlier quoted context omitted.

> I've pointed this problem out early last year to libsodium, but they chose to ignore it. I'm guessing you're referencing this [0]. libsodium's response that your suggestion wasn't enough seems reasonable, as does their response: > `sodium_memzero` should be considered as best-effort, with reasonable tradeoffs. The documentation for memzero [1] doesn't read like it works 100% of the time, no matter what. It reads li…

The tradeoff they are talking about is leaving secrets in the cache, because mb(lb) is slow. This is not acceptable for security, only for performance. That time they had no idea about the upcoming cache exploits, they were only apparent to me. So who was right?

> That time they had no idea about the upcoming cache exploits, they were only apparent to me. So who was right?

I don't see anything that suggests you did have an idea about "upcoming cache exploits", so I'm afraid I can't say that you were.

I saw you mentioning something that would help, but was nowhere near enough, to deal with Spectre, which was then dealt with by microcode, kernels and every other part of the software stack, making attacking libsodium with Spectre something that might not even be possible.

> The tradeoff they are talking about is leaving secrets in the cache, because mb(lb) is slow. This is not acceptable for security, only for performance.

Not entirely. The main reason is this one:

> SPECTRE-like attacks can be conducted during all the time the secret is present, prior to zeroing. The required preconditions and the time window during which a full memory barrier could help, seem to be negligible compared to the actual lifetime of the secret.

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

#134

Post by rurban » Wed, Jan 29, 2020, 8:27 AM UTC

floodyberry- wrote: post #132

rurban wrote: post #121

Earlier quoted context omitted.

The secrets stay in the cache much longer, and are rarely evicted to the heap at all.

Cryptographic operations can take hundreds of thousands of cycles during which the values can be freely read. The cache will stay stale after the values have been cleared for _longer_ than that?

At least one of the 3 caches will stay much longer, yes. Esp. the L3. Throwing a tantrum because of 50 cycles for the mb is laughable. They should call it fast crypto, but not secure crypto.

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

#135

Post by avianes » Wed, Jan 29, 2020, 12:34 PM UTC

ga-vu wrote: post #68

This appears to be one of the four ZombieLoad/RIDL variations, rather than a new attack: https://zombieloadattack.com/

Yes, this is a RIDL variant called "L1D Eviction Sampling". Bolt the RIDL paper (Addendum 2 B [1]) and the CacheOut paper refer to the CVE-2020-0549: "L1D Eviction Sampling (L1Des) Leakage".

But the CacheOut paper describes how to use it in practice and why the intel fix is not sufficient.

[1]: https://mdsattacks.com/files/ridl.pdf#page=20

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

#136

Post by cptskippy » Wed, Jan 29, 2020, 7:45 PM UTC

chmod775 wrote: post #40

cptskippy wrote: post #32

Earlier quoted context omitted.

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

I was kind of joking and it's also not explicitly stated, that's just the assumption the reader makes.

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

#137

Post by Tuna-Fish » Sat, Feb 01, 2020, 10:08 AM UTC

MrBuddyCasino wrote: post #117

marcan_42 wrote: post #110

Earlier quoted context omitted.

You can have several virtual addresses mapped to the same physical address. However, if you use bits that are not 1:1 mapped between those two to index into your cache, then you might end up with one virtual address getting cached in one place in L1, and the other getting cached in another place in L1. That would be bad, because you'd have two potentially inconsistent caches of the same memory.

> You can have several virtual addresses mapped to the same physical address. Ah yes, of course. Is this something that actually happens (e.g. because of processes sharing memory, OS hands out different virtual addresses pointing to the same physical memory) or theoretical in nature?

It does happen, and not just for two different processes.

For example, a common trick to implement an efficient circular list for objects of varying size is to map the same physical addresses twice in adjacent locations. Then you can just use a pointer to the start of each object and have no special handling for the case where an object straddles the end of the allocated area.