4 ms·

AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues wh

AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.

p_l 7y ago
> AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. > AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen. Putting memory permissions check in retirement stage of the pipeline couldn't be accidental, I say... Sounds like a great "efficiency hack". Till it fucks up.
- deleted 7y ago
  [deleted]
paulddraper 7y ago
AFAIK Spectre variant 1 only applies to a single address space; i.e. per process. Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.
- wolf550e 7y ago
  There used to be a time when people thought relying on if statements for security was enough and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs. Now we know better. 1 - https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)
  - zzzcpan 7y ago
    > and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs WebAssembly doubles down on it today. Technically, though, software isolated lightweight processes within the same address space is still a very real possibility, it's just that isolation is up to the compilers now that have to emit spectre-proof code, so no native blobs. Which, let's get real, has to happen sooner or later for all userspace code, because hardware can't be trusted.
    - gmueckl 7y ago
      You can't trust any computation on hardware that cannot be trusted. There is no way to check that. Any software implemented check to detect that can be thwarted by hardware that misbehaves in malicious ways. Imagine an address based instruction replacement table that is used to convert some key consitional branches into unconditional ones.
    - paulddraper 7y ago
      > hardware can't be trusted "Spectre-proof" code are specific workarounds for hardware bugs, not protection against all hardware security issues.
      - zzzcpan 7y ago
        Obviously. Hardware can't be trusted to do secure isolation, this is the context here.
  - paulddraper 7y ago
    > used to be https://en.wikipedia.org/wiki/Unikernel https://en.wikipedia.org/wiki/Unikernel
- renox 7y ago
  Web browsers didn't (still don't AFAIK) use one process per website visited..
  - wolf550e 7y ago
    They do: https://developers.google.com/web/updates/2018/07/site-isolation https://developers.google.com/web/updates/2018/07/site-isola...
rrss 7y ago
AMD processors were also vulnerable to spectre v2. I don't know the status of the mitigations or whether it was fixed in zen 2. EDIT: I found the list I made a few months back. no guarantees, but i think it is mostly accurate. Meltdown: Intel, IBM, some ARM Spectre v1: Intel, ARM, IBM, AMD Spectre v2: Intel, ARM, IBM, AMD Spectre v3a: Intel, ARM Spectre v4: Intel, ARM, IBM, AMD L1TF: Intel, IBM Meltdown-PK: Intel Spectre-PHT: Intel, ARM, AMD Meltdown-BND: Intel, AMD MDS: Intel RIDL: Intel
- wolf550e 7y ago
  L1TF was an incredibly stupid bug in Intel's L1 cache implementation. I very much doubt IBM's POWER chips had the same issue. Do you have any source for this?
  - Twirrim 7y ago
    Quoting from https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/ https://www.ibm.com/blogs/psirt/potential-impact-processors-... "On August 15, 2018, security vulnerabilities codenamed Foreshadow/L1TF (CVE-2018-3620, CVE-2018-3646 and CVE-2018-3615) were announced. Two of the vulnerabilities (CVE-2018-3620 and CVE-2018-3646) could potentially impact Power Systems. The Firmware and OS patches released by IBM in February and March 2018 to address the original Meltdown vulnerability (CVE-2017-5754) also address the L1TF/Foreshadow vulnerability, except for Power 9 Systems running with KVM Hypervisor. OS patch for Power 9 KVM Systems will be made available soon. The Firmware and OS patches for all other Power Systems are available in this blog below. The third L1TF/Foreshadow vulnerability (CVE-2018-3615) relates to SGX implementation and does not impact the Power Systems."
    - wolf550e 7y ago
      Thank you! L1TF is this: https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-l1-terminal-fault https://software.intel.com/security-software-guidance/insigh... I'm surprised IBM did this. I thought better of them.
- 7y ago

p_l 7y ago

> AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. > AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen. Putting memory permissions check in retirement stage of the pipeline couldn't be accidental, I say... Sounds like a great "efficiency hack". Till it fucks up.

deleted 7y ago
[deleted]

paulddraper 7y ago

AFAIK Spectre variant 1 only applies to a single address space; i.e. per process. Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.

wolf550e 7y ago
There used to be a time when people thought relying on if statements for security was enough and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs. Now we know better. 1 - https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)
- zzzcpan 7y ago
  > and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs WebAssembly doubles down on it today. Technically, though, software isolated lightweight processes within the same address space is still a very real possibility, it's just that isolation is up to the compilers now that have to emit spectre-proof code, so no native blobs. Which, let's get real, has to happen sooner or later for all userspace code, because hardware can't be trusted.
  - gmueckl 7y ago
    You can't trust any computation on hardware that cannot be trusted. There is no way to check that. Any software implemented check to detect that can be thwarted by hardware that misbehaves in malicious ways. Imagine an address based instruction replacement table that is used to convert some key consitional branches into unconditional ones.
  - paulddraper 7y ago
    > hardware can't be trusted "Spectre-proof" code are specific workarounds for hardware bugs, not protection against all hardware security issues.
    - zzzcpan 7y ago
      Obviously. Hardware can't be trusted to do secure isolation, this is the context here.
- paulddraper 7y ago
  > used to be https://en.wikipedia.org/wiki/Unikernel https://en.wikipedia.org/wiki/Unikernel
renox 7y ago
Web browsers didn't (still don't AFAIK) use one process per website visited..
- wolf550e 7y ago
  They do: https://developers.google.com/web/updates/2018/07/site-isolation https://developers.google.com/web/updates/2018/07/site-isola...

rrss 7y ago

AMD processors were also vulnerable to spectre v2. I don't know the status of the mitigations or whether it was fixed in zen 2. EDIT: I found the list I made a few months back. no guarantees, but i think it is mostly accurate. Meltdown: Intel, IBM, some ARM Spectre v1: Intel, ARM, IBM, AMD Spectre v2: Intel, ARM, IBM, AMD Spectre v3a: Intel, ARM Spectre v4: Intel, ARM, IBM, AMD L1TF: Intel, IBM Meltdown-PK: Intel Spectre-PHT: Intel, ARM, AMD Meltdown-BND: Intel, AMD MDS: Intel RIDL: Intel

wolf550e 7y ago
L1TF was an incredibly stupid bug in Intel's L1 cache implementation. I very much doubt IBM's POWER chips had the same issue. Do you have any source for this?
- Twirrim 7y ago
  Quoting from https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/ https://www.ibm.com/blogs/psirt/potential-impact-processors-... "On August 15, 2018, security vulnerabilities codenamed Foreshadow/L1TF (CVE-2018-3620, CVE-2018-3646 and CVE-2018-3615) were announced. Two of the vulnerabilities (CVE-2018-3620 and CVE-2018-3646) could potentially impact Power Systems. The Firmware and OS patches released by IBM in February and March 2018 to address the original Meltdown vulnerability (CVE-2017-5754) also address the L1TF/Foreshadow vulnerability, except for Power 9 Systems running with KVM Hypervisor. OS patch for Power 9 KVM Systems will be made available soon. The Firmware and OS patches for all other Power Systems are available in this blog below. The third L1TF/Foreshadow vulnerability (CVE-2018-3615) relates to SGX implementation and does not impact the Power Systems."
  - wolf550e 7y ago
    Thank you! L1TF is this: https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-l1-terminal-fault https://software.intel.com/security-software-guidance/insigh... I'm surprised IBM did this. I thought better of them.
7y ago