11–20 of 22 posts
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."
Possibly 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…
https://www.reenigne.org/blog/how-to-get-away-with-disabling...
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."
Possibly 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…
That makes me curious; I wonder what on a modern PC relies on periodic interrupts, and would lock up the machine if they didn't occur. I know on the original PC and XT, DRAM refresh relied on interrupts but that stopped being the case with the AT: https://www.reenigne.org/blog/how-to-get-away-with-disabling...
Possibly 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 I would guess the deadlock is due to a hardware watchdog timer rebooting the system, or some other hardware function that needs to be tended to periodically before it hangs.
If interrupts are off, the the PoC program might wait forever for "hits > 32" if never testfun() never detects a "hit". Giving up after 1M bust loops ("cycles but... I wonder...
gcc -o test test.c -Wall -DHIT_THRESHOLD=50 -DNO_INTERRUPTS
/*long cycles = 0;*/ //DEAD
while (hits sprintf(out_, "%c: %s in 100000 cycles (hitrate: %f%%)\n",
secret_read_area[idx], results, 100*hits/(double)(100000));
Earlier quoted context omitted.
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 I would guess the deadlock is due to a hardware watchdog timer rebooting the system, or some other hardware function that needs to be tended to periodically before it hangs.
It doesn't look like a deadlock; turning off interrupts prevents the preemptive scheduler from running. Without a timer interrupt, the only way the scheduler would run is if it's invoked to put the process to sleep during a blocking syscall or explicitly with sched_yield(2), pthread_yield(3), etc . If interrupts are off, the the PoC program might wait forever for "hits > 32" if never testfun() never detects a "hit".…
Virtual Machines now need to be exposed a new Intel CPU feature flag: 'ssbd' (Speculative Store Bypass Disable).
On microcode, from Red Hat's blog post[3]:
In many (but not all) cases, full mitigation will also require updated microcode from the system microprocessor vendor. Red Hat intends to ship updated microcode as a convenience to our customers as it is made available to us. In the interim, customers are strongly advised to contact their OEM, ODM, or system manufacturer to receive this via a system BIOS update.
[1] https://www.redhat.com/archives/libvir-list/2018-May/msg0156...
[2] https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg047...
[3] https://www.redhat.com/en/blog/speculative-store-bypass-expl...
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."
I like that it's specex variant 4 and spectre variant 3. Keeps everybody sharp.
Possibly 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 I would guess the deadlock is due to a hardware watchdog timer rebooting the system, or some other hardware function that needs to be tended to periodically before it hangs.
There go my plans for non-root system lockup :(