Speculative execution, variant 4: speculative store bypass
bugs.chromium.org
Speculative execution, variant 4: speculative store bypass
1–10 of 22 posts
Re: Speculative execution, variant 4: speculative store bypass
#2Re: Speculative execution, variant 4: speculative store bypass
#3Re: Speculative execution, variant 4: speculative store bypass
#4Explained: https://www.redhat.com/en/blog/speculative-store-bypass-expl...
This is actually less clear (at least for me) than the project zero post.
Re: Speculative execution, variant 4: speculative store bypass
#5Explained: https://www.redhat.com/en/blog/speculative-store-bypass-expl...
This is actually less clear (at least for me) than the project zero post.
Can you share the link? I found the redhat article clearer than the current chromium FP post :)
---
edit: I wasn't able to find anything new since Jan 3rd about the speculative bypass from Project Zero.
Some additional articles about the newly revealed Variant 4:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/Variant4
https://xenbits.xen.org/xsa/advisory-263.html
https://www.cnet.com/news/intel-microsoft-reveal-new-variant...
https://newsroom.intel.com/editorials/addressing-new-researc...
Re: Speculative execution, variant 4: speculative store bypass
#6Earlier quoted context omitted.
This is actually less clear (at least for me) than the project zero post.
Can you share the link? I found the redhat article clearer than the current chromium FP post :) --- edit: I wasn't able to find anything new since Jan 3rd about the speculative bypass from Project Zero. Some additional articles about the newly revealed Variant 4: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/Variant4 https://xenbits.xen.org/xsa/advisory-263.html https://www.cnet.com/news/intel-microsoft-reveal-n…
>Can you share the link? I found the redhat article clearer than the current chromium FP post :)
I was talking about https://bugs.chromium.org/p/project-zero/issues/detail?id=15...
Re: Speculative execution, variant 4: speculative store bypass
#7Possibly completely unrelated question (this stuff is firmly over my head): toward the end of the first PoC there's
/* if we don't break the loop after some time when it doesn't
work, in NO_INTERRUPTS mode with SMP disabled, the machine will lock
up */
======== Demo code (no privilege boundaries crossed) ========
So... is this deadlock fundamentally related to the speculative execution glitch(es)?
Re: Speculative execution, variant 4: speculative store bypass
#8These are the links I found most explanatory
https://bugs.chromium.org/p/project-zero/issues/detail?id=15...
https://software.intel.com/sites/default/files/managed/b9/f9...
https://software.intel.com/sites/default/files/managed/c5/63...
https://blogs.technet.microsoft.com/srd/2018/05/21/analysis-...
https://developer.amd.com/wp-content/resources/124441_AMD64_...
https://www.intel.com/content/www/us/en/security-center/advi... uCode update is only for variant 3a (MSR read) and for the global disable bit in the MSR. The standard mitigation is still LFENCE.
https://docs.microsoft.com/en-us/cpp/security/developer-guid... vulnerable code examples
Re: Speculative execution, variant 4: speculative store bypass
#9Possibly completely unrelated question (this stuff is firmly over my head): toward the end of the first PoC there's /* if we don't break the loop after some time when it doesn't work, in NO_INTERRUPTS mode with SMP disabled, the machine will lock up */ The bit at the top of the that says ======== Demo code (no privilege boundaries crossed) ======== is suggestive and unambiguous, but the program executions show (with…
Locking up the machine is a possibility when you disable interrupts. Disabling interrupts with the cli instruction needs the IO privilege level (IOPL) to be at least as high as the protection ring the code is running in. Linux runs userspace code in ring 3, so the IOPL has to be set to 3 with the iopl call first. This requires the CAP_SYS_RAWIO capability, which allows you to do pretty much anything already.
Re: Speculative execution, variant 4: speculative store bypass
#10Possibly completely unrelated question (this stuff is firmly over my head): toward the end of the first PoC there's /* if we don't break the loop after some time when it doesn't work, in NO_INTERRUPTS mode with SMP disabled, the machine will lock up */ The bit at the top of the that says ======== Demo code (no privilege boundaries crossed) ======== is suggestive and unambiguous, but the program executions show (with…
You wouldn't be able to disable interrupts as non-root. The iopl syscall allows the PoC to use CLI to disable interrupts. See the "sudo" in the NO_INTERRUPTS runs:
$ gcc -o test test.c -Wall -DHIT_THRESHOLD=50 -DNO_INTERRUPTS
$ sudo ./test