Compiling dom0 kernel for notebook from source code guide

Community Guides
, ,
1

Currently in progress…

Why is this necessary:
Qubes OS prioritizes security over usability. This is especially noticeable on my Asus laptop, and I experienced a number of issues that couldn’t be resolved otherwise:

  1. Inefficient laptop performance and excessive heating. My laptop has an AMD integrated GPU (along with the CPU) and a separate NVIDIA GPU. The NVIDIA GPU was constantly running, even when hidden from dom0. Power was supplied to the GPU and it was actively heating up. The fans were humming like a jet, while the laptop remained at 80-90 degrees Celsius when idle. This significantly reduced the lifespan of almost all the laptop’s components. There was no way to disable this behavior (except by physically removing the graphics card, which is not a very sensible solution).
  2. Inability to control the maximum battery charge level. Modern laptops, to preserve battery life when constantly plugged in, limit the maximum charge level to 40-60%. 3. The banal discomfort of point 1, when a hot wind constantly blows from the laptop.

Security risks: There are only two.

  1. Hotplug PCIe is disabled by the QubesOS developers for security reasons. Enabling it opens the door to attacks with physical access to the device via the Thunderbolt port. However, my personal opinion is that this is a huge sacrifice in convenience for a very small security gain. If an attacker has physical access to a running device, they have hundreds of other possible attacks, some more effective. + My laptop doesn’t have this port.

  2. The Qubes OS dom0 kernel is included by default in the QubesOS repositories and is signed by the QubesOS developers. If your build system is infected or hostile, the dom0 kernel will be infected, as will the entire dom0 kernel, meaning QubesOS is completely compromised.

Requirements:
Proficiency in Linux console
A device running x64 (preferably tested) with network access, 16GB RAM, and 20GB of free disk space.
A GitHub account

This guide is designed for a build performed on a dedicated server/device, outside of QubesOS. In theory, it can easily be adapted for building in Qubes by simply changing a couple of lines (docker->dispvm).

Instructions:
We will use tools from the QubesOS developers for the build.

  1. git clone GitHub - QubesOS/qubes-builderv2: Next generation of Qubes OS builder · GitHub

  2. The builder contains a bug that prevents the ignore signature flag from being applied correctly during the build, and your build will inevitably fail. Anyone with programming skills can help us create a less dirty hack. For now, let’s go to qubes-builderv2/qubesbuilder/plugins/fetch/scripts
    /get-and-verify-source.py and replace a few lines.

"verify = True
if insecure_skip_checking:
verify = False
elif less_secure_signed_commits_sufficient:
check = “signed-tag-or-commit”
elif args.git_commit:

user specified pre-verified commit-id

verify = False"

Change to
"
insecure_skip_checking = True
verify = False
"

As a result, the build won’t check the signature of each Github commit (we can’t sign our edits with the Qubes developers’ keys).

  1. Go to GitHub and fork the kernel repository
    GitHub - QubesOS/qubes-linux-kernel: Qubes component: linux-kernel · GitHub
  2. Go to your GitHub repository in the config-base file and change exactly one line:
    “# CONFIG_HOTPLUG_PCI_CPCI is not set”
    Change to

“CONFIG_HOTPLUG_PCI_CPCI=y”

  1. THIS IS A TEMPORARY FIX DUE TO A BUG IN THE ORIGINAL QUBES KERNEL REPOSITORY. The QubesOS authors enable rust flags in a kernel version that doesn’t support rust flags.

Go to the gen-config file in your repository and remove the behavior where the build fails due to the inability to apply the kernel flag:

Delete line 49. Remove lines 54-55 and replace them with “printf ‘WARNING: Local config setting for %s didn’t make it into the final config (ignored)’ “$cfg””

Replace line 61 “exit $rc” with “exit 0”

  1. Optional: open the version file and change the kernel version to the latest one from kernel.org of the same global version, in our case 6.19.5->6.19.10. Because why not, and why should we be stuck with an old kernel?

This concludes the edits to GitHub.

  1. Return to your Linux OS/VPS/build environment
    In the Qubes-builderv2 directory, create a builder.yaml file with the following content:
    "git:
    baseurl: https://github.com
    prefix: QubesOS/qubes-
    branch: release4.3
    maintainers:
    • ‘0064428F455451B3EBE78A7F063938BA42CFA724’
    • ‘274E12AB03F2FE293765FC06DA0434BC706E1FCF’

backend-vmm: xen
debug: true
verbose: true
qubes-release: r4.3

distributions:

  • host-fcrq

components:

executor:
type: docker
options:
image: “qubes-builder-fedora:latest”
clean: True
cpus: “0.000”

stages:

  • fetch
  • prep
  • build
  • post
  • verify
  • sign:
    executor:
    type: local
  • publish:
    executor:
    type: local"
  1. Make sure you have Python 3.11 or later installed. If you have an older version, any llm will tell you how to update.
  2. Install dependencies according to the instructions at GitHub - dill-shower/qubes-builderv2: Next generation of Qubes OS builder · GitHub
  3. Prepare the Docker container: $ tools/generate-container-image.sh docker (the command is correct; you don’t need to install Fedora 36 as in the original documentation; even on Fedora 42, the kernel for Fedora 37 builds successfully).
  4. $ ./qb package fetch prep build
  5. Wait… Building the kernel takes time, about 10 minutes on a 256-core processor; on a standard device, it can take up to an hour.
  6. Go to repository/host… I don’t remember the exact path, but the RPM files will be there. We only need kernel-latest and without src in the name.
  7. Transfer and copy to dom0
  8. sudo dnf install ./*rpm or list all the files to install this way
  9. Restart QubesOS and grub will default to our kernel (since it’s the newest one)
  10. Enjoy life

This guide is based on personal experience. The text may look like llm due to Google Translate; English is not my native language.
If you have difficulty editing with git, I’ll try to attach all the modified files to this post or upload them to the hosting service if the Qubes forum doesn’t allow file uploads.

Transfer.it edited files and builder.yml

1 Like