Booster

Booster is a fast initramfs generator similar to mkinitcpio and dracut. Booster is inspired by distri project and aims to create a small and fast init image.

Booster consists of two major components:

Initramfs generator /usr/bin/booster user-space tool. It is responsible for initramfs image generation.
Generated images that are usually located at /boot/ and used by the system boot loader to boot Linux OS.

Install

Install booster. The package installation hook will generate initramfs images, one per installed kernel (e.g. for linux, linux-lts). The images are located under /boot directory:

$ ls -lh /boot/booster*

-rwxr-xr-x 1 root root 4.0M Dec 16 16:20 /boot/booster-linux.img

Optionally the image can build manually:

$ booster -output mybooster.img

Configuration

Booster generator configuration is located at /etc/booster.yaml. If there is no configuration file then the default configuration (host-specific images, no network) is used.

The configuration file helps to override the default behaviour. Here is a sample configuration:

/etc/booster.yaml

network:
  dhcp: on
  # 'dhcp' cannot be used together with 'ip'
  ip: 10.0.2.15/24
  gateway: 10.0.2.255
universal: false
modules: nvidia,kernel/sound/usb/
compression: none

network is for network configuration. If this node is omitted then no network is initialized at the boot time. The network can be configured with static ip (nodes ip and gateway) or with dhcp4 (node dhcp).

universal option enables universal images. Universal images include a large set of kernel drivers/tools. By default a host-specific image is generated, such images contain modules used by the current host only.

modules adds extra modules to the generated image. You can use reference modules either by its name or file path or path to directory with modules (directory name always ends with / symbol). Note that the booster generator resolves module dependencies and adds them to the image as well.

compression specifies compression for the output image. By default zstd is used. Other possible values are gzip and none.

Boot loader configuration

Once the image is generated it is time to configure the boot loader.

systemd-boot

To enable the new initramfs image with systemd-boot simply create a new boot loader entry like this one:

/boot/loader/entries/booster.conf

title Arch Linux with booster
linux /vmlinuz-linux
initrd /booster-linux.img
options root=UUID=08f83949-bcbb-47bb-bc17-089aaa59e17e rw

Where the root filesystem is referenced by UUID=08f83949-bcbb-47bb-bc17-089aaa59e17e. To find your root device UUID run blkid /dev/ROOTDEVICE.

Enable encryption

Booster supports LUKS based full disk encryption out of the box. Generator does not need any extra configuration. And for initramfs you need to append information about the LUKS partition where the root resides. This is done with either rd.luks.uuid=LUKSUUID or rd.luks.name=LUKSUUID=LUKSNAME kernel parameter that you need to specify in your boot loader configuration file. LUKSUUID specifies UUID of the encrypted LUKS partition that needs to be unlocked by booster. Pay attention that the UUID does not contain any quotes. LUKSNAME specifies name of the unlocked partition (as in /dev/mapper/NAME).

No image rebuild is required. Once the boot loader configuration is done, reboot the computer. After that you will see a Enter passphrase for YOURROOT: prompt at the boot time asking for a password for the encrypted root partition.

Clevis encryption

Note: Create a separate page for non-booster specific clevis information

Passwords manually entered by a user is a traditional and widely used way to unlock encrypted LUKS partitions. But it has a few disadvantages:

It requires manual intervention and thus does not work with setups that require automatic boot (e.g. a large server farm).
An average human brain is capable of remembering relatively simple passwords (~20-30 bits of entropy) that are much weaker than keys used for modern block ciphers (128/256 bits).

A solution for it would be encrypting data with a strong key stored securely somewhere else, for example at your TPM chip or YubiKey or some network service. Clevis is a framework that implements this idea. It allows to encrypt (in terms of clevis bind) data with a pluggable pin. Currently clevis implements 3 pins:

TPM2 data binding
Network service (called Tang) data binding
Shamir's Secret Sharing that allows you to combine other pins.

Booster supports all 3 types of pin.

To use clevis please install clevis package. Here is an example of data binding with TPM2 (works only if you have a TPM chip at your computer):

$ clevis encrypt tpm2 '{}' <<< 'hello, world'

eyJhbGciOiJkaXIiLCJjbGV2aXMiOnsicGluIjoidHBtMiIsInRwbTIiOnsiaGFzaCI6InNoYTI1NiIsImp3a19wcml2IjoiQU80QUlJQkxxT3FVenVDU1FmWkprNmdDN2wzMW43V3M2Y2FZd0VZS1BSR3Q0OHJEQUJBV2Z4M3pTUUNUTmtHZE9BM2FZd2RTZk9GcXZWdnVlQ3lPamFsWldCT2R4RlJKSzl5ZVRCM0pkNFktcF9HalhhNmlnLWxxNmtmMHZTWWkzOWMxVEpES1RYRVZTdnlXSlpEbGdxQ0JPMVNxeGJBd2tfSnIyRlRNY3hvNGtpSmNtMEVjbWd5dFdyME00QmcySlg4aVo3MEt1MTVjNzFORU5Ra3RjdGMtREhBVGFQcHJ2VzI2Z3d1YmUxckRfX19aV2tHaG9mX053M0M1OHlOcXF2RUpPZUwzNTZHNXJHNVVtYmUtWWV4Ujl2SEppZWlua3ZaNTJoMFVRYWVNSm9LYjJuNjlVTGZHb2J1NElTN20iLCJqd2tfcHViIjoiQUM0QUNBQUxBQUFFMGdBQUFCQUFJQ2poWDBVeTJKZVpSNU9pRU0ySktSeEtnUElYQ3dGNnRNR09NTDZ0ZnE5aiIsImtleSI6ImVjYyJ9fSwiZW5jIjoiQTI1NkdDTSJ9..1P2Emag_4k-GlhyY.MuQQYPa8QHrysZ74uA.0ddDxfZA3R-cCmaKu5yUZA

This long base64-encoded message is our text encrypted with an internal TPM key. It can be decrypted at the current computer only. Trying to decrypt it from another computer (or rather with another TPM chip) will return an error.

$ clevis decrypt tpm2 '{}' <<< 'eyJhbGciOiJkaXIiLCJjbGV2aXMiOnsicGluIjoidHBtMiIsInRwbTIiOnsiaGFzaCI6InNoYTI1NiIsImp3a19wcml2IjoiQU80QUlJQkxxT3FVenVDU1FmWkprNmdDN2wzMW43V3M2Y2FZd0VZS1BSR3Q0OHJEQUJBV2Z4M3pTUUNUTmtHZE9BM2FZd2RTZk9GcXZWdnVlQ3lPamFsWldCT2R4RlJKSzl5ZVRCM0pkNFktcF9HalhhNmlnLWxxNmtmMHZTWWkzOWMxVEpES1RYRVZTdnlXSlpEbGdxQ0JPMVNxeGJBd2tfSnIyRlRNY3hvNGtpSmNtMEVjbWd5dFdyME00QmcySlg4aVo3MEt1MTVjNzFORU5Ra3RjdGMtREhBVGFQcHJ2VzI2Z3d1YmUxckRfX19aV2tHaG9mX053M0M1OHlOcXF2RUpPZUwzNTZHNXJHNVVtYmUtWWV4Ujl2SEppZWlua3ZaNTJoMFVRYWVNSm9LYjJuNjlVTGZHb2J1NElTN20iLCJqd2tfcHViIjoiQUM0QUNBQUxBQUFFMGdBQUFCQUFJQ2poWDBVeTJKZVpSNU9pRU0ySktSeEtnUElYQ3dGNnRNR09NTDZ0ZnE5aiIsImtleSI6ImVjYyJ9fSwiZW5jIjoiQTI1NkdDTSJ9..1P2Emag_4k-GlhyY.MuQQYPa8QHrysZ74uA.0ddDxfZA3R-cCmaKu5yUZA'

hello, world

Clevis allows to bind LUKS partitions as well, e.g.

# clevis luks bind -d /dev/nvme0n1p2 tpm2 '{}'

Creates a LUKS slot with a password encrypted by your TPM chip. It can be verified by running

# cryptsetup luksDump /dev/nvme0n1p2

...
Tokens:
 0: clevis
   Keyslot:  1
...

It shows that one clevis token appeared. LUKS uses these tokens to store metadata about passwords stored somewhere else (e.g. at TPM chip). Please refer to clevis documentation for more information.

Booster is able to read the LUKS tokens, decode clevis information, reconstruct the password and unlock the partition automatically.

Partitions bound to tpm2 or sss pins do not require any booster-side configuration. Tang (network binding) pin requires network enabled. Please refer to #Configuration section for more information on network configuration.

Debug

If booster has issues and does not work as expected then please enable debug output that provides extra information about what is going on:

for generator there is a -debug command line flag: booster -debug.
for init there is a booster.debug=1 kernel parameter.

If you believe it is an issue with booster itself then please file a ticket here https://github.com/anatol/booster/issues

Booster

Contents