Live data from Hacker News

Speculative execution, variant 4: speculative store bypass

bugs.chromium.org

21–22 of 22 posts

Re: Speculative execution, variant 4: speculative store bypass

#21
post #11

AMD guidance: https://developer.amd.com/wp-content/resources/124441_AMD64_... (setting an CPU-specific MSR and it's done for current CPUs, no microcode updates required.) https://www.amd.com/en/corporate/security-updates has : "We have not identified any AMD x86 products susceptible to the Variant 3a vulnerability in our analysis to-date."

For AMD, in context of virtualization — you would need to also expose a new CPUID flag: 'virt-ssdb', which all hypervisor vendors will expose to guests on AMD hosts. More from the libvirt patch[1]:

Some AMD processors only support a non-architectural means of enabling Speculative Store Bypass Disable. To allow simplified handling in virtual environments, hypervisors will expose an architectural definition through CPUID bit 0x80000008_EBX[25]. This needs to be exposed to guest OS running on AMD x86 hosts to allow them to protect against CVE-2018-3639.

Note that since this CPUID bit won't be present in the host CPUID results on physical hosts, it will not be enabled automatically in guests configured with "host-model" CPU unless using QEMU version >= 2.9.0. Thus for older versions of QEMU, this feature must be manually enabled using policy=force. Guests using the "host-passthrough" CPU mode do not need special handling.

[1] https://www.redhat.com/archives/libvir-list/2018-May/msg0156...

Re: Speculative execution, variant 4: speculative store bypass

#22
A commenter over at arstechnica (https://arstechnica.com/gadgets/2018/05/new-speculative-exec...) found an old article explaining the optimization which led to this vulnerability: "Faster Load Times - Intel Core versus AMD's K8 architecture" https://www.anandtech.com/show/1998/5
Post reply on HN