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

91–100 of 137 posts

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

#91

Post by zelon88 »

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…

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?

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

#92

Post by tomThom »

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…

"all nutty as usual"

Nice that you get away with it. I assume you're being paid?

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

#93

Post by ngneer »

guug wrote: post #76
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 "nutty"ness comes from people getting frustrated with intel fucking up the security of yet another feature they promised, and intel's overall poor security record. Luckily there are other vendors who seem to know what they're doing: We just received our first batch of non-intel servers at work and have no intention of returning to intel for the foreseeable future. What they offer is simply not worth the risk. I e…

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.

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

#94

Post by jacquesm »

zelon88 wrote: post #91
userbinator wrote: post #80

Earlier quoted context omitted.

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…

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.

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

#95

Post by guug »

ngneer wrote: post #93
guug wrote: post #76

Earlier quoted context omitted.

The "nutty"ness comes from people getting frustrated with intel fucking up the security of yet another feature they promised, and intel's overall poor security record. Luckily there are other vendors who seem to know what they're doing: We just received our first batch of non-intel servers at work and have no intention of returning to intel for the foreseeable future. What they offer is simply not worth the risk. I e…

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.

Not a complaint but merely stating the obvious.

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

#96

Post by mlyle »

ngneer wrote: post #93
guug wrote: post #76

Earlier quoted context omitted.

The "nutty"ness comes from people getting frustrated with intel fucking up the security of yet another feature they promised, and intel's overall poor security record. Luckily there are other vendors who seem to know what they're doing: We just received our first batch of non-intel servers at work and have no intention of returning to intel for the foreseeable future. What they offer is simply not worth the risk. I e…

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

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

#97

Post by [deleted] »

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.

[deleted]

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

#99

Post by shakna »

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 like there are tradeoffs involved.

> My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs.

Your memset_s also doesn't work on big endian, whilst "the so-called 'secure' libs" often do.

I'm fine with self-promotion, but don't disparage efforts that have a much larger surface that they deal with, simply because you disagree with the tradeoff they find acceptable. A one-liner isn't enough for that conversation.

[0] https://github.com/jedisct1/libsodium/issues/802

[1] https://download.libsodium.org/doc/memory_management#zeroing...

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

#100

Post by ghettoimp »

sitkack wrote: post #79
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…

Does this mean we could see 16x larger L1?

All of hardware is tradeoffs.

A huge L1 would be slower to access. You might end up slowing down all memory accesses by a cycle (or more) just for accessing the large cache. You also have to find some place to put the thing in your floorplan, and route everything else around it. This may result in timing challenges in other parts of the chip, which might require additional delay to resolve.

A huge L1 would take up more space. This would increase area, reduce yield, and increase cost. Since in a multi-core chip each core has its own L1, you will have to pay this cost multiple times. Also, L2 caches are typically inclusive, so you would potentially need a much larger L2 to be able to accommodate all the extra information in these L1s.

These tradeoffs have to be studied with simulated experiments to make the right call. For programs with huge working set, maybe the added latency pays for itself because you have have fewer cache misses. For programs with good locality, maybe you end up losing performance. Maybe you save power by reducing misses, or maybe you waste more power because the cache is using more power. Maybe it's an insignificant area increase, or maybe it completely blows up your budget.

Post reply on HN