As recently announced in a previous article I wanted to write a couple of guides on how to mitigate Spectre and Meltdown vulnerabilities in GNU/Linux and UNIX environments. It is always a good and I hope a standard practice to have your systems patched and if they aren’t for whatever the reason (that legacy thing you’re carrying on for ages) you may take the necessary extra steps to protect your environment. I never planned to do any article on patching anything. Nowadays it’s a no brainier and operating systems have provided the necessary tools for this to be easy and as smooth as possible. So why this article?
Spectre and Meltdown are both hardware vulnerabilities. Major ones. They are meaningful for several reasons among them the world wide impact since they affect Intel and AMD systems which are ubiquitous. And second because patching hardware is not as easy, for the manufacturer and for the users or administrators in charge of the systems. There is still no known exploit around left out in the open hitting servers or desktops anywhere. The question is not if it will ever happen. The question is when will it happen. And it may be sooner than later. This is why big companies, governments and people in charge of big deployments are patching or have already patched their systems. But have you done it to your system? I know you have a firewall. Have you thought about CVE-2018-3639? This particular one could make your browser being a vector to get into your system. So, no, there is no reason to skip this.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.
Mind Vultr supports FreeBSD on their VPS offer.
Patching these set of vulnerabilities implies some more steps and concerns than updating the operating system. If you are a regular Windows user I find rare you to be here and many of the things you will read may be foreign to you. I am not planning to do a guide on Windows systems since I believe someone else has or will do it and will do it better than me since I am not a pro Windows user. However there is one basic and common thing for all OS’s when dealing with Spectre and Meltdown and that is a microcode update is necessary for the OS patches to effectively work.
What is microcode? You can read the Wikipedia article but in short it is basically a layer of code that allows chip manufacturers to deal with modifications on the hardware they’ve produced and the operating systems that will manage that hardware. Since there’s been some issues (namely Spectre and Meltdown) Intel and AMD respectively have released a series of microcode updates to address those problems. First series did come with serious problems and some regressions, to the point GNU/Linux producers stopped releasing the microcode updates through their release channels for updates and placed the ball on Intel’s roof. Patching fast does always include risks, specially when dealing with hardware. OS vendors have resumed their microcode update releases so all seems to be fine now.
In order to update the microcode we’re faced with two options. Download the most recent BIOS release from our vendor, provided it patches the Spectre and Meltdown vulnerabilities, or patch it from the OS. If your hardware vendor has decided not to provide support on your hardware you are forced to use the latter solution. Yes, you can still keep your hardware. They usually come accompanied with a “release notes” file where there are some explanatory notes on what is fixed, what is new, etc. To make the search easy for you a news site collected the vendors list and linked the right support pages for anyone to look. In some scenarios it would be desirable not to replace the whole BIOS but just update the microcode from the OS side. In my case I should update an HP Proliant ML110 G7 box and the download link for that would be this.
Instead of using the full blown BIOS update path we’ll use the inner utilities to patch Spectre and Meltdown on FreeBSD. So let’s put our hands on it.
This is the output of the FreeBSD version in use:
albert@HP:~ % freebsd-version
11.2-RELEASE-p2
albert@HP:~ %
Plus the pkg utility is using the very latest available packages instead of the quarterly ones:
albert@:HP~ % cat /etc/pkg/FreeBSD.conf
# $FreeBSD: releng/11.2/etc/pkg/FreeBSD.conf 333474 2018-05-10 23:58:33Z gjb $
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
# mkdir -p /usr/local/etc/pkg/repos
# echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#
FreeBSD: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
albert@HP:~ %
Now let’s find out what hardware we’re running on by typing dmesg. You’ll see a ton of output but we’ll concentrate on the CPU bit:
CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3093.04-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x1fbae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX>
AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
AMD Features2=0x1<LAHF>
XSAVE Features=0x1<XSAVEOPT>
VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
TSC: P-state invariant, performance statistics
With FreeBSD there are a few steps to follow. First we’ll determine what microcode version we’re running on. For that we’ll install a tool called x86info.
albert@HP:~ % sudo pkg install x86info
Updating FreeBSD repository catalog...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
x86info: 1.31.s02
Number of packages to be installed: 1
60 KiB to be downloaded.
Proceed with this action? [y/N]: y
[1/1] Fetching x86info-1.31.s02.txz: 100% 60 KiB 61.6kB/s 00:01
Checking integrity... done (0 conflicting)
[1/1] Installing x86info-1.31.s02...
[1/1] Extracting x86info-1.31.s02: 100%
Message from x86info-1.31.s02:
===> NOTICE:
The x86info port currently does not have a maintainer. As a result, it is
more likely to have unresolved issues, not be up-to-date, or even be removed in
the future. To volunteer to maintain this port, please create an issue at:
https://bugs.freebsd.org/bugzilla
More information about port maintainership is available at:
https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html#maintain-port
albert@HP:~ %
Before using this tool we have to turn on a kernel module called cpuctl. If we want to store it as permanent you may edit the /boot/loader.conf file and add:
cpuctl_enable="YES"
Now, if you just want to do this for now because you don’t see the need for keeping track of microcode updates or order cpu matters (this is not a light decision to make and maybe having it off is a better idea than the having it on) you can load the module for the time the system is on.
albert@HP:~ % sudo kldload cpuctl
albert@HP:~ %
To check if it’s loaded:
albert@HP:~ % sudo kldstat | grep cpuctl
32 1 0xffffffff82908000 31f7 cpuctl.ko
albert@HP:~ %
If the command results on nothing it is not loaded. If you see something similar as above with the entry on your right, the module is loaded.
At this point we are ready to use x86info to get information about our CPU and the microcode version it’s running on.
[albert@HP ~]$ sudo x86info -a | grep Microcode
Microcode version: 0x000000000000002d
[albert@HP ~]$
It is now time to grab the Intel’s latest manual (supposing you’re using that vendor instead of AMD) and compare the result we’ve received to what they’ve published. This is a necessary step I haven’t seen on many guides to patch Spectre and Meltdown. Launching commands does not guarantee the desired result necesseraly. I am still learning this the hard way.
This is the link we’ll use to check our CPU and microcode:
https://www.intel.com/content/dam/www/public/us/en/documents/sa00115-microcode-update-guidance.pdf
The CPU I am patching here is a Xeon E3-1220 from an HP Proliant ML110 G7. If you check on the table the microcode in use now, you won’t find it on the Sandy Bridge section where it belongs. It’s an Intel’s errata. The actual status of this microcode version running on the CPU is what Intel calls “Pre-mitigation production MCU”. Yes, all those zeroes on the left of “2d” can be skipped for their meaningless. So this CPU is behind the desired microcode version. Next, the desired update and hopefully the result will be in Intel’s parlance: “New Production MCU Rev”.
FreeBSD offers two solutions to update microcode for the main CPU. The classic devcpu-data on one hand and cpupdate. The former is a proven old solution. The latter claims to be better with new microcode releases but we’ll stick to the old and proven. To use the newest tool click here and here, and then do your thing.
The first step is installing the devcpu-data tool.
albert@HP:~ % sudo pkg install devcpu-data
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
devcpu-data: 1.19
Number of packages to be installed: 1
The process will require 2 MiB more space.
1 MiB to be downloaded.
Proceed with this action? [y/N]: y
[1/1] Fetching devcpu-data-1.19.txz: 100% 1 MiB 1.4MB/s 00:01
Checking integrity... done (0 conflicting)
[1/1] Installing devcpu-data-1.19...
[1/1] Extracting devcpu-data-1.19: 100%
Message from devcpu-data-1.19:
Installing this port will allow host startup to update the CPU microcode on
a FreeBSD system automatically. In order to enable this feature, add the
following to the system's /etc/rc.conf:
microcode_update_enable="YES"
To ensure the update is applied, reboot the system or start the microcode update
service via:
# service microcode_update start
If the CPU requires a microcode update, a console message such as the following
will appear:
Updating CPU Microcode...
/usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl0 from rev 0x17 to rev 0x22... done.
/usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl2 from rev 0x17 to rev 0x22... done.
/usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl4 from rev 0x17 to rev 0x22... done.
/usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl6 from rev 0x17 to rev 0x22... done.
Done.
albert@HP:~ %
As the instructions say we have to edit the /etc/rc.conf file and we’ll do this by:
albert@HP:~ % sudo sysrc microcode_update_enable="YES"
Password:
microcode_update_enable: -> YES
albert@HP:~ %
Once this is done we can launch the tool:
albert@HP:~ % sudo service microcode_update start
Updating CPU Microcode...
Done.
albert@HP:~ %
Let’s now check the microcode version again with x86info.
[albert@HP ~]$ sudo x86info -a | grep Microcode
Microcode version: 0x000000000000002e
[albert@HP ~]$
As you can see it has changed. It was ended with 2d before and now it’s 2e. Let’s compare the new value yet again with the pdf file from Intel.
Fortunately enough the microcode is now in Intel’s parlance in “New Production MCU Rev.” status. As a final note it’s worth noting that commenting out the line microcode_update_enable=”YES” does not keep the updated microcode and in the next reboot we’ll find ourselves using an older and probably outdated and maybe dangerous microcode version. So keep it on.
Devcpu-data is the right tool, or at least good enough, to patch Spectre and Meltdown on FreeBSD. Again, this time, because this is a hardware issue patching the OS is not enough. It is mandatory to get microcode updates combined with OS patches in order to mitigate or fully patch these vulnerabilities.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.
Mind Vultr supports FreeBSD on their VPS offer.