Tags: Coreboot, F2A85-M, F2A85-M PRO, A10-5800K
Last Update: Jan 2021

This guide is based on the BIOS UEFI replacement called Coreboot which runs on an ASUS F2A85-M or F2A85-M PRO mainboard with an AMD A10-5800K CPU with integrated graphics.

1. Introduction and aim

This initial idea came up with the uprising problems and vulnerabilities of Intel ME and AMD Secure Technology (PSP). After having researched several alternatives without running those (in)secure technologies I was looking for very specific hardware to meet the requirements on security as mentioned in the pinetree of open and secure classical computing.

The aim is to provide a comprehensive guide which allows the daily user to gain a higher level of security. The daily user shall be empowered to get back the control about every piece of hardware within the computer system. In general hardware is always run by the so-called firmware. Firmware is software which is in the closest control of the underlying hardware to make it work as intended. So firmware is needed by the all BIOS/UEFI computer systems we know. Based on these hardware firmwares the central BIOS/UEFI unit is able to tell other computer parts how to cooperate. The newer the hardware, the worse the availability of open firmware. In fact in most cases the availability of open code is zero, because vendors assume that keeping the source code secret (closed source code) increases the security of the product. Nowadays we’ve learned by many lessons that this conviction is wrong. It’s a fact that every source contains errors which might be exploitable if they are found. The more people access a source code, the better this code is reviewed and the fewer errors are included.

Conclusion: Due to this circumstance sometimes developers have to use vendor’s original binary code (firmware) to get the hardware to work at all. That means that wide limitations are accepted by almost all vendors. Security can only be guaranteed by open source code. This leads to a conflict of objectives: On one hand we want a secure system and on the other hand we don’t want to lose comfort by leaving out the functionality which the vendor has placed within his (closed) firmware.

Maybe you take this into account before you support a certain vendor by buying his hardware the next time.

Since it’s practically almost impossible to use every piece of hardware out there by open code, we need to find the best compromise between functionality and security:

• free and open source code
• running Coreboot or even Libreboot
• running Windows and GNU/Linux
• as little as possible of (closed) firmware
• enough performance to get work done

2. Software we will need

• For booting the system we will use Coreboot instead of the vendor’s BIOS/UEFI. Libreboot is even a “better” option but – as mentioned in other posts – unfortunately very few and old boards are supported.
• As an operating system you can choose one from the recommendations. I prefer using Manjaro GNU/Linux with the free driver stack option which you can choose while booting the installation disk from a pen-drive. In my view this is the best mix between bleeding edge development, security and user comfort.
• If you prefer to build the Coreboot ROM on your own, you need a Linux on which you can compile the Coreboot sources. Ubuntu is usually a good choice.
• If you prefer to extract the VGA BIOS on your own, you will also need to run a live Linux from a pen-drive for extraction.

3. Hardware you will need (mostly second hand)

Hardware used	Notes	$
Mainboard F2A85-M PRO	Both the ASUS F2A85-M or F2A85-M PRO are currently the best choice for a desktop platform, because it is widely supported by Coreboot.	40
CPU AMD A10-5800K	As we found out before AMD’s Piledriver and Steamroller CPU architectures (codenames Trinity, Richland and Kaveri) are the latest ones which does NOT include those (in)secure technologies. The AMD A10-5800K or AMD A10-6800K are the most compatible and powerful CPU/APU you can run on with Coreboot on this mainboard.	40
CPU Cooler Xilence A250PWM	Pick any adequate CPU cooler you want which is supporting the FM2 socket. You can use a good old Arctic Freezer A30 with a silent 120mm fan (~ 30 $). If you want something new you can take the Xilence A250PWM (XC035).	10
Memory Kingston KHX1600C10D3B1K2	DDR3-1866 RAM is the fastest RAM speed our CPU is supporting. The amount depends just on your personal demands. With a minimum of 8 GB we should be good to go. I’ve been successful with Corsair CML16GX3M2A1600C100 and Kingston KHX1600C10D3B1K2; but there are many many others that will work, too.	50
HDD/SSD	We need a SATA hard-drive for the operating system. Think about using a SSD if you want a fast system. Remember to encrypt your partitions and/or files – especially if you are using a SSD.	50
GPU	In the CPU above the graphics are onboard and included within the CPU. So there is no need to buy a dedicated one.	0
Power Supply	As a power supply any standard ATX AC adaptor will work.	30
Case Bitfenix Prodigy M	Choose a computer case according to your personal preferences. I like the Bitfenix Prodigy M. Remember: Not all micro ATX cases are suitable for taking bigger/higher CPU coolers. This one takes and bigger CPU cooler like the Freezer A30 perfectly.	50
Flashtool CH341A	In order to flash the BIOS chip via SPI we need a CH341A USB Programmer.	15
BIOS chip W25Q64FVAIG	I recommend strongly to buy a separate Winbond W25Q64FVAIG or W25Q64BVAIG spare chip in order to flash the Coreboot build onto it. There are people who flash the onboard chip during a running system but this process can fail and in my opinion it’s better to have a fallback – just in case flashing or extraction have failed.	10
	total cost, approx.	295

4. Assembling your computer

I assume you know how to assemble a computer so now it’s a good time to do so. Make sure your DDR3 RAM is placed into the BLUE SLOTS. Otherwise your computer won’t boot up.

5. Extracting the VGA BIOS binary blob

Unfortunately the internal GPU won’t work unless we integrate its binary into the Coreboot ROM.

You can download now the vgabios.zip which contains the vgabios.bin which I have extracted already from an AMD A10-5800K. Or you download it on your own following the Coreboot guide:

Boot up a linux live Distro like Ubuntu from your prepared pendrive.

Check the ID by issueing “lspci -tvnn”. As you can see my ID of the GPU is 1002:9901. Write the ID down. We will need it later to build the Coreboot ROM.

lspci -tvnn
-[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex [1022:1410]
           +-00.2 Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) I/O Memory Management Unit [1022:1419]
           +-01.0 Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7660D] [1002:9901]
           +-01.1 Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio Controller [1002:9902]
...

For enabling to read the ROM we need to set a enablement bit 1 to the corresponding address 0000:00:01.0 which we found above:

echo 1 > /sys/devices/pci0000:00/0000:00:01.0/rom

Now we can extract the VGA BIOS into a binary. Copy the vgabios.bin file onto a pendrive.

cp /sys/devices/pci0000:00/0000:00:01.0/rom vgabios.bin

6. Building the Coreboot ROM

If you want to skip this step or encounter unsolvable errors prohibiting you to generate the ROM you can download one of my compiled ROMs:

• coreboot.rom for AMD A10-5800K & ASUS F2A85M-PRO
• coreboot.rom for AMD A10-5800K & ASUS F2A85M (coming soon)

Since the old method isn’t working anymore you can decide now if you want to prepare Ubuntu Linux on your own or want to download my already prepared Virtual Machine I prepared for you.

6a. Preparing Ubuntu 20.04 LTS for building Coreboot

Get yourself a fresh copy of Ubuntu 20.04 LTS. Supply your Ubuntu with needed packages:

sudo apt-get install git build-essential gnat flex bison libncurses5-dev wget zlib1g-dev python

Let’s clone the Coreboot repository and change into that folder:

git clone https://review.coreboot.org/coreboot
cd coreboot

Now copy your vgabios.bin from chapter 5 into the root directory of your Coreboot folder. Alternatively you can use my extracted vgabios.bin from a 5800K:

wget https:/freundschafter.com/download/coreboot/vgabios.bin

Now you can set up the Coreboot environment for building the Coreboot ROM, which we’ll transfer to our BIOS chip.

6b. Setup your settings for the Coreboot build

Run the configuration wizard with:

make nconfig

Save your configuration by hitting “Save”, leave the filename “.config” and exit the tool.

Build the Compiler. CPUS=4 means it will use 4 cores to compile. Adjust this value to meet your number of cores. Be patient, this process takes some time. With my older notebook I had to wait around 10-20 minutes.

make crossgcc-i386 CPUS=4

Finally we are able to build the Coreboot ROM:

make

You will find the generated coreboot.rom in a subfolder called build.

7. Flashing the Coreboot ROM

• Place your spare chip on the USB programmer and plug it into a USB port on your Linux machine.
• Install flashrom under Ubuntu by

sudo apt-get install flashrom

Flash your spare chip now with your generated coreboot.rom:

sudo flashrom -n -w build/coreboot.rom --programmer ch341a_spi

If you get the following notifications your chip is ready:

Found Winbond flash chip "W25Q64.V" (8192 kB, SPI).
Erase/write done.
Verifying flash... VERIFIED.

Replace your old BIOS chip by the new flashed one during your system is switched off. Be careful not to bend a pin. So-called DIP8 pliers might help you to release the chip from the board.

Just in case you mess something up you can download a fresh vendor’s copy of the original BIOS/UEFI image and flash it again:

• ASUS F2A85-M: BIOS image v6508
• ASUS F2A85-M PRO: BIOS image v6601

8. Operating System

Now, equipped with Coreboot, you can choose to install any operating system you wish. Since I am very familiar with it I’d go with something Debian-based: PureOS. If you want to follow me, you’ll notice that after installation of PureOS 9.x your screen will remain black due to the lack of AMD graphics firmware packages within PureOS. (Actually it’s a good sign because now you see that binary blobs like the AMD firmware really weren’t loaded during bootup). To fix this we need to install a package into our PureOS installation:

8a. Prepare the pendrive

Get a pendrive formatted with FAT and use another computer to prepare it. Download the firmware.zip archive from https://cdimage.debian.org/cdimage/unofficial/non-free/firmware/testing/current/ and extract firmware-amd-graphics*.deb from it. If you use Linux you can use the following lines:

wget https://cdimage.debian.org/cdimage/unofficial/non-free/firmware/testing/current/firmware.zip
unzip firmware.zip firmware-amd-graphics*.deb

Copy this .deb package into your pendrive, unmount it and plug it into your secure computer system.

8b. Installing the AMD graphics firmware

First login into the system on another TTY by pressing Crtl + Alt + F3 by providing your user and password. Afterwards we will create a new folder as mounting point for your pendrive, mount it, and install the .deb package. You will need the identifier for your pendrive partition. You can find it out by using “lsblk” for instance. In my case it’s /dev/sdb1.

sudo mkdir /pendrive
sudo mount /dev/sbd1 /pendrive
cd /pendrive
sudo apt install ./fireware-amd-graphics*.deb
cd /
sudo umount /dev/sdb1

After having installed the graphics firmware you can now unplug your pendrive, reboot your system by issuing “reboot” and enjoy PureOS welcoming you.

Tags: Full Disk Encryption, Ubuntu Linux, Dropbear, SSH
Last update: Dec 2019

Some of you are security-aware and would like to install a full disk encryption on a new system. But you’ll face a problem: Once the machine reboots and you’re not around to type in the password, the machine will simply not boot up. For come over that issue you can use a small SSH listener called Dropbear which loads up during the very beginning of the boot process. Only if you authenticate with your correct RSA key, you can log on to the machine, provide the password for uncrypting the filesystem and will be kicked out again while the machine will finish its bootup.

Prerequisites:
– Freshly installed and encrypted Ubuntu 18.04 server (headless installation – no GUI).
– You should know how to use the linux terminal and the text editor nano.
– I advice you to tell your DHCP router to provide always the same IP to the machine. Otherwise the IP will change/increment every time you boot it up.

Steps:
1. Let’s ensure we have all updates installed:

sudo apt update
sudo apt dist-upgrade

Install the required additional dropbear package:

sudo apt-get --assume-yes install dropbear-initramfs

You’ll notice that during package installation some keys will be automatically generated:
– DSA 1024 key for root
– RSA 2048 key for root
– ECDSA521 key for root

2. Edit the config file:

sudo nano /etc/dropbear-initramfs/config

Uncomment the DROPBEAR_OPTIONS line and add a second port where SSH should listen on:

DROPBEAR_OPTIONS=“-p YOUR_PORT“

3. Since only public key authentication is allowed we need to create and fill up our authorized_keys file:

sudo nano /etc/dropbear-initramfs/authorized_keys

Fill it with the only allowed command and append your ssh-rsa key:

command="/bin/cryptroot-unlock" ssh-rsa YOUR_KEY

4. Apply the changes and reboot:

sudo update-initramfs -u
sudo reboot

5. Now you can login to your machine for instance with:

ssh root@MACHINE_IP -p YOUR_PORT -i ~/.ssh/YOUR_KEY_FILE

Credits:
– https://hamy.io/post/0009/how-to-install-luks-encrypted-ubuntu-18.04.x-server-and-enable-remote-unlocking/
– https://www.pbworks.net/ubuntu-guide-dropbear-ssh-server-to-unlock-luks-encrypted-pc/
– https://seeseekey.net/archive/122144/ (Hetzner specific)

Tags: amd trustzone, amd psp, amd secure technology
Last update: jun 2018

Technological overview

ARM, originally Acorn RISC Machine, is a set of architectures for computer processors. In 2004 ARM developed TrustZone – an optional extension for processors which provide a secure execution environment (source 01). In 2012 AMD announced the integration of ARM’s TrustZone into their first Accelerated Processing Units (APU). Similar to the integration of the Intel Management Engine (link) those extension is also placed close to the CPU (source 02). This implementation has been renamed to the “AMD Platform Security Processor” (PSP) (source 03).

Interim conclusion

The computer is running AMD Secure Technology all the time. Invisible. Even if the PC is powered off. But wait, is that a problem? People who are keen on security and try to avoid risks are noticing it immediately: If there is an underlying second operating system – do we have control over it? How secure is this at all? Is there a way to disable AMD PSP / AMD Secure Technology?

Documentation

To Answer those questions we need to check out if there is a sufficient documentation out there which allows to comprehend all mechanisms and we need to watch out for possible security flaws.

AMD PSP / AMD Secure Technology has been mentioned in chapter 2.14 of the BIOS and Kernel Developer’s Guide for AMD Familiy 16h Models 30h-3Fh for the first time. On page 156 you can find just a very brief summary of this technology.

Neither is there a hint how to disable those functionality in total or in parts, nor is the source code availabe to the public.

So as far as we know AMD PSP / AMD Secure Technology can’t be disabled at all. The AMD Secure Technology is integrated into all intel desktop, mobile and server systems since 2014.

Security vulnerabilities and exploits

Also in AMD PSP vulnerabilities have been found. It was possible to craft a certificate to get code execution rights on the AMD Secure Processor and to infiltrate AMD’s security subsystem (source 04).

This management engine is definitely running. The lack of an ordinary documentation leads inevitable to security holes which represent a not only potentional but and proven risk to data and computer security.

Is there a solution to this?

• Vendor updates: There is no known method to fix vulnerabilities except updating the AMD Secure Technlology firmware by the vendor/oem.
• Trying to deactivate AMD Secure Technology: Some vendors like Asrock and Gigabyte have implemented a switch called “BIOS PSP Support” into their UEFI BIOS. Unfortunately there is no description what this switch acutally does.
• Buying hardware without this technology: Please refer to CPU and system alternatives without Intel ME iAMT and AMD PSP / Secure Technology.

Sources

• 01: Wikipedia ARM Architektur [DE]
• 02: Golem.de AMD integriert ARM-Chips in seine Prozessoren [DE]
• 03: regonline.com Secure Hardware and the Creation of an Open Trusted Ecosystem [EN]
• 04: bleepingcomputer.com Security flaw in AMDs Secure Chip on Chip Processor [EN]

Tags: computer system without intel me, amd psp
Last update: Jan 2021

Due to a lack of documentation and possiblities to deactivate these “secure execution environments” those can’t be disabled on our own. If you are interested you can read some more details about Intel ME/iAMT and AMD Platform Secure Processor / AMD Secure Technology. This article is providing an overview about possible solutions. From today’s point of view there a several options and we’ll discuss every of them:

• Option 1: Getting compatible hardware and flashing Libreboot on your own
• Option 2: Buying an already flashed device with Libreboot
• Option 3: Getting compatible hardware and flashing Coreboot on your own
• Option 4: Buying an already Coreboot-compatible modern Notebook
• Option 5: Get an opensource SoC / single board computer
• Mandatory: Use an operating system which is free from proprietary undocumented code

So let’s get started 😉

Option 1: Getting compatible hardware and flashing Libreboot on your own

Libreboot is a free BIOS/UEFI replacement which aims to completely omit any proprietary binary blobs within the firmware. If you are a hardliner and accept only free and blob-free solutions, then you should try to stick to Libreboot first. Unfortunately there is so few rather old compatible hardware, that in most cases you’ll find it insufficient. Please check their website for more details. To make it short: In my opinion the most promising candidates are:

Desktop and Server boards

• Gigabyte GA-G41M-ES2L desktop board
• Asus KCMA-D8 server board + AMD Opteron 4200 series CPU
• Asus KGPE-D16 server board + AMD Opteron 6200 series CPU

Notebooks

• Lenovo ThinkPad X60 / X60s / T60 / T60 Tablet
• Lenovo ThinkPad X200 / X200s / X200 Tablet / R400 / T400 / T400s / T500 / W500
• Apple MacBook 2,1

Option 2: Buying an already flashed device with Libreboot

If you don’t want to take the risk of a possibly broken device there are suppliers who are selling some of the above mentioned, just already flashed for you:

• https://www.flashedtech.com
• https://shop.libiquity.com
• https://tehnoetic.com
• https://store.vikings.net

Option 3: Getting compatible hardware and flashing Coreboot on your own

Coreboot is a firmware for mainboards where most of the proprietary code has been removed, but not all of it. Especially in quite modern computers there are some (closed and non-free) parts needed, to boot up the computer. All other parts or the system are opensource and can be viewed publicly. Currently as I write those letters there is a bunch of supported mainboards which work with Coreboot. Among the official mainboard-specific documentation list there are for instance:

Mainboards

• ASRock H81M-HDS (Intel Socket 1150)
• ASRock H110M-DVS (Intel Socket 1151)
• Asus F2A85-M (AMD Socket FM2)
• Asus P5Q (Intel Socket 775)
• Asus P8H61-M LX (Intel Socket 1155)
• Asus P8H61-M Pro (Intel Socket 1155)
• Asus P8Z77-M Pro (Intel Socket 1155)
• Gigabyte GA-H61M-S2PV (Intel Socket 1155)
• Intel DG43GT (Intel Socket 775)
• MSI MS-7707 (Intel Socket 1155)

Systems

• Dell Optiplex 9010 SFF
• HP Compaq 8200 Elite SFF
• HP Z220 Workstation SFF
• HP EliteBook 2560p
• HP EliteBook 8760w
• Purism Librem Mini
• System76 Lemur Pro

Tutorial available

I have build up my own custom system based on an Asus F2A85-M mainboard together with an AMD A10-5800K APU. If this way is suitable for you, you can follow the tutorial and build up a system on your own. If you are not satisfied with my choice of the processor, you can check out the elaboration on AMD Processors without AMD PSP / Secure Technology.

Option 4: Buying an already Coreboot-compatible modern Notebook

With an awareness of increased security new manufacturers emerge selling specialized notebooks. For instance:

• Purism Librem 14
• Purism Librem 15
• System76 Galago Pro, Lemur Pro and others

Option 5: Get an open source SoC / single board computer

Alternatively to the classical x86/x64 world there is also the possibility of using an ARM based system on a chip (SoC). Please find some of the common used boards below and feel free to search for new ones. Especially the quite performant boards by Olimex are certified by the Open Source Hardware Association. I recommend to get rid of the trusted execution environment (TEE) by using Crust: a libre firmware for Allwinner SoCs.

Vendor / Model	SoC architecture	Linux / FreeBSD?	Execution Environment free?	Notes
Libre Computer Board ALL-H3-CC (Tritium)	Allwinner H3 (ARM Cortex A7 or A53)	yes / yes	probably no	Only open schematics available.
Beagle Board Black	Sitara AM335 (ARM Cortex A8)	yes / yes	yes	Implementation of TrustZone is limited by TI to high-volume customers. Documentation available.
OLIMEX Ltd OLinuXino	Allwinner A20, A64 (ARM Cortex A7 or A53)	yes / yes	A20: yes A64: possible	All A20 and A64 boards are open source hardware. Documentation available.

Mandatory: Use an operating system which is free from proprietary undocumented code

The openest hardware isn’t good enough if you use an operating system which isn’t free. You might want to have a quick look on the pinetree of open and secure computing to get a short idea about the relevance of open hard- and software. In the following table you’ll find free and available operating systems. Futher operating systems can be found at gnu.org.

Name	Free (as in freedom)?	Project active?	Available Arch	Notes
Parabola	yes	yes	x64, i686, ARMv7	based on Arch
PureOS	yes	yes	x64	based on Debian
Trisquel	yes	yes	x64	based on Ubuntu
Uruk	yes	yes	x64	based on Trisquel/Ubuntu
Guix	yes	yes	x64, i686, ARMv7, AArch64	advanced GNU OS

Sources

• developer.amd.com: Developer Guides, Manuals & ISA Documents [EN]

Tags: meltdown, intel cpu vulnerability
Last update: Aug 2020

1. Einleitung

Unsere heutigen gewöhnlichen Computersysteme funktionieren nach dem Prinzip der sog. Von-Neumann-Architektur nach welcher es im Computer einen gemeinsamen Speicher gibt, der sowohl Programmbefehle als auch Daten hält. Mit Daten sind unsere gewöhnlichen Nutzdaten gemeint, die wir als Nutzer speichern und verarbeiten. Da sich dies nur in dem für den Nutzer vorgesehenen Bereich des Betriebssystems abspielt, spricht man daher auch von User-Space. Programmbefehle hingehen liegen ausschließlich in der Hoheit des Betriebssystems, da sie das gesamte System steuern. Diesen Bereich nennt man Kernel-Space. Aufgabe eines guten Betriebssystems ist es diese beiden Speicherbereiche perfekt zu isolieren. Ein gewöhnlicher Benutzer sollte im Rechnerbetrieb niemals Zugriff auf Daten erlangen, die eigentümlich nur der Rechnersteuerung dienen. Das mag erstmal etwas unbedeutend klingen, aber sobald wir uns vorstellen, dass auf heutigen Betriebssystemen mehrere Benutzer oder Kunden gleichzeitig angemeldet sein können, wird das Problem offenbar: Der Kern des Betriebssystems (Kernel) speichert in seinem eigenen isolierten Speicherbereich (Kernel-Space) nicht nur potentiell sensitive Daten von uns als angemeldetem Benutzer, sondern auch von allen anderen Benutzern, die angemeldet sind. Wenn wir nun in der Lage wären den ganzen Kernel-Space auszulesen, dann würden uns sämtliche Informationen in die Hände fallen, die das Betriebssystem mit allen Mitteln der Isolation zu schützen versucht.

2. Problem

Mit der Meltdown genannten Technik ist es aber als Benutzer möglich den Speicherbereich des Kernels über einen Umweg auszulesen! Weil dieses Auslesen nicht direkt geschieht, sondern über einen Umweg realisiert wird, nennt man dies eine sog. Seitenkanal-Attacke. Diese Seitenkanal-Attacke wird erst durch die sog. Out of Order Execution und spekulative Ausführung ermöglicht.

3. Out of Order Execution und spekulative Ausführung

Moderne Prozessoren versuchen aus Gründen aus Auslastung und Performance so viele Befehle wie möglich auszuführen. Man muss sich das derart vorstellen, dass ein Prozessor die Programmbefehle nicht linear hintereinander bekommt und ausführt, sondern die Befehle in einem Bündel vom Betriebssystem erhält und dann „so gut es ihm gefällt“ sortiert. Es kann Befehle geben die sich für den Prozessor „gut“ sortieren lassen, weil sie sich unabhängig voneinander verarbeiten lassen wie beispielsweise:

a = 1 + 3;
b = 2 + 4;

Und es kann Befehle geben, die sich gegenseitig bedingen:

a = 1 + 3;
b = a + 4;

Hier muss der Prozessor auf die komplette Abarbeitung der ersten Zeile warten, weil die berechnete Variable a für die zweite Zeile benötigt wird.

Wir sehen also, dass der Prozessor die anstehenden Befehle nicht immer linear (In-Order) abarbeitet, sondern aus Gründen der Performance stets versucht unabhängige Befehle parallel (Out-of-Order) auszuführen. Diese Möglichkeit Befehle parallel zu verarbeiten ist die Grundlage dafür, dass der Prozessor sich fragt welche Befehle überhaupt als nächstes parallel ausgeführt werden können. Auf der Suche nach dem nächsten Befehl, welcher zur Abarbeitung geeignet sein könnte, bedient er sich seiner eigenen Vorhersage. Im Grunde versucht der Prozessor den nächsten wahrscheinlichen Befehl zu erraten und spekuliert somit auf dessen nächste Ausführung. Das bedeutet insgesamt, dass der Prozessor Befehle vorab ausführt, bevor sie eigentlich an der Reihe sind, ohne zu wissen, ob diese überhaupt benötigt sein werden. Daher der Name der spekulativen Ausführung. Das Kalkül für den Prozessor ist relativ einfach: Falls das Ergebnis des Befehls tatsächlich benötigt wird, so ist der Befehl bereits ausgeführt worden und das Ergebnis kann sehr schnell geladen werden. Im anderen Fall müssten die Befehle erst neu sortiert, die dafür nötigen Daten/Ressourcen geholt und der Befehl ausgeführt werden. Dies ist viel aufwändiger und kostet deshalb deutlich mehr Zeit.

Wir merken uns: Wenn wir irgendwie merken könnten, dass bestimmte Ergebnisse besonders schnell geliefert werden können, dann wüssten wir, dass diese vorher bereits abgearbeitet worden sind.

4. Ein konkretes Beispiel

Wir nehmen an wir haben einen gemeinsamen Speicherbereich von 0 bis 15 und davon sind dem Benutzer 0 bis 11 und dem Betriebssystem-Kern 12 bis 15 zugewiesen.

Adresse	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Inhalt													1	3	3	7
													▲

Wir als normaler Benutzer geben in einem Programm den Befehl aus, auf die Position Nr. 12 in diesem Speicherbereich zuzugreifen:

my_precious = read(12);

welcher jedoch zum Kernel-Space gehört und auf den wir deshalb keine Berechtigung haben zuzugreifen. Das Betriebssystem liefert uns daraufhin einen Fehler (Segmentation Fault) zurück, weil wir nicht berechtigt sind auf Speicherbereiche des Betriebssystems zuzugreifen und bricht unser Programm folgerichtig ab. Es ist für uns nicht möglich den Wert my_precious ausgeben zu lassen.

Da der Prozessor seine Befehle jedoch sortiert und diese spekulativ ausführt, führt dies dazu, dass der Speicherzugriff tatsächlich im System stattfindet. Nur mit der Einschränkung, dass das Betriebssystem uns diese Information nicht weitergeben darf. Diese Ausführung von spekulativen Befehlen ist Kern des Problems von Meltdown, denn sie findet statt, ohne dass vorher geprüft wird, ob der Benutzer dies überhaupt darf. Dadurch, dass der Befehl bereits ausgeführt wurde, befindet sich – und das ist besonders wichtig – das Ergebnis tatsächlich ab diesem Zeitpunkt im Zwischenspeicher (Cache) des Prozessors. Der Prozessor weiß zu diesem Zeitpunkt noch gar nicht, ob dieser Befehl gleich tatsächlich noch benötigt wird oder nicht, aber das Ergebnis befindet sich jetzt im Zwischenspeicher. Falls der Prozessor merkt, dass der Befehl falsch vorhergesagt wurde, dann werden zwar die fälschlich angenommenen Befehle aus der internen Befehlskette (Pipeline) entfernt, die errechneten Ergebniswerte bleiben jedoch weiterhin im Zwischenspeicher bestehen.

Kommen wir zu unserem Speicherbereich mit den 16 Positionen zurück. Wir wissen nun, dass unser Befehl des Zugriffs auf Adresse 12 stattgefunden hat und dass das Ergebnis im Zwischenspeicher des Prozessors liegt. Alle anderen 15 Adressen liegen nicht irgendwo im Zwischenspeicher, weil wir keine Operationen hierzu abgesetzt haben. Wir merken uns an dieser Stelle ergänzend im Hinterkopf: Ein Eintrag wurde bereits verarbeitet und dieser Wert befindet sich irgendwo im Zwischenspeicher des Prozessors.

5. Indirekter Zugriff auf den Kernel-Space

Wie kommen wir an diesen zwischengespeicherten Wert heran?

• Im ersten Schritt allozieren wir uns als normaler Benutzer einen Speicherbereich A mit der Adresse 0.
• Dann lassen wir einen Befehl spekulativ ausführen, welcher die Adresse 12 einliest. Wir wissen zwar noch nicht, dass dort die Zahl 1 gespeichert ist, aber wir nehmen das zum Verständnis einfach mal an. Das Ergebnis des Lesezugriffs (auf Adresse 12) soll nun an die Adresse A + B geschrieben werden (also an die Stelle 0 + 1 = 1).
• Jetzt lesen wir nacheinander die uns erreichbaren Stellen 0 bis 11 aus und messen die Zeiten, die das System für den Lesezugriff braucht.
  Bei Adresse 0 ist der Zugriff langsam (z. B. 450ms).
  Bei Adresse 1 ist der Zugriff besonders schnell (z. B. 200ms).
  Bei Adresse 2 ist der Zugriff wieder langsam (z. B. 430ms)
  Usw.

Wir haben über den Umweg der Zeitmessung die Tatsache entdeckt, dass die Adresse 1 besonders schnell ausgelesen werden konnte. Und hier wird die Schönheit von Meltdown offenbar: Dadurch, dass wir bei Adresse 1 einen besonders schnellen Zugriff sehen, wissen wir, dass dieser Wert nicht erst wie die anderen Adressen berechnet/geholt werden musste, sondern dass dieser Wert sich bereits im Zwischenspeicher des Prozessors befunden haben muss. Anders ist diese besonders schnelle Lesezeit nicht möglich.

Das Elegante dabei ist, dass wir das Ergebnis an die Adresse A+B haben schreiben lassen. Da wir A ohnehin kennen, können wir nun direkt anhand des Abstands ablesen, welcher Wert bei Adresse 12 gestanden haben muss. Wir betrachten nämlich nun die Entfernung zwischen Adresse 0 und der Adresse die sich besonders schnell auslesen lässt (hier: 1) und wissen nun, dass der Wert bei Adresse 12 ebenfalls 1 ist.

• Nachdem wir nun den Wert von Adresse 12 ermittelt haben, können wir im nächsten Durchgang einen Befehl spekulativ ausführen lassen, der die nächste Adresse 13 einliest usw.

In dieser Form lässt sich der gesamte (!) Kernel-Space komplett auslesen. Aus diesem Grunde wird Meltdown oft als eine der größten je gefunden Schwachstellen in Prozessorarchitekturen genannt.

6. Quellen & Weiterlesen

• „Meltdown: Reading Kernel Memory from User Space“ von Moritz Lipp et al.
• „Analyse und Erklärung zu den Meltdown und Spectre Sicherheitsproblemen“ von Patrick Dreker
• „A Simplified Explanation of the ‚Meltdown‘ CPU Vulnerability“ von Brad Robinson
• „Meltdown: Eine Erklärung für den Laien oder Lesefaulen“ von Thomas Christlieb