Kernel build bug - KVM_AMD and CRYPTO_DEV_CPP

About a week ago, I failed to build a Kernel for my new Ryzen 2700X working machine. After some time of configuring my kernel I run into some weird problems

The problem

I wanted to have a Kernel with KVM_AMD support enabled. The build was going on fine, until some weird linker errors appeared.

(Full output [Pastebin])

Since I'm a Kernel rookie, it took me some time to realize what was going on. A google search didn't revealed a solution, other than something similar on Unix Stackexchange, that was not directly applicable for my case.

The problem persisted and is reproducible in linux-4.17.1 and linux-4.16.15, using this config file. Building linux-4.14.49 was doing fine. For any options that were not defined by the config file I chose the default suggestion.


Workaround

The problem arises, if CONFIG_CRYPTO_DEV_CCP_DD is compiled as module [=m], also if the SEV is not used. Enabling CONFIG_CRYPTO_DEV_CCP_DD to be compiled in the kernel [=y] is a workaround for the issue.

This commit already revealed the issue.

I had to Include the "Secure Processor device driver", that is found in Cryptographic API > Hardware crypto devices

Weirdly, the suggested solution from Unix Stackexchange was not solving the problem for me, neither was it causing problems. I could build the Kernel (4.17.1) with "Kernel-based Virtual Machine Support" set as module. But those are just my two cents, it might have been an issue some versions ago ...

Unluckily I cannot contribute to Unix Stackexchange yet (not enough reputation *sigh*), so I cannot improve the answer there.

Thanks to Richard!

Many thanks to Richard, who provided me with support, regarding nailing it down to a bug in the Kernel build system.

Getting VeraCrypt running on a custom build Kernel

Having your own compiled Linux Kernel is a nice thing for various reasons. First, you are not stuck with the (depending on your distribution possibly outdated) Kernel versions your distribution and you highly customize your experience. Some people want to have a super-fast lightweight Kernel, I'm more on the other side of the spectrum. But that's a matter of flavor.

A side-effect is that you learn a lot more about Linux - inevitably issues will arise, from not working KVM (upcoming post) because of iptable issues to VeraCrypt that cannot operate with Kernel support.


Getting your custom Kernel ready for VeraCrypt

I've encountered the following error

device-mapper: reload ioctl on veracrypt1 failed: Invalid argument
Command failed

I've started with that. ioctl based errors normally are a good indicator that something in your Kernel configuration is or missing or misconfigured.
In this case it was the missing support for crypto targets in the device mapper (I suppose).

Fortunately the Gentoo-Forums provide some very useful informations. Make sure you have configured the following options in your Kernel

Device Drivers --->
[*] Multiple devices driver support (RAID and LVM) --->
<*> Device mapper support
<*> Crypt target support
[*] Block Devices --->
<*> Loopback device support
File systems --->
<*> FUSE (Filesystem in Userspace) support
[*] Cryptographic API --->
<*> RIPEMD-160 digest algorithm
<*> SHA384 and SHA512 digest algorithms
<*> Whirlpool digest algorithms
<*> LRW support
<*> XTS support
<*> AES cipher algorithms
<*> Serpent cipher algorithm
<*> Twofish cipher algorithm

Re-build your Kernel, and everything should work fine 🙂

Ubuntu - Building own Kernel

One of the reasons why I like Ubuntu is its simple usage. Most stuff works out-of-the-box or is configurable pretty easy. So it's also pretty easy to compile your own kernel.

The reason I wanted to build my own kernel were some issues with the amdgpu graphics card. Since Kernel 4.15 AMD has pushed it's recent open-source drivers upstream, so I wanted to give it a try.

In a nutshell

In principle you have to follow those simple steps

  1. MAKE SURE GRUB HAS A TIMEOUT so you can select an old kernel, in case something went wrong
  2. Download kernel sources from kernel.org
  3. Extract the sources into a directory and change into that directory
  4. Copy current configuration from /boot/config-uname -r to .config
  5. Check current configuration using make localmodconfig
  6. Compile using make [-j8]
  7. Install by using sudo make modules_install install

More details

For now I'm assuming we want to compile the current stable kernel, witch is 4.15.6

  1. Download kernel sources from kernel.org - I won't post a direct link to a kernel, because that will become outdated pretty soon!
  2. Extract the sources into a directory and change into that directory

I download the file and extract it with tar. For me it was like

In general it's save to hit the return key and just use the default values. But keep that in mind, if you run into problems you might have a more detailed look and the options

Now it's time to compile the kernel. Use -j4 to use 4 threads for building. I in general use up to 16, but that depends on your system. People report in general good results in taking a number between 1x and 2x the number of CPU cores you have. I have 8, so I choose 16, but that's up to you

Now watch the build process and grab a cup of coffee. That might take a while ....

If the build process completes, then run a simply a make modules_install and make install to install the new kernel

In Ubuntu this triggers a grub-update as well, so it should work the next time you boot into your system.

Nice 🙂

Privilege escalation bug in Linux Kernel

... and how to deal with it right:

Bug filed and fixed on February 17, patches are already in circulation. Exploit will be made available in some days to allow the administrators to update.

The fix was just a two-liner but still: Fixed-on-the-same-day-as-filed. That's how it should work 🙂

And in the Windows world we still have unpatched Zero-day exploits, after three months of responsible disclosure. THREE MONTHS!! STILL UNPATCHED!!

Hello World Kernel Module

Heute geht's um Linux Kernel Module.

Ich zeige euch, wie ihr ein ganz simples "Hello World!" Modul erstellen könnt.

Ich benutze die Shell und einen Texteditor. Mehr brauchst du nicht für dein erstes Kernel-Modul!

 

Benötigte Vorkenntnisse

  • Linux - sudo und Root-Rechte
  • Texteditor
  • gcc
  • Makefile
  • C

Los geht's!

Und wir legen los. Am besten erstellst du ein neues Verzeichnis (ich arbeite im temp/hello_kernel Ordner) für das ganze

Und genau hier wird nun die datei module.c mit dem folgenden Inhalt erstellt. Die Datei könnt ihr hier downloaden.

Damit öffnet ihr vi als Texteditor und schreibt nun folgenden Inhalt in die Datei (i eingeben, um in den INSERT-Mode zu kommen).
(Randbemerkung: Hier gibt die Vi-Cheat Sheats. Ausdrucken und an die Wand nageln!!)
#include <linux/module.h>
MODULE_AUTHOR("Flex");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_DESCRIPTION("Hello World module");
static int start__module(void) {
/* Use printk for debug prints of a kernel module */
printk(KERN_INFO " *** Hello linux! *** \n");
/* There are eight Loglevel-Strings, defined in <linux/kernel.h> */
/* (More precise: /linux/printk.h) */
/*
* #define KERN_EMERG
* #define KERN_ALERT
* #define KERN_CRIT
* #define KERN_ERR
* #define KERN_WARNING
* #define KERN_NOTICE
* #define KERN_INFO
* #define KERN_DEBUG
*
*/
/* Always use return 0 instant of EXIT_SUCCESS. On the
* kernel level, we return with 0 on success!
*/
return 0;
}
static void end__module(void) {
printk(KERN_INFO " *** Hello module exit *** \n");
}
/* This pointers design the entrance end exit functions of the module */
module_init(start__module);
module_exit(end__module);

Die Kommentare sollten für sich sprechen. mit STRG+C wechselt ihr in den Kommando-Modus von vi, und mit

Wird die Datei geschrieben und vi geschlossen.

Nur brauchen wir noch eine Makefile. Die Datei könnt ihr hier downloaden. Los gehts:

mit dem folgenden Inhalt

obj-m := module.o
PWD := $(shell pwd)
all:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) clean

 

Auf den genauen Inhalt will ich jetzt hier nicht eingehen. Betrachtet es einfach mal als von Gott gegeben, und benutzt die File. 😉

OK, nun wird das Modul kompiliert:

Fertig! Die Modul-Datei ist die module.ko, die brauchen wir nun.

 

Modul einbinden

Wir benutzen insmod mit Superuser-Rechten. Unter Ubuntu läuft mit sudo alles wunderbar

Und überprüft, ob das Modul geladen wurde

Sollte euch euer geladenes Modul anzeigen.

 

Nun wollen wir aber noch den Output vom printk anschauen. Das tool dazu ist dmesg. Wir pipen dmesg an tail, damit wir nur die letzten Zeilen erhalten.

gibt euch hoffentlich soetwas ähnliches wie die folgende Zeile aus:

Say hello to your little friend 🙂

 

Modul entfernen

Fertig. Wir pipen wieder dmesg an tail (Aber mit zwei Zeilen, damit wir sehen, wie lange das Modul gelaufen ist)

das Resultat schaut (hoffentlich) ungefähr so aus

Und so schaut das ganze am Bildschirm aus

Viel Spass beim Kernel-Hacking 🙂