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

81–90 of 137 posts

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

#81

Post by userbinator »

heavyset_go wrote: post #44
baybal2 wrote: post #37

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.

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

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

#82

Post by userbinator »

swebs wrote: post #59
baybal2 wrote: post #37

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.

>Untrusted code execution must go, that's the only way. Ironically, you have to enable third party javascript to even view the page.

The page is perfectly readable with no JS at all.

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

#83

Post by kazinator »

userbinator wrote: post #82
swebs wrote: post #59

Earlier quoted context omitted.

>Untrusted code execution must go, that's the only way. Ironically, you have to enable third party javascript to even view the page.

The page is perfectly readable with no JS at all.

Not "perfectly" at all. The abstract is readable as is the click to the PDF, which is readable. The FAQ list below doesn't open, and the icons which drive the open/close actions appear as "tofu" characters.

However, the data is in all in the document source; the JS just plays with the visibility. I.e. there are no dynamic tricks to populate that.

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

#84

Post by ehvatum »

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…

At the level where large, security-centric organizations make decisions, these instances argue for getting AMD in the door like nothing else that I can recall. So, it's a good time for AMD to have such performant hardware and a process advantage. If it stays this way for a decade, I'll be able to put in a PO for AMD hardware...

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

#85

Post by slovenlyrobot »

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…

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

I don't mean to understate the difficulty of the task, but I've also seen probably tens of repros by now that use intimate knowledge of e.g. the kernel page allocator and known post-boot state of e.g. a firmware image flashed on millions of devices to drastically cut down the search space

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

#86

Post by blackflame »

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.

This might be true in recent history, but Intel's Core architecture had AMD on its heels for several years.

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

#87

Post by eyegor »

cosmiccatnap wrote: post #35
eyegor wrote: post #5

Earlier quoted context omitted.

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

Yes but most enterprise customers have reacted by buying more Intel chips, because the cost of migrating infrastructure is much greater. Once you're invested deep into the omni-path level interconnects and spend 100k+ on cables alone, buying a few extra blades isn't a huge deal. Speaking as someone who has sat in on meetings where we negotiate with vendors for 1ku pricing.

The big migration will happen in about 2-4 years. Typical enterprise schedule is 3-5 year cycles, zen2 launch was 2019.

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

#88

Post by [deleted] »

rodgerd wrote: post #52
_hl_ wrote: post #4

Earlier quoted context omitted.

> AMD is not affected by CacheOut, as AMD does not offer any feature akin to Intel TSX on their current offering of CPUs. It seems to be down to the notoriously buggy TSX (hardware transactional memory) in Intel CPUs.

It's interesting that TSX seems to be one of those holy grails that causes more problems than it solves - trying to implement TSX caused, I believe, huge problems for Sunacle's Rock processor team.

[deleted]

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

#89

Post by jrochkind1 »

ptx wrote: post #62
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…

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