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.
spectre v2, like v1, isn't one that is "fixable." The mitigations (retpoline & microcode updates) are essentially additions that are added in places where security checks are done to just disable speculation for that particular check. But you still have to choose when & where to use those or even if you opt to use them at all.
There are no sweeping fixes for either v1 or v2, and there probably won't be for a long time at best.
But the positive news is that v1 & v2 only matter at all if you do in-process sandboxing of untrusted code. Which most things don't do, so most things are not at any risk from it.
> But the positive news is that v1 & v2 only matter at all if you do in-process sandboxing of untrusted code.
I don't think this is accurate. It seems to be a widespread misunderstanding that started because the original proof of concept was within a single process. Spectre, before mitigations, allowed userspace to read kernel memory if appropriate gadgets in the kernel could be identified and exploited.
My understanding is the impact is only intra-process after mitigations.
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?
"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."
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.
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.
> 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.
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.
> 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.
There are some architectural differences that help amd with this specific issues, but I’m pretty sure main reason is just scale - amd is still niche nowadays and receives much less scrutiny and attention from security researchers
