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...

I like that it's specex variant 4 and spectre variant 3. Keeps everybody sharp.

This is actually less clear (at least for me) than the project zero post.

Isn't preemption still interupt based. Without interrupts, there would be nothing to cause the CPU to stop executing the demo code. With SMP disabled, this means that nothing else will get a chance to run until the demo code yields itself (or re-enables interupts).

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". Giving up after 1M bust loops ("cycles < 1000000") should prevent this from happening... but... I wonder...

    gcc -o test test.c -Wall -DHIT_THRESHOLD=50 -DNO_INTERRUPTS

Without -O0, some optimizations are still enabled. Could a modern "clever" optimizing compiler assume that the speculative "hit" never happens and therefor conclude that "cycles" is only used after the loop when it is "guaranteed" to have the value 1000000 and "optimize" the loop into something like

    /*long cycles = 0;*/ //DEAD
    while (hits < 32 /*&& cycles < 1000000*/) { //DEAD
        // ... rest of loop body, maybe?
        /* cycles++; */ //DEAD
        pipeline_flush();
    /*}*/ //DEAD

and the sprintf() into something like:

    sprintf(out_, "%c: %s in 100000 cycles (hitrate: %f%%)\n",
        secret_read_area[idx], results,  100*hits/(double)(100000));

I'm probably worrying about nothing. Or at lest I should be worrying about nothing, but with the current trend of "clever" optimizers exploiting everything they think is provable, I'm no longer certain. bleh

Woops! Completely missed that, heh.

There go my plans for non-root system lockup :(