.png){kind=small}
Meltdown and Spectre
In the previous post I have introduced the Meltdown and Spectre vulnerabilities of modern x86 processors and what threat do they pose to security and safety of the data. As a continuation of the last post, I will demonstrate the state of Meltdown and Spectre vulnerabilities on PC Engines apu2 platforms. Some time ago we have added a microcode update feature to PC Engines firmware so I will show how microcode update improves mitigation and present results using public tools, proof of concepts known to exploit the vulnerability.
State of Meltdown and Spectre on apu2
Let’s take v4.9.0.1 firmware release as a reference for initial testing. In this post I will use Debian stable release installed on mSATA SSD:
|
|
Firstly let’s check the state of the vulnerabilities on the system. I will use the spectre meltdown checker and Spectre PoC by Ryan Crosby which was proven to work on AMD GX-412TC SoC (apu2 platforms processor). For details see README Tweaking section.
Spectre meltdown checker
Let’s start with spectre meltdown checker:
|
|
Or:
|
|
SHA256 of the script used: b0f884be51f0eb49ed61854f0e011a2f89f44c35699e07a705b0ec6f98fa29b5
Now load msr module, give execution permission to the script and run it:
|
|
The result is as follows
-
Hardware support for mitigation techniques:
-
Spectre variants mitigation checks:
What is worth noticing here is that script reports that system is not vulnerable due to mitigation presence, however:
|
|
One can see that mitigation can still be improved by microcode updates.
One can check current microcode patch level in dmesg:
1 2 3 4 5 6 7 8 9 10 11 12 13 14microcode: CPU0: patch_level=0x07030105 microcode: CPU1: patch_level=0x07030105 microcode: CPU2: patch_level=0x07030105 microcode: CPU3: patch_level=0x07030105 ```bash Be sure to use recent kernels with implemented mitigation (dmesg output): ```bash Spectre V2 : Mitigation: Full AMD retpoline Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Spectre PoC
In order to prove that the script wrongly reports that the platform is not vulnerable, we will perform proof of concept with the usage of Spectre PoC:
|
|
I have run the executable with two different parameters.
|
|
One can see that the secret string was not disclosed (0xFF=? everywhere). Let’s increase the cache hit threshold.
|
|
One can see that positive results are obtained with a larger value of cache hit threshold (with 70 some characters have not been obtained - score 0, 100 is sufficient to get whole string - score 2 everywhere). It is related to CPU performance.
For those more interested in details of the attack, please refer to Spectre Attacks or to my previous post introducing the Meltdown and Spectre.
Let’s also check out the kernel mitigation. Rebuild the PoC with:
|
|
After trying to run the PoC with 20/70/100 the string is not disclosed. But what if the kernel we use does not have the mitigation? The answer is firmware and microcode for full hardware mitigation.
Microcode update and spectre
To present results of Spectre vulnerability without kernel mitigation, we will need the microcode update. For details how to build PC Engines apu2 coreboot firmware with microcode update, please refer to this guide
Building the firmware is pretty easy and the guide shows step by step solution to obtain binary.
You may also watch how to build coreboot with microcode update for apu2:
Flashing coreboot is possible with flashrom:
|
|
Watch out! Flashing the SPI ROM carelessly may lead to hardware damage. Also be sure You have a recovery method available, for example SPI1a Be sure to do a full power cycle (with power supply detaching) after firmware update, simple reboot is not advised.
dmesg should now report new patch level:
|
|
Spectre meltdown checker with microcode update
Let’s run the spectre meltdown checker with updated microcode.
For convenience, I will paste only the differences between the result with and without microcode:
Before microcode patching:
|
|
After microcode patching:
|
|
One may notice that the values regarding Indirect Branch Prediction Barrier
have been updated and platform gained slightly better protection.
Spectre PoC with microcode update
Let’s try now the Spectre PoC on Debian booted on firmware with microcode update:
Try various cache hit thresholds like before 20/70/100 and even more. Unfortunately, the secret is still revealed without kernel mitigation.
|
|
But let’s check anothertool
aimed to exploit CVE-2017-5715. Following the README:
|
|
Change the
#define CACHE_HIT_THRESHOLD 80to the value of 200 before compiling to be sure to trigger the vulnerability.
Result without microcode update:
|
|
Result with updated microcode:
|
|
The exploit-cve-2017-5715 does not seem to use the kernel mitigation thus we
obtain the same result as with Spectre PoC without compiled mitigation.
Summary
In the light of my experiments, it looks like microcode does not fully mitigate
the Meltdown and Spectre vulnerabilities. It seems to enable
Indirect Branch Prediction Barrier which is just a small part of the
vulnerability protection.
Most of the protection is achieved by using the kernel with proper mitigation.
Although some of the mitigation look to be inactive due to lack of hardware
support (Indirect Branch Restricted Speculation).
Used scripts and tools give only overall insight into the status of the Meltdown and Spectre. They are not official tools proving system vulnerability, they were designed to give information on present mitigation (spectre meltdown checker) or to try exploiting the vulnerabilities based on an article.
It has to be noted that AMD and Intel processors are affected differently. AMD processors are “marked” to not be vulnerable for some variants. AMD has even released a statement regarding the speculative execution.
During experiments, different results have been obtained. It proves that only combined mitigation in firmware/microcode and kernel give the best protection. Although microcode update seems to not improve the situation in this particular case.
I hope this post was useful for you. Please feel free to share your opinion and if you think there is value, then share with friends.
If you think we can help in improving the security of your firmware or you
looking for someone who can boot your product by leveraging advanced features of
used hardware platform, feel free to
book a call with us or
drop us email to contact<at>3mdeb<dot>com. If you are interested in similar
content feel free to sign up for our newsletter
