Tl;dr: Another Intel TSX async abort side channel.
See also Intel's advisory: https://software.intel.com/security-software-guidance/softwa... (cite 23 in the CacheOut PDF).
CacheOut: Leaking Data on Intel CPUs via Cache Evictions
11–20 of 137 posts
Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions
#12Did AMD design their processors with these side channel attacks in mind, or is it a matter of where the security research is focused?
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.
> Amd still has almost no server marketshare.
Yet another Intel exclusive side channel vulnerability might help change that. This side channel stuff is terrible for cloud operators. Every time they have to adopt another layer of mitigation some fraction of their capacity disappears in a puff of shame and excuses.
Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions
#13Is disabling Hyper-threading a viable work-around in this case?
Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions
#14Is disabling Hyper-threading a viable work-around in this case?
"CacheOut is effective even in the non HyperThreaded scenario, where the victim always runs sequentially to the attacker."
Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions
#15Did AMD design their processors with these side channel attacks in mind, or is it a matter of where the security research is focused?
It is specific to Intel TSX, which should already be disabled due to earlier published MDS vulnerabilities in the same space.
Only the implicit TSX has been disabled. You can still use xbegin/xend/xabort.
They had an additional mode that would transparently convert many spinlocks into transactions without code changes - that is now gone.
Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions
#16[deleted]
Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions
#17Intel got cash in, but we've got cacheout.
Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions
#18Earlier quoted context omitted.
It is specific to Intel TSX, which should already be disabled due to earlier published MDS vulnerabilities in the same space.
Only the implicit TSX has been disabled. You can still use xbegin/xend/xabort. They had an additional mode that would transparently convert many spinlocks into transactions without code changes - that is now gone.
"Should" as in, I think the earlier vulnerability was damning enough that people /should/ have disabled TSX entirely. If they have not already, they /should/ now.
Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions
#19Before 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 noise reduction to enhance recovery, they said it took twice as long - so about 113 byte/minute.
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) and require the process to be either reading or writing the data to get it into L1 cache somehow, so just sitting in RAM isn't good enough.
attacker still needs to figure out an address (even with ASLR there is still a lot of guessing, and if you have really sensitive data, just move it every second until you wipe it).
Interesting, but kind of a non-issue.
Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions
#20Did AMD design their processors with these side channel attacks in mind, or is it a matter of where the security research is focused?
Mostly, it seems to be a difference in design philosphy - AMD processors prevent speculative reads of data that shouldn't be accessible almost everywhere, whereas Intel ones allow them pretty much everywhere. This particular attack requires TSX which AMD processors don't have, but I don't think it'd work on AMD processors anyway because they're not missing the security check that Intel ones are. If I remember rightly…
It is known since... forever?, that one should not speculate across security boundaries. This was not enough to avoid Spectre, but this was largely enough to avoid TONS of security vulns Intel is also susceptible to.
Somebody messed-up big time. Or from a business point of view did they? Intel current problems are manufacturing and the continuously lower power of their "legacy" processor (except due to manufacturing problems, this "legacy" is still mostly the current one) makes it so that people are buying more. Of course there is AMD back in the game, but the market demand is large enough; plus AMD would have been there anyway, and, in the fiction that Intel did take good parts of the perf hit upfront instead of the secu vulns, as competitive as in the current situation.
The people most annoyed are the users. Intel got away by pretending this was not really defects in their product but only new SW tricks that they will help defend against, and their clients just let them say that without much complaint (well, I guess big ones got some rebate...) but security researchers and/or processor designers know very well this is bullshit (see the vulns papers and FAQ) and that they simply fucked-up big time on Meltdown, MDS, etc. I don't care that a few other vendors did some of the same mistakes: they are still mistakes and design flaws, and not even something new.
Pretty much the only new shinny thing in this stream of vulns was Spectre and the few variants that appeared quite early on (but NOT Meltdown&co). The rest are design flaws that comes from the "oh not a big deal to leak that potentially privileged data, we will drop anything and trap before any derivative can go out anyway" mentality. Yeah, no, I'm sorry but the funding paper about speculation already told to not do that :/ Either they did not do their homework, or they voluntarily chose to violate the rule.