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

111–120 of 137 posts

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

#111

Post by mlyle »

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.

This doesn't mean that Intel hasn't been affected negatively by the resurgence of AMD in the processor business. AMD is taking several billion dollars of revenue, and every dollar of that costs Intel much more than $1. A noticeable part of AMD's newfound competitiveness comes from the various performance taxes that Intel has had to pay for speculative execution mitigation.

It's worth noting, too, that Intel has diversified-- the processor business is only one very important business to Intel.

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

#113

Post by mtgx »

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.

Yes, and the point is how do we define "badly enough".

Badly enough as in they can ever do it a few times a year against a few high-value targets, or badly enough that they can do it to "only" a few tens of millions a year?

Even end-to-end encrypted communications can be bypassed if the government wants them "badly enough". But the point is that with E2E encryption, they can no longer tap into and data mine the conversions of billions in real-time to fish for crimes.

Just like when fighting malware creators, the point of security is to keep raising the standards and the difficulty for the malicious actors.

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

#114

Post by catalogia »

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

Is simply unlinking a file in the FS not sufficient for GDPR compliance?

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

#115

Post by ec109685 »

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…

The paper talks about how in a VM environment, this attack allows reading the hypervisor’s memory, and that public clouds put in mitigations based on the early disclosure to them.

That feels like a big issue.

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

#116

Post by wizzwizz4 »

catalogia wrote: post #114
BlueTemplar wrote: post #78

Earlier quoted context omitted.

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

Is simply unlinking a file in the FS not sufficient for GDPR compliance?

It's supposed to be erased, not put in a pile of “things to write over at a later date”.

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

#117

Post by MrBuddyCasino »

marcan_42 wrote: post #110
MrBuddyCasino wrote: post #107

Earlier quoted context omitted.

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.

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

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

#118

Post by IshKebab »

userbinator wrote: post #80
jandrese wrote: post #21

Earlier quoted context omitted.

That's a lot of work, but the instant it's in a rootkit everybody will be able to do it. 113 bytes is extracting an AES key from memory in about a minute. It's only really hard and messy for the first guy who implements it, after that it is much easier, albeit still fairly messy. I'm not saying we need to panic, but it's more than a "non-issue".

113 bytes is extracting an AES key from memory in about a minute. How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else? That's what really irritates me about all these side-channels that have been found ever since the first Spectre/Meltdown --- they all demon…

History has repeatedly shown that "infeasible" attacks are really just difficult.

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

#119

Post by gdy »

jrochkind1 wrote: post #89
ptx wrote: post #62

Earlier quoted context omitted.

"In their defence"? The fact that things worked well for the perpetrator (until they were caught) at the expense of the victim isn't an argument usually brought up by the defence.

It is when the only "court" is how much money you can make.

And you are accused of being stupid.

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

#120

Post by rurban »

shakna wrote: post #99
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.

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