Local content


Regular booting

The Unified Extensible Firmware Interface (UEFI) specification includes a boot manager, which starts the OS boot loader or kernel.


The Unified Extensible Firmware Interface (UEFI)is a publicly available specification that defines a software interface between an operating system and platform firmware. UEFI replaces the legacy Basic Input/Output System (BIOS) firmware interface. UEFI can support remote diagnostics and repair of computers, even with no operating system installed.

Intel developed the original Extensible Firmware Interface (EFI) specifications. The Unified EFI Forum is the industry body that manages the UEFI specifications throughout.

The Linux kernel has been able to use EFI at boot time since early 2000s, using the elilo EFI boot loader or, more recently, EFI versions of GRUB.

UEFI defines a boot manager as part of the UEFI specification (it does not rely on boot sectors). When a computer is powered on, the boot manager checks the boot configuration and based on its settings, then executes the specified OS boot loader or operating system kernel. The boot configuration is defined by variables stored in NVRAM, including variables that indicate the file system paths to OS loaders or OS kernels.

UEFI provides a shell environment, which can be used to execute other UEFI applications, including UEFI boot loaders.

DebbyBuster has the InsydeH2O BIOS (the Insyde Software (Taiwan) implementation of the Intel Platform Innovation Framework for UEFI/EFI).


GRUB (GRand Unified Bootloader) can be used to boot most operating system on the intel platforms. There are two versions: Grub Legacy (Grub 1) and Grub 2. What do I have?

Secure booting

UEFI Secure Boot and Shim

The UEFI 2.3.1 Errata C specification (or higher) defines a protocol known as Secure Boot, which can secure the boot process by preventing the loading of UEFI drivers or OS boot loaders that are not signed with an acceptable digital signature. Supported by Debian since Debian 10.

Shim is a boot loader to chain-load signed boot loaders under Secure Boot. Shim becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.

Windows 10 allows OEMs to decide whether or not Secure Boot can be managed by users of their x86 systems. The Machine Owner Key (MOK) allows you to add signed files.

Finding out your status: Installed shim files: SELinux

Kernel security/encryption

Linux kernel crypto API

The kernel crypto API serves the following entity types: Documentation


Device-mapper is infrastructure in the Linux kernel that provides a generic way to create virtual layers of block devices.

Device-mapper crypt target provides transparent encryption of block devices using the kernel crypto API.

The user can basically specify a symmetric ciphers, an encryption mode, a key, an iv generation mode and then the user can create a new block device in /dev. Writes to this device will be encrypted and reads decrypted. One can mount the filesystem on it as usual or stack dm-crypt device with another device like RAID or LVM volume.


Policy-Based Decryption (PBD) is a collection of technologies that enable unlocking encrypted root and secondary volumes of hard drives on physical and virtual machines. PBD uses a variety of unlocking methods, such as user passwords, a Trusted Platform Module (TPM) device, a PKCS #11 device connected to a system, for example, a smart card, or a special network server.

Network Bound Disc Encryption (NBDE) is a subcategory of PBD that allows binding encrypted volumes to a special network server.

Security checking


Linux Distributions

D-bus middleware

D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed.

D-Bus supplies both a system daemon (for events such as "new hardware device added" or "printer queue changed") and a per-user-login-session daemon (for general IPC needs among user applications). Also, the message bus is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon). Currently the communicating applications are on one computer, or through unencrypted TCP/IP suitable for use behind a firewall with shared NFS home directories.


Display servers

Application level encryption

General interest

Hardware, support, consulting

Linux mobile

Linux media servers and music applications

Linux and language

Raspberry Pi

Backing up a Windows PC