Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CacheOut: Leaking Data on Intel CPUs via Cache Evictions

cacheoutattack.com

Post reply on HN
Print view View original

101–110 of 137 posts

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

#101

Post by mantap »

rcthompson wrote: post #72
simias wrote: post #31

Earlier quoted context omitted.

>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 tru…

I wonder how much of Intel's long-term perceived lead over AMD in performance is explained by compromising on these security issues that are only in the past few years being (known to be) exploited.

You have to distinguish between mitigating an issue in software/firmware, and fixing it in hardware. You can't unfab a chip, so the software/firmware mitigation is necessarily crude. The actual performance advantage Intel was getting from "cheating" was most likely small.

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

#103

Post by zelon88 »

jacquesm wrote: post #94
zelon88 wrote: post #91

Earlier quoted context omitted.

What is it that programmers do? They automate complex tasks that take humans considerable effort. If a university can accomplish this task with their funding and no urgent incentive, what is the nation state actor doing with their enormous budget?

The conventional wisdom is that if a nation state wants your data badly enough it is game over. Even an air gap can apparently be bridged if you have the budget and you're patient and smart enough. It's root kits, booters, ransomware, exfiltration and script kiddies that you have to worry about in practice.

It's not what a nation does to it's own supply chain that a nations supply chain has to worry about.

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

#104

Post by floodyberry- »

rurban wrote: post #66

I've pointed this problem out early last year to libsodium, but they chose to ignore it. My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs.

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?

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

#105

Post by empiricus »

mlyle wrote: post #96
ngneer wrote: post #93

Earlier quoted context omitted.

When the market rewards secure design, you can make that complaint. Since the market does not reward secure design, expect investments in security to be commensurate. You cannot have it both ways.

The market is noticing that we're losing a whole lot of performance on Intel to these security-related mitigations, though...

Intel reports record profits again.

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

#106

Post by chaboud »

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)"

That looks conspicuously like the load/store port address aliasing size (look up "4K Aliasing"), which can be used to stall data availability while the conflict is resolved. I'll read up on this particular one, but there's a growing family of vulnerabilities with 12-bit address aliasing in their toolbox.

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

#107

Post by MrBuddyCasino »

cesarb wrote: post #36
Tuna-Fish wrote: post #22

Earlier quoted context omitted.

> 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 mor…

Thanks for the explanation, but I‘m not sure I got why this can happen:

> To prevent the confusing situation where the same physical address has more than one index in the cache

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

#108

Post by wtallis »

BlueTemplar wrote: post #78
cpudestw2020 wrote: post #58

Earlier quoted context omitted.

Can't edit, but obviously the web won't die. But it is going to change a bit over the next few years still; the privacy changes are likely to be a big catalyst for a lot of change...

Any idea if the fundamental incompatibility between GDPR and "cloud" is ever going to come home to roost? (You know, how personal data is supposed to be deleted on request, but the whole idea of "deletion" is pretty hard to properly execute in practice without physically destroying the storage, especially for transistor-based storage like SSDs!)

> especially for transistor-based storage like SSDs!

It's actually much easier to render deleted data unrecoverable on a flash based SSD than a hard drive, if you're willing to use only SSDs that eschew a few very common performance optimizations. So that fits right in with the theme.

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

#109

Post by ngneer »

empiricus wrote: post #105
mlyle wrote: post #96

Earlier quoted context omitted.

The market is noticing that we're losing a whole lot of performance on Intel to these security-related mitigations, though...

Intel reports record profits again.

Thank you. Apparently, the stockholders agree with my assessment.

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

#110

Post by marcan_42 »

MrBuddyCasino wrote: post #107
cesarb wrote: post #36

Earlier quoted context omitted.

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 mor…

Thanks for the explanation, but I‘m not sure I got why this can happen: > To prevent the confusing situation where the same physical address has more than one index in the cache

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.
Post reply on HN