10 ms·

Did AMD design their processors with these side channel attacks in mind, or is it a matter of where the security research is focused?

_hl_ 7y ago
> 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.
- rodgerd 7y ago
  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 7y ago
    [deleted]
eyegor 7y ago
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.
- topspin 7y ago
  > 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.
- cosmiccatnap 7y ago
  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
  - eyegor 7y ago
    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.
Symmetry 7y ago
In this case AMD just doesn't support TSX instructions. For previous vulnerabilities with Meltdown I'd guess that AMD just didn't feel they had the engineering resources to do after the fact validation of memory access permissions without architecturally leaking data in some weird corner case. But then along comes Meltdown and it turns out that non-architectural leaks are a thing that can happen and if you try to do after the fact validation you can't prevent them.
makomk 7y ago
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, there were other now-mitigated exploits for this line fill buffer leak that didn't require TSX. (The one exception is also interesting. AMD processors allow speculative reads past the end of x86 segments and past BOUND instructions, which of course no-one uses these days. This suggests there may have been a deliberate decision to block them in the more important cases.)
- temac 7y ago
  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.
loeg 7y ago
It is specific to Intel TSX, which should already be disabled due to earlier published MDS vulnerabilities in the same space.
- jdsully 7y ago
  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.
  - loeg 7y ago
    "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.
    - jdsully 7y ago
      TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it off globally doesn't make much sense. Unlike hyperthreading use of TSX can be decided on an app to app basis. As core counts increase spinlocks and other synchronization primitives simply become too expensive. We'll need transactional hardware support eventually.
      - cosmiccatnap 7y ago
        That's putting alot of faith in the OS and it's ability to sandbox correctly.
        loeg 7y ago
        Especially when this publication shows that sandboxing correctly isn't possible with TSX.
      - loeg 7y ago

_hl_ 7y ago

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

rodgerd 7y ago
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 7y ago
  [deleted]

eyegor 7y ago

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.

topspin 7y ago
> 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.
cosmiccatnap 7y ago
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
- eyegor 7y ago
  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.

Symmetry 7y ago

In this case AMD just doesn't support TSX instructions. For previous vulnerabilities with Meltdown I'd guess that AMD just didn't feel they had the engineering resources to do after the fact validation of memory access permissions without architecturally leaking data in some weird corner case. But then along comes Meltdown and it turns out that non-architectural leaks are a thing that can happen and if you try to do after the fact validation you can't prevent them.

makomk 7y ago

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, there were other now-mitigated exploits for this line fill buffer leak that didn't require TSX. (The one exception is also interesting. AMD processors allow speculative reads past the end of x86 segments and past BOUND instructions, which of course no-one uses these days. This suggests there may have been a deliberate decision to block them in the more important cases.)

temac 7y ago
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.

loeg 7y ago

It is specific to Intel TSX, which should already be disabled due to earlier published MDS vulnerabilities in the same space.

jdsully 7y ago
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.
- loeg 7y ago
  "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.
  - jdsully 7y ago
    TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it off globally doesn't make much sense. Unlike hyperthreading use of TSX can be decided on an app to app basis. As core counts increase spinlocks and other synchronization primitives simply become too expensive. We'll need transactional hardware support eventually.
    - cosmiccatnap 7y ago
      That's putting alot of faith in the OS and it's ability to sandbox correctly.
      - loeg 7y ago
        Especially when this publication shows that sandboxing correctly isn't possible with TSX.
    - loeg 7y ago