You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
I just did a test. One thread of RDRAND on an unpatched Xeon E-2144G (8 threads) drops 7-threaded sysbench performance by 10%. The same with the patch, 55%. So with the patch, a rogue core can now halve your memory performance. But it gets better.
Running 8 threads (on an 8-thread E-2144G) of RDRAND in the background, memory throughput drops by *81%* with the patch vs unpatched (91% vs idle). So if someone can spawn a bunch of RDRAND threads, they can drop your memory perf to 19% of what it would be, 9% of nominal.
Good lord, no wonder Apple wants to jump ship.
I didn't find the time to run this test for the paper, so thank you so much for actually doing it! It was clear it'd be bad given that they put the effort in to add an MSR to disable the mitigations again. It's about the level of performance hit I expected, but.. ouch. Very ouch.
It was just a quick sysbench thing, not even sure exactly what kind of memory workload it's using, vs "a: rdrand %rax; jmp a", but yeah.... it looks pretty bad.
Could Cloud Vendor A spin up up vms on Cloud Vendor Bs cloud which basically spin and emit RDRAND hence killing perf?
It would be interesting to see if this performance drop is worse than what was already possible by other operations such as split locks (atomic operation covering two cachelines). To ensure coherence, they also cause a bus lock on Intel CPUs.https://lwn.net/Articles/790464/ …
Who uses RDRAND after all? it's not even the main source for /dev/(u)random
Sigh. I've also heard Intel removed the ability to undervolt in Comet Lake to prevent plundervolt-style enclave attacks... that's so disappointing. I can't understand why they wouldn't let you disable SGX instead.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
