7 ms·

"AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker

"AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected." - http://www.zdnet.com/article/security-flaws-affect-every-intel-chip-since-1995-arm-processors-vulnerable/ http://www.zdnet.com/article/security-flaws-affect-every-int... * Edit: From https://meltdownattack.com/ https://meltdownattack.com/ Which systems are affected by Meltdown? "Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown. Which systems are affected by Spectre? Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."

mtgx 9y ago
"Intel suffers a Meltdown" should be an apt headline for tomorrow's headlines.
MikeHolman 9y ago
Looks like everyone is vulnerable to arbitrary user memory reads, while Intel and ARM are vulnerable to arbitrary kernel memory reads as well.
- mrmondo 9y ago
  Thanks for clarifying Mike, should be interesting to see how this actually pans out.
  - comex 9y ago
    Not just user memory reads. AMD CPUs won’t speculate loads from userland code directly to kernel memory, ignoring privilege checks (“Meltdown”). But they are still subject to the “Spectre” attack, which can disclose kernel memory by taking advantage of certain code patterns (which normally would be harmless) in kernel code.
    - tankenmate 9y ago
      But that means the root user or someone with root effective privs or CAP_* to load programs into a kernel interpreter or kernel JIT. If you've given someone permission to do this from a user process you've probably opened up to more mundane issues. I suspect this is why AMD says the issue is near zero, if you've given away the keys to the kernel you're already in trouble. AMD's ASID blocks the issues for VM guests (and root users on VM guests).
      - Pyxl101 9y ago
        Do you need root or comparable privileges to take advantage of BPF? I did not think that was the case. My understanding was that BPF code executes within the kernel. BPF is employed by the `bpf()` syscall for socket packet filtering, as well as by `seccomp` itself for its syscall filtering. Is this threat vector not available to untrusted processes?
        language 9y ago
        iirc I think that the BPF JIT is disabled by default? Your kernel might be compiled with `CONFIG_BPF_JIT`, but I think the sysctl knob (`bpf_jit_enable`) is set to 0 by default. Also there's a sysctl for unprivileged BPF called `unprivileged_bpf_disabled`. On my system it seems to default to 0. https://elixir.free-electrons.com/linux/v4.15-rc6/source/kernel/bpf/syscall.c#L1690 https://elixir.free-electrons.com/linux/v4.15-rc6/source/ker...
      - comex 9y ago
        For variant 1, a kernel JIT is definitely helpful, which is why the Project Zero PoC used it, but it's not required. For variant 2, Project Zero used the eBPF interpreter as a gadget, a fake branch destination, without having to actually create an eBPF program or use the normal userland-facing eBPF APIs at all. And they only chose it as the least "annoying" option (see quote below). edit: I'm not sure how ASID support would mitigate either of those variants, though there may be something I'm not thinking of. (It would help with variant 3, but that's the variant AMD wasn't vulnerable to in the first place.) quote: > At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.
buryat 9y ago
That article links a commit [1] that contradicts this statement > AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. And Axios [2] that Zdnet quotes gave a comment from AMD: > "To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time." And a comment from ARM: > Please note that our Cortex-M processors, which are pervasive in low-power, connected IoT devices, are not impacted. [1] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=694d99d40972f12e59a3696effee8a376b79d7c8 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/... [2] https://www.axios.com/how-the-giants-of-tech-are-dealing-with-a-massive-chip-vulnerability-2522206367.html https://www.axios.com/how-the-giants-of-tech-are-dealing-wit...
- deleted 9y ago
  [deleted]
- ethbro 9y ago
  My read is that vulnerable processors generally have to: 1. Have out of order execution 2. Have aggressive speculative memory load / caching behavior 3. Be able to speculatively cache memory not owned by the current process (either kernel or otherwise) 4. Have deterministic ways of triggering a speculative load / read to the same memory location 2 is probably the saving grace in ARM / low power land, given they don't have the power budget to trade speculative loads for performance (in the event they're even out of order in the first place). Caveat: I'm drinking pretty strong Belgian beer while reading through these papers.
- Pyxl101 9y ago
  How does that pertain to the vulnerabilities that involve eBPF? My understanding is that eBPF code executes within the kernel, and so would run at the same privilege level.
ece 9y ago
Another good article: https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl... "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
- mrmondo 9y ago
  Yeah that's a good one, hope they keep it updated / link to new info / posts as they come out.
- michaelermer 9y ago
  Google's post is newer and has more insights, the registry article is now outdated.
  - ece 9y ago
    The register has more details. Worth a read.
    - olliej 9y ago
      the google site has the actual white papers detailing the attacks.
      - ece 9y ago
        The register has the tweet with actual code for spectre, and more details from the manufacturers and potential fixes. Seriosuly? They're both worth a read.
        ece 9y ago
        @lern_too_spel The AMD engineer could be right if talking about Ryzen, and/or he isn't mentioning user-user and user-kernel boundaries. AMD isn't affected in nearly the same way as Intel/ARM are: https://twitter.com/ryanshrout/status/948683677244018689 https://twitter.com/ryanshrout/status/948683677244018689

mtgx 9y ago

"Intel suffers a Meltdown" should be an apt headline for tomorrow's headlines.

MikeHolman 9y ago

Looks like everyone is vulnerable to arbitrary user memory reads, while Intel and ARM are vulnerable to arbitrary kernel memory reads as well.

mrmondo 9y ago
Thanks for clarifying Mike, should be interesting to see how this actually pans out.
- comex 9y ago
  Not just user memory reads. AMD CPUs won’t speculate loads from userland code directly to kernel memory, ignoring privilege checks (“Meltdown”). But they are still subject to the “Spectre” attack, which can disclose kernel memory by taking advantage of certain code patterns (which normally would be harmless) in kernel code.
  - tankenmate 9y ago
    But that means the root user or someone with root effective privs or CAP_* to load programs into a kernel interpreter or kernel JIT. If you've given someone permission to do this from a user process you've probably opened up to more mundane issues. I suspect this is why AMD says the issue is near zero, if you've given away the keys to the kernel you're already in trouble. AMD's ASID blocks the issues for VM guests (and root users on VM guests).
    - Pyxl101 9y ago
      Do you need root or comparable privileges to take advantage of BPF? I did not think that was the case. My understanding was that BPF code executes within the kernel. BPF is employed by the `bpf()` syscall for socket packet filtering, as well as by `seccomp` itself for its syscall filtering. Is this threat vector not available to untrusted processes?
      - language 9y ago
        iirc I think that the BPF JIT is disabled by default? Your kernel might be compiled with `CONFIG_BPF_JIT`, but I think the sysctl knob (`bpf_jit_enable`) is set to 0 by default. Also there's a sysctl for unprivileged BPF called `unprivileged_bpf_disabled`. On my system it seems to default to 0. https://elixir.free-electrons.com/linux/v4.15-rc6/source/kernel/bpf/syscall.c#L1690 https://elixir.free-electrons.com/linux/v4.15-rc6/source/ker...
    - comex 9y ago
      For variant 1, a kernel JIT is definitely helpful, which is why the Project Zero PoC used it, but it's not required. For variant 2, Project Zero used the eBPF interpreter as a gadget, a fake branch destination, without having to actually create an eBPF program or use the normal userland-facing eBPF APIs at all. And they only chose it as the least "annoying" option (see quote below). edit: I'm not sure how ASID support would mitigate either of those variants, though there may be something I'm not thinking of. (It would help with variant 3, but that's the variant AMD wasn't vulnerable to in the first place.) quote: > At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.

buryat 9y ago

That article links a commit [1] that contradicts this statement > AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. And Axios [2] that Zdnet quotes gave a comment from AMD: > "To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time." And a comment from ARM: > Please note that our Cortex-M processors, which are pervasive in low-power, connected IoT devices, are not impacted. [1] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=694d99d40972f12e59a3696effee8a376b79d7c8 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/... [2] https://www.axios.com/how-the-giants-of-tech-are-dealing-with-a-massive-chip-vulnerability-2522206367.html https://www.axios.com/how-the-giants-of-tech-are-dealing-wit...

deleted 9y ago
[deleted]
ethbro 9y ago
My read is that vulnerable processors generally have to: 1. Have out of order execution 2. Have aggressive speculative memory load / caching behavior 3. Be able to speculatively cache memory not owned by the current process (either kernel or otherwise) 4. Have deterministic ways of triggering a speculative load / read to the same memory location 2 is probably the saving grace in ARM / low power land, given they don't have the power budget to trade speculative loads for performance (in the event they're even out of order in the first place). Caveat: I'm drinking pretty strong Belgian beer while reading through these papers.
Pyxl101 9y ago
How does that pertain to the vulnerabilities that involve eBPF? My understanding is that eBPF code executes within the kernel, and so would run at the same privilege level.

ece 9y ago

Another good article: https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl... "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

mrmondo 9y ago
Yeah that's a good one, hope they keep it updated / link to new info / posts as they come out.
michaelermer 9y ago
Google's post is newer and has more insights, the registry article is now outdated.
- ece 9y ago
  The register has more details. Worth a read.
  - olliej 9y ago
    the google site has the actual white papers detailing the attacks.
    - ece 9y ago
      The register has the tweet with actual code for spectre, and more details from the manufacturers and potential fixes. Seriosuly? They're both worth a read.
      - ece 9y ago
        @lern_too_spel The AMD engineer could be right if talking about Ryzen, and/or he isn't mentioning user-user and user-kernel boundaries. AMD isn't affected in nearly the same way as Intel/ARM are: https://twitter.com/ryanshrout/status/948683677244018689 https://twitter.com/ryanshrout/status/948683677244018689