Warning: in this article, I'll show how to disable mitigations for some vulnerabilities. Do not try this on a production system or any other system containing important data you care about not being leaked/stolen/lost.

After the blog post on the NetBSD kernel compilation benchmarking, and since most of my computers are at least 5 years old, I was wondering how much of an impact on performance the CPU vulnerabilities mitigations have over time. So let's first discover how to verify how vulnerable a system is, disable all we can and then verify again.

how vulnerable am I ?

The test system is the following : an old laptop with an Intel Core i5 i5-3210M, with Hyperthreading enabled. It is running Fedora Linux 37, and all updates are applied at this time. Most notably, the package microcode_ctl is installed in its latest version.

From what I understood, there are two ways to mitigate the ever growing list of processor vulnerabilities : one is by adding fixing code in the OS kernel (Linux in this case), and another is by adding fixing code in the CPU microcode, which is some sort of firmware. Usually, the first one has much more impact on performance than the second one. It may be important because it means a processor can still get mitigations even if the vendor stopped supporting it, which is likely to be my case with a 10-year old laptop.

There are many tools that verify CPU vulnerabilities, and I chose Spectre & Meltdown Checker because it seems to be well maintained, quite complete, easy to use and to understand. It gives for each CVE a status of OK or KO. Let's run it to get a "control" result :

$ cd /tmp
$ curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
$ chmod +x spectre-meltdown-checker.sh
$ sudo ./spectre-meltdown-checker.sh
[lots of stuff and explanations]
> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK CVE-2018-12207:OK CVE-2020-0543:KO

As you can see, my laptop is still vulnerable to CVE-2020-0543, aka 'Special Register Buffer Data Sampling (SRBDS)'. For some other vulnerabilities, I'm not entirely covered :

dmesg |grep "CPU bug"
[    0.198447] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
[   23.371778] L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details.

For the sake of simplicity, I'll still consider myself non vulnerable. So, I'm OK on 14 out of 15 checks.

Disabling the microcode mitigations

Basically, disabling the microcode mitigations means "downgrading the microcode and hoping it is old enough to be vulnerable". Which, on my laptop, was not really possible. The microcode can come from two locations : the first one is the BIOS or UEFI, and the second is the operating system.

In my case, I'm running Fedora. I uninstalled the microcode_ctl package, and out of precaution, updated the initramfs using dracut --force -vvv. However, before and after this, I still had the same microcode version :

$ grep microcode /proc/cpuinfo | sort -u
microcode   : 0x21

After some research, and comparison of Intel's public Github repository with the microcode_ctl package, my only explanation is that the provided BIOS/UEFI has the same microcode version. Does Apple slips EFI updates containing microcode with macOS ?

In order to get a working example, I'm thinking about finding an older computer. Maybe in a follow-up post ?

Disabling the kernel mitigations

This last part is simpler : following the official Linux kernel documentation, disabling the mitigations is as simple as adding mitigations=off to the command-line, either as a one-off at boot time, or by updating the Grub configuration.

Once the mitigations are disabled, the result of the check script is now :

> SUMMARY: CVE-2017-5753:KO CVE-2017-5715:KO CVE-2017-5754:KO CVE-2018-3640:OK CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO CVE-2019-11135:OK CVE-2018-12207:OK CVE-2020-0543:KO

I am still OK for 6 out of 15 checks. I hope this will give results when compiling the NetBSD kernel.

I hope you enjoyed this post ! If you did, please share it on your favorite social networks :-)

Photo by Louis Reed on Unsplash.