Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save HardenedArray/ee3041c04165926fca02deca675effe1 to your computer and use it in GitHub Desktop.
Save HardenedArray/ee3041c04165926fca02deca675effe1 to your computer and use it in GitHub Desktop.
Efficient UEFI Encrypted Root and Swap Arch Linux Installation with an ENCRYPTED BOOT
# OBJECTIVE: Install Arch Linux with encrypted root and swap filesystems with an ENCRYPTED BOOT and boot from UEFI. We will
also decrypt and mount our entire encrypted system using a single LUKS passphrase entry.
# Note: This method supports both dedicated Arch installs and those who wish to install Arch on a multi-OS-UEFI booting system.
# External USB HDD/SSD Installers Notes: Encrypted Arch installs can be booted and run from an external USB HDD or SSD, but
# only when the installation is correctly set up. There are several necessary changes to my standard procedure you'll want
# to make during the install process. Read my External USB HDD/SSD Installation section below before proceeding.
# VirtualBox Installers Notes: This installation method can also be used to install Arch Linux as an UEFI-booting
# Guest system in VirtualBox. You must have UEFI-booting enabled in VBox's Guest System Settings prior to installation.
# I have written a separate guide dedicated to the specifics of achieving an encrypted Arch Linux VirtualBox installation.
# My Arch Linux VirtualBox Guest installation guide is available at:
https://gist.github.com/HardenedArray/d5b70681eca1d4e7cfb88df32cc4c7e6
# The official Arch installation guide contains details that you should refer to during this installation process.
# That guide resides at: https://wiki.archlinux.org/index.php/Installation_Guide
# Download the archlinux-*.iso image from https://www.archlinux.org/download/ and its GnuPG signature.
# Use gpg --verify to ensure your archlinux-*.iso is exactly what the Arch developers intended. For example:
$ gpg -v archlinux-2019.11.01-x86_64.iso.sig
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: assuming signed data in 'archlinux-2019.11.01-x86_64.iso'
gpg: Signature made Fri Nov 1 16:34:35 2019 UTC
gpg: using RSA key 4AA4767BBC9C4B1D18AE28B77F2D434B9741E8AC
gpg: using pgp trust model
gpg: Good signature from "Pierre Schmitz <pierre@archlinux.de>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4AA4 767B BC9C 4B1D 18AE 28B7 7F2D 434B 9741 E8AC
gpg: binary signature, digest algorithm SHA256, key algorithm rsa2048
# Burn the archlinux-*.iso to a 1+ Gb USB stick. On linux, do something like:
dd bs=4M if=archlinux-*.iso of=/dev/sdX status=progress oflag=sync
# If running Windows, use Rufus to burn the archlinux-*.iso to your USB stick in DD mode.
# Also, if you are running BitLocker to encrypt your Windows system, read my BitLocker notes below, before proceeding.
# UEFI-Boot from your USB stick. If your USB stick fails to boot, ensure that Secure Boot is disabled in your UEFI configuration.
# Set your keymap only if not you are not using the default English language.
# It is typically wiser to be hard wired to the Net during installation. However, Arch supports WiFi-only installs. Also
# note that in mid-2020 the Arch devs deprecrated the use of `wifi-menu`. The current installation images support `iwd`,
# which provides `iwctl`. Carefully note that `iwd` will NOT be installed on your new system. If you will require WiFi
# access following reboot, we install `iwd` in the pacstrap command and then enable it after we enter arch-chroot, below.
# Connect to WiFi using:
iwctl
# then to connect to your WiFi station; do something like:
station <wlan device name> connect <wifi-station-name tab-auto-complete>
# then enter your WiFi station's passphrase
# It is possible to access this guide from within your Arch installation environment using the built-in elinks text browser.
# For those interested, open a new terminal at tty2 using ctrl-alt-f2, then use elinks to search for 'HardenedArray Gists'
# which should return the URL of my Arch installation guide:
https://gist.github.com/HardenedArray/31915e3d73a4ae45adc0efa9ba458b07
# You can then return to your installation terminal using ctrl-alt-f1.
# Create and size partitions appropriate to your goals using gdisk.
# To support booting from an encrypted /boot, we need to set up our partitions differently and use a different LUKS encryption
# method than in my other guides.
# Create only the partitions you need. If you have an existing EFI partition, do NOT create a new one. We will mount that
# existing EFI partition and append our new Arch installation to it.
gdisk /dev/sdX
# Also note, we are intentionally NOT creating a separate /boot partition. Our separately encrypted /boot will reside
# as a directory under our encrypted root / filesystem. We need ONLY two partitions!
Partition Y = 100 MiB EFI partition # Hex code EF00
Partition Z = Choose a reasonable size for your encrypted root and swap system partition, or just size it to the
last sector of your drive. # Hex code 8300.
# Review your partitions with 'p'.
# Write your gdisk changes with 'w'.
# Reboot, if necessary, so the kernel reads your new partition structure.
,
# I strongly recommend you zero-out each of of your new partitions prior to creating filesystems on them. Obviously, multi-OS
# booters should NEVER zero-out an existing EFI partition. You can either use the Arch installer's ddrescue or, if you don't
# mind not having a progress indicator, it's more efficient to run:
cat /dev/zero > /dev/sdXY followed by
cat /dev/zero > /dev/sdXZ
# Create a filesystem for /efi. This step applies to NEW EFI installations ONLY!
mkfs.vfat -F 32 /dev/sdXY
# Encrypt and open your system partition
cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random --type luks1 luksFormat /dev/sdXZ
# Note our use of the critical '--type luks1' encryption switch. The default Type 2 LUKS encryption PREVENTS Grub from
# being able to properly decrypt an encrypted /boot. This is also precisely why an existing encrypted Arch system which used
# standard LUKS Type 2 encryption CANNOT be converted into an encrypted /boot system. A clean install is necessary!
# Also note that Grub is slated to support unlocking a LUKS2 encrypted /boot in the future. That LUKS2 support is currently
# targeted at the Grub 2.06 (or later) release, but that support is NOT currently available in Grub.
cryptsetup luksOpen /dev/sdXZ RockinEncryptedBoot # (or use any word or phrase you're fond of)
# Create encrypted LVM partitions
# These steps create a required root partition and an optional partition for swap. Note that using a swap file with BTRFS has
# become possible since kernel 5+. As always, swap partitions are not controlled by BTRFS so they work fine. Read the
# BTRFS ArchWiki before proceeding.
# Also note that BTRFS fully supports, detects, and properly configures settings for all modern SSDs, which is the drive type
# almost everyone should be running when installing ArchLinux! HDDs are only useful for infrequently accessed data, and
# for storing your SSD's critical directories as encrypted backups.
# Modify this structure only if you need additional, separate partitions. The sizes used below are only suggestions.
# The VG and LV labels 'Arch, root and swap' can be changed to anything memorable to you. Use your labels consistently, below!
pvcreate /dev/mapper/RockinEncryptedBoot
vgcreate Arch /dev/mapper/RockinEncryptedBoot
lvcreate -L 512M Arch -n swap
lvcreate -l 100%FREE Arch -n root
# Create filesystems on your encrypted partitions
mkswap /dev/mapper/Arch-swap
mkfs.ext4 /dev/mapper/Arch-root
# Note that Arch Linux fully supports btrfs, and btrfs is also an excellent filesystem choice for your encrypted root.
# If you want a btrfs filesystem on your root logical volume, instead of 'mkfs.ext4 /dev/mapper/Arch-root', do this:
mkfs.btrfs /dev/mapper/Arch-root
# If you've created a btrfs root filesystem, do not forget to append 'btrfs-progs' to the pacstrap installation command
# we use immediately after correctly mounting our partitions below.
# Mount the new system
mount /dev/mapper/Arch-root /mnt
swapon /dev/mapper/Arch-swap
mkdir /mnt/boot
mkdir /mnt/efi
mount /dev/sdXY /mnt/efi
# Optional - Edit the Mirrorlist To Optimize Package Download Speeds
nano /etc/pacman.d/mirrorlist
# Copy one or two mirrors near your physical location to the top of the mirrorlist.
# Install your Arch system
# If you read the contents of https://www.archlinux.org/ you would know the Arch developers made significant
# changes to the 'base' package in October 2019.
# The new base-metapackage does not contain a kernel nor an editor and several other important packages.
# We will be addressing those issues in our pacstrap command below.
# This installation command provides a decent set of basic system programs which will also support WiFi through
# iwd's `iwctl` after initially booting into your Arch system. Having WiFi following installation is particularly
# critical for anyone running a modern ultrabook, as most are equipped with WiFi-only access to the Net. Recommended, yet
# optional: make and enjoy some fresh java while the following command completes. Once completed, you'll only
# be a few minutes away from putting your new system to serious work!
pacstrap /mnt base base-devel grub efibootmgr dialog wpa_supplicant linux linux-headers nano
dhcpcd iwd lvm2 linux-firmware man-pages
# Create and review FSTAB
genfstab -U /mnt >> /mnt/etc/fstab # The -U option pulls in all the correct UUIDs for your mounted filesystems.
cat /mnt/etc/fstab # Check your fstab carefully, and modify it, if required.
# Enter the new system
arch-chroot /mnt /bin/bash
# Set the system clock
ln -s /usr/share/zoneinfo/UTC /etc/localtime # This will harmlessly fail if your system's CMOS clock is already set to UTC.
hwclock --systohc --utc
# If you require WiFi access following reboot, enable iwd:
systemctl enable iwd
# Assign your hostname
echo MyHostName > /etc/hostname
# Set or update your locale
# If English is your native language, you need to edit exactly two lines to correctly configure your locale language settings:
a. In /etc/locale.gen **uncomment only**: en_US.UTF-8 UTF-8
b. In /etc/locale.conf, you should **only** have this line: LANG=en_US.UTF-8
# Now run:
locale-gen
# Set your root password
passwd
# Create a User, assign appropriate Group membership, and set a User password. 'Wheel' is just one important Group.
useradd -m -G wheel -s /bin/bash MyUserName
passwd MyUserName
# Let's create our crypto keyfile:
cd /
dd bs=512 count=4 if=/dev/random of=crypto_keyfile.bin iflag=fullblock
chmod 000 /crypto_keyfile.bin
chmod 600 /boot/initramfs-linux*
cryptsetup luksAddKey /dev/sdXZ /crypto_keyfile.bin
cryptsetup luksDump /dev/sdXZ # You should now see that LUKS Key Slots 0 and 1 are both occupied
# Configure mkinitcpio with the correct FILES statement and proper HOOKS required for your initrd image:
nano /etc/mkinitcpio.conf
# Your FILES statement needs to match mine:
FILES=(/crypto_keyfile.bin)
# Use this HOOKS statement:
HOOKS="base udev autodetect modconf block keymap encrypt lvm2 resume filesystems keyboard fsck"
# Note that recent ArchLinux installation images have shipped with a new version of /etc/mkinitcpio.conf. The
# only difference is that the new version uses '(' and ')' instead of dual double quotation marks: ' " " '. Therefore,
# the current HOOKS statement should be:
HOOKS=(base udev autodetect modconf block keymap encrypt lvm2 resume filesystems keyboard fsck)
# You do not need or want 'resume' in your HOOKS statement if you are not using swap.
# Generate your initrd image
mkinitcpio -p linux
# Install and Configure Grub-EFI
# Since we need grub to decrypt our encrypted /boot, we first need to configure grub so that it knows we are working with
# a LUKS encrypted disk.
nano /etc/default/grub
# UNCOMMENT this line:
GRUB_ENABLE_CRYPTODISK=y
# The correct way to install grub on an UEFI computer, irrespective of your use of a HDD or SSD, and whether you are
# installing dedicated Arch, or multi-OS booting, for our encrypted /boot purposes is:
grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=ArchLinux
# Edit /etc/default/grub so it includes a statement like this:
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sdYZ:MyDevMapperMountpoint resume=/dev/mapper/MyVolGroupName-MyLVSwapName"
# Maintaining consistency with the examples provided above, you would use something like:
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sdXZ:RockinEncryptedBoot resume=/dev/mapper/Arch-swap"
# If you are not using swap, eliminate the 'resume' statement above.
# Generate Your Final Grub Configuration:
grub-mkconfig -o /boot/grub/grub.cfg
# Exit Your New Arch System
exit
# Unmount all partitions
umount -R /mnt
swapoff -a
# Reboot and Enjoy Your Encrypted BOOT Arch Linux System!
reboot
# Upon reboot, you should be greeted with a Grub screen asking you to enter your LUKS encryption passphrase.
# Note, because of the way I have structured this installation you will always only need to enter your passphrase ONCE!!
# This passphrase entry allows Grub to decrypt /boot, then Grub will automatically decrypt our encrypted root and swap!
# If you need non-US keyboard passphrase entry support, note that the early-boot passphrase entry will always use
# US keyboard mapping, even if you changed the keymap for your GRUB bootloader. Refer to:
https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot
# for additional information.
__________________________
# After you are satisfied that your Arch system is running well, if you are like most people not running an Arch server,
# you'll want a Desktop Environment so you can begin using your new system productively. See my: 'Installing a
# Plasma-KDE Desktop Post Arch Install' section below for some ideas and an efficient DE installation process.
__________________________
If you ever get dropped to the EFI Shell prompt when powering up Arch Linux, which I most often notice within
VirtualBox when running Arch Linux as an UEFI-enabled Guest System, do the following:
At the Shell prompt, type the following entries, as indicated (also remember we used --bootloader-id=ArchLinux, above):
Shell> fs0:
fs0:> \EFI\ArchLinux\grubx64.efi
Hit Enter and now you should see your graphical grub Arch Linux menu. Note my atypical use of backslashes.
To prevent being dropped to the EFI Shell prompt in the future, enter your Arch Linux system, become root, and do:
# nano /boot/efi/startup.nsh
In your startup.nsh file, add these two lines:
fs0:
\EFI\ArchLinux\grubx64.efi
Save and exit nano. To test that you will no longer be dropped to the EFI Shell prompt, poweroff, not reboot, and fire up
your Arch Linux system again.
If you simply cannot bear the agony of the EFI Shell's five second wait prior to its loading of startup.nsh, hit any key,
except for 'esc', and you should be immediately directed to your (hopefully, beautifully configured) grub graphical
Arch Linux boot screen.
This solution also works when you have installed Arch Linux as an UEFI-enabled Guest system within VirtualBox.
__________________________
External USB HDD/SSD Encrypted Arch Installation:
Almost all of my standard Arch install procedure can be followed without modification when installing Arch to an external device.
However, if you already have an encrypted Arch installation on a system HDD/SSD, you must ensure the names assigned to your
PV, VG and LVs are different than whatever you used on your system drive's Arch installation. Failure to use different names
will cause major udev and therefore, /dev/mapper, assignment problems for you, especially when you try to mount your
multiple encrypted Arch drives!
Additionally, we don't want to instruct grub to use standard device names as these are very likely to change when using an
external USB drive. For example, our external SSD may be assigned /dev/sdc by udev during installation, but when we try to
initially boot from it, udev may assign that external SSD to /dev/sdb, resulting in an unbootable system.
The solution is to use PARTUUID, as opposed to a standard device name, in the cryptdevice statement in /etc/default/grub.
Therefore, instead of using this example from above:
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sdXZ:2016-Global-OpSec-Champion-LyingHillary resume=/dev/mapper/Arch-swap"
Run 'blkid' as root, and find the correct PARTUUID for your external device's encrypted partition.
N.B.: PARTUUIDs are completely unrelated to UUIDs.
Substitute the correct PARTUUID for the standard device name. You should end up with a statement that looks similar to this:
GRUB_CMDLINE_LINUX="cryptdevice=PARTUUID=4d2aed94-92d4-7b5e-b8df-81d7554495cf4:ArchUSBSSD resume=/dev/mapper/ArchSSD-swap"
Now regardless of the device name assigned by udev to your external drive, the kernel will be able to find the
correct cryptdevice.
All other parts of my installation procedure should be followed without modification.
__________________________
Multi-OS-Booting Notes:
I UEFI boot and run more than five operating systems from my SSD.
All of my OSes UEFI boot from my single, 100 MiB, EFI partition.
All of my OSes have encrypted root and swap, utilizing my SSD's native hardware-based AES-256-bit encryption support
with BitLocker or Linux's software-based LUKS on LVM encryption to secure my data, when at rest.
My Arch Linux install is just another encrypted Linux OS installation that happens to reside on my SSD.
If you multi-boot, ensure you mount Arch's /boot/efi at your existing ESP partition.
If you installed Windows 10 first, your EFI partition is likely to be /dev/sda2.
In all cases, /boot, /boot/efi, and '/' partitions, at a minimum, are required to be mounted during Arch installation.
As an example, an EFI-addicted, multi-OS booter might be doing something like:
mount /dev/mapper/Arch-root /mnt
swapon /dev/mapper/Arch-swap
mkdir /mnt/boot
mount /dev/sda17 /mnt/boot
mkdir /mnt/boot/efi
mount /dev/sda2 /mnt/boot/efi
In this example, the user is likely to be using /dev/sda18 as the physical drive partition where their encrypted
Arch root and swap filesystems will reside. Note the user's re-use of their existing EFI partition which resides
at /dev/sda2.
Adapt, as necessary, for your drive's partition structure.
Following successful Arch system installation, the path to your Arch-EFI boot file should be:
/boot/efi/EFI/ArchLinux/grubx64.efi
When you are multi-OS booting correctly, you should have one directory per operating system, each residing at:
/boot/efi/EFI/
__________________________
BitLocker Users on Windows Notes:
If you are running hardware-based BitLocker encryption on Windows, I recommend you Turn Off BitLocker encryption prior to
installing Arch, or any other operating system.
As I don't use software-based BitLocker, I cannot say whether leaving it enabled during Arch installation will cause problems.
Obviously, if you experience issues, you could turn BitLocker off temporarily.
You can tell if you are using AES-256 bit hardware-based BitLocker encryption when you run from within PowerShell,
as an Administrator:
PS C:\WINDOWS\system32> manage-bde -status
You see this line:
Encryption Method: Hardware Encryption - 1.3.111.2.1619.0.1.2
Also note that hardware-based BitLocker can either encrypt, or decrypt, a multi-hundred GiB drive in less than 3 seconds.
You can re-enable BitLocker after your new encrypted Arch system is UEFI booting correctly and running smoothly.
__________________________
Installing a Plasma-KDE Desktop Post Arch Install
After you have rebooted into your new Arch system, and are satisfied that every aspect of your system is running correctly,
if you're like most people not running an Arch server, you will likely want to install a desktop so you can utilize your new
Arch system productively.
Your choice of desktop environment is entirely up to you. Personally, I have tried them all. It is my opinion that if
you are running a modern, reasonably powered PC or laptop you are doing yourself a significant disservice by running any
of the 'lightweight desktops.' I also think the Gnome DE is best suited for children, or unskilled users. Keep in mind
that you can install multiple desktops, and then choose which one to fire up at each login, but that is beyond the scope
of this guide.
I prefer the Plasma5-KDE environment over all the others. If you would like to efficiently install a full Plasma5-KDE
environment, do the following, in this order:
# Log in as root, and not as a user
# Fully update your Arch system:
pacman -Syu # If a new kernel becomes available and is now installed, reboot, before proceeding.
# If you don't have network connectivity in your Arch system, run:
systemctl start dhcpcd <ethernet or wlan interface name>
# Now that you have an updated system, do:
pacman -S linux-headers
pacman -S dkms # This will automatically rebuild your kernel modules as new upstream kernels are released.
pacman -S xorg # This will install a mandatory X server.
pacman -S xorg-apps
reboot
__________________________
# Log in as root, and not as a user, and do:
pacman -S plasma-meta # This large package set will also provide us with sddm, the recommended Plasma5 login manager.
systemctl enable sddm
systemctl enable NetworkManager # After your next reboot you will have full, correct, networking support from boot.
pacman -S kde-applications-meta
pacman -S xdg-user-dirs
# If you want full (US English) spelling support for all of your applications, do:
pacman -S hunspell-en_US hyphen-en libmythes mythes-en aspell-en
# Everyone has their own font preferences, but I agree with Arch's initial ttf-font recommendations because they look great!:
pacman -S ttf-dejavu ttf-liberation
reboot
__________________________
# Log in to sddm's GUI as your user
# Your first stop is System Settings. Tweak 'all the things' into full compliance with 'your way.'
# Go ROCK your fully enabled Plasma DE, and your properly encrypted Arch Linux system!!!
@stelgenhof
Copy link

HardenedArray, first of all thanks for the great instructions! Very helpful to have all the steps in one page.

Just wanted to point out one thing I experienced with my setup (Thinkpad P53, i7 6 Core, 64GB RAM, 256GB NVMe SSD). The time taken by GRUB to decrypt /boot is very long (~ 1min). After doing some web searching, it seems to be a know issue for some people. See also this article about that: https://linux-blog.anracom.com/2018/11/30/full-encryption-with-luks-sha512-aes-xts-plain64-grub2-really-slow/

Perhaps it is an idea to mention that in your tutorial as an FYI to others.

Haven't figured out yet how to resolve this. I may change the installation to an uncrypted /boot :(

Cheers! Sacha

@woopstar
Copy link

Great guide. I tried it out the weekend. The only thing I ran into was after the reboot when Arch has been installed, I was unable to find any wifi networks on my ThinkPad T440s. I had to disable power save on the card and it then worked.

In regards to LUKS1 format for the boot loader, the reference ticket is here https://savannah.gnu.org/bugs/?55093
I guess when it's closed, we can switch to LUKS2

@HardenedArray
Copy link
Author

HardenedArray commented Feb 19, 2020

Hi Sacha @stelgenhof,

I am happy to learn that you found my encrypted /boot guide useful.

There is no way a powerful laptop like yours should be requiring more than a minute to unlock LUKS. I say this ONLY if you did not intentionally increase cryptsetup's iteration default to a larger value when you initially ran luksFormat. That alone could explain long unlocking times. The iteration default used by cryptsetup provides more than adequate security on most modern, fast and capable CPUs while still maintaining reasonable unlocking times.

You might want to have a look at your actual iterations with something like: cryptsetup luksDump /dev/nvme0n1pX and also try: cryptsetup benchmark and see if those commands provide valuable clues.

I read the link the you sent, and I will be not be modifying my guide. Reducing cryptsetup's iterations is a very poor idea. You may want to review: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions Section 5.10 What is "iteration count" and why is decreasing it a bad idea?

I have two laptops, an old one with an i5, and a new one with an i7, and both run SSDs. My old laptop requires ~9-11 seconds to unlock LUKS (Slot 0 opened) and my new laptop takes about 7-9 seconds to unlock LUKS. Neither of these values are unacceptable to me. I only reboot my system after pulling in a new kernel, and I run many kernels, and even with keeping my system continuously updated, I only need to reboot about every 2 or 3 days. To me the short LUKS unlock wait time is worth the enhanced security of an encrypted /boot.

Cheers,

Hardened Array

@HardenedArray
Copy link
Author

HardenedArray commented Feb 19, 2020

Hi woopstar,

Thank you for your kind words. On the WiFi issue, I'm glad you tracked down the cause with your WiFi card so could you then use wifi-menu post-install.

On the Grub2 supporting LUKS2 front, I am actively engaged in this issue with the maintainer of the grub-git AUR and also with several senior Arch developers.

The best we know so far is that Grub2 is supposed to offer LUKS2 encrypted /boot unlocking support in version 2.06. In the meantime, we just have to wait for that release. Of course, I will make appropriate modifications to my guide once I have tested the new LUKS2 encrypted /boot thoroughly and know it works.

Cheers,

HardenedArray

@stelgenhof
Copy link

Hi HardenedArray,

Thanks for the explanation. I will have a look at your recommendations. My suggestion was mostly from lack of experience with this topic, so please indeed feel free to ignore :)

Cheers! Sacha

@HardenedArray
Copy link
Author

Hi Sacha @stelgenhof,

It was my pleasure to explain my stance to you. I take all reasonable suggestions seriously, including yours.

Keep up the good work on your git site. You are heading on the correct path.

Cheers,

HardenedArray

@xel
Copy link

xel commented Apr 13, 2020

Hi HardenedArray,

It's been three years since i first encountered the first version of this guide and the amazing recommendation that came with it. During the period, i've ported the same strategy over to NixOs and found it equally effective. Thank you once again for taking your time to thoroughly test out and write this guide. It not have blown up much, but some of us do appreciate the effort to the core.

PS: I also did arrive at the same conclusion as you did on the LUKS unlock wait time. I have 9-11 seconds on a high end T570 as well and though i feel it could be better, anything beneath 30 seconds is acceptable to me as a reasonable compromise for enhanced security on /boot

@HardenedArray
Copy link
Author

HardenedArray commented Apr 14, 2020

Hi (again) Xel,

It is amazing that it has been 3 years since I received your original feedback concerning my encrypted Arch installation guide.

Thank you for your kind words, and it was nice to learn about the NixOS applicability of this encrypted /boot strategy.

I agree that the short LUKS encrypted /boot unlocking time required is at best a minor inconvenience relative to the security improvement.

Cheers,

HardenedArray

@hertg
Copy link

hertg commented Apr 16, 2020

Hi HardenedArray,

Thanks a lot for this great guide! I just used it to install my system. The instructions are clear and I didn't run into any big issues.

One thing that I found out during the installation is that the keymap is always set to the us layout during the encryption passphrase prompt (which is pretty inconvenient if there are special characters in your passphrase). I digged a little deeper on that, and it turns out that this can't be fixed with pure configurations, because the grubx64.efi core image does only contain the mappings for us keyboards. In order to fix this issue, a non-US keyboard user needs to regenerate the core image. Fortunately this use-case is described in the Manual configuration of core image for early boot chapter on the ArchWiki. Would be great if you could mention this Wiki Page in your guide, as a lot of non-US users might run into this problem.

I didn't test that yet, because it seems that you need to have Xorg installed for the keymaps (?). I'm installing my GUI right now and will report back if it resolves my issue. :)

Btw.
The only thing that wasn't really clear to me is why the EFI Partition is mounted at /efi instead of the usual /boot/efi? Would be great if you could elaborate on that decision. 😄

Regards,
Michael

@HardenedArray
Copy link
Author

HardenedArray commented Aug 9, 2020

Hi Michael @hertg,

My apologies for the lengthy delay in my follow-up. I am very glad to learn you found my installation guide useful.

I do not want to change anything in this guide regarding key mappings, as there are multitudes of different layouts. I think for the average new installer it is preferable to stick with the default US keyboard layout during installation, and it makes no sense to open up this vast can of worms during installation. Following successful installation, obviously interested users can research how tweak their systems into compliance with their own language and keyboard layout preferences.

As to your query regarding the EFI partition, please recall we are installing encrypted /boot is this guide. When we install (or run) an encrypted /boot system, /boot is NEVER mounted. /boot is only a folder residing under our encrypted /.

As shown above, prior to running pacstrap only two partitions are mounted:

/ is mounted at /mnt

and

/efi is mounted at /mnt/efi

Again, /boot is NEVER mounted on an encrypted /boot system.

I hope this clarifies matters for you.

Cheers,

HardenedArray

@hertg
Copy link

hertg commented Aug 9, 2020

Hi @HardenedArray,

Thanks for the response. No problem about the delay.
I actually ended up not using an encrypted boot, as the hassle to setup and maintain it with my "triple"-boot (linux, linux, windows) setup was bigger than its gain. All the other partitions apart from boot/efi are still encrypted, your other guide was of great help for that too.

I do not want to change anything in this guide regarding key mappings, as there are multitudes of different layouts. I think for the average new installer it is preferable to stick with the default US keyboard layout during installation, and it makes no sense to open up this vast can of worms during installation. Following successful installation, obviously interested users can research how tweak their systems into compliance with their own language and keyboard layout preferences.

I agree. I wouldn't add the steps on how to do this in your guide. But just a small hint on line 288 might guide some future non-US users into the right direction to solve that later.

Something like:

Be aware that the early-boot passphrase entry will always have the US keyboard mapping, 
even if you changed the keymap for your GRUB bootloader. 
For more information: https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot

Thanks for elaborating on the /efi partition, that makes sense.

@HardenedArray
Copy link
Author

Hi @hertg,

Your input makes sense to me. I have appended a paragraph above directing folks who need non-US keyboard passphrase entry support to the link you provided.

Thanks for your feedback and suggestion, Michael.

Cheers,

HardenedArray

@insan1k
Copy link

insan1k commented Sep 20, 2020

Dear Folks,

First off thank you a lot @HardenedArray for the awesome guide. It would seem support has been added to LUKS2 on the Grub master branch https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755 I will try and use LUKS2 at my current fresh install and let you guys know how it went.

Regards,
Erick

@insan1k
Copy link

insan1k commented Sep 20, 2020

Turns out it didn't work, or rather... LUKS2 is supported, just not with argon2i which is the current default KDF for luks2, LUKS2 is supported with PBKDF2 which is the default for LUKS1... since we're at the moment in grub v 2.04-8 I'll wait a bit more and try again.

@HardenedArray
Copy link
Author

Hi @insan1k,

First, I am glad you found my encrypted /boot installation guide useful!

Correct - as you found out grub (from the Arch repos) does NOT support LUKS2, and there is still no published estimate as to when it will. For these reasons, that is why I insist that folks use --type luks1 when encrypting their / in the steps above.

I have been aware of Patrick's LUKS2 grub commit since late 2019. In fact, it was Patrick who helped me develop the script which allows LUKS2 automated encrypted /boot unlocking!

You CAN however, boot an encrypted /boot with LUKS2 support right now with a bit of effort, but you will need to compile and install grub-git from the AUR, here:

https://aur.archlinux.org/packages/grub-git/

Read and adapt to your requirements my LUKS2 procedure, published under another of my nicks 'air-g4p'. Start with my process here:

air-g4p commented on 2020-08-30 09:52 - then read my other, subsequent comments if you want automated LUKS2 unlocking.

I ONLY use LUKS2 encrypted /boot unlocking on both of my laptops. Both rigs boot flawlessly!

I hope you (and others) find my LUKS2 encrypted /boot procedure useful!

Cheers,

HardenedArray

@mrkvn
Copy link

mrkvn commented Jan 17, 2021

Thanks for sharing this guide. Just want to ask why you don't make this a markdown file. Not complaining at all. It would just be better in the eyes, for reading. Cheers!

Copy link

ghost commented Jan 13, 2022

Thanks for your hard work i always use your guides but is there an option you can include multiple hdd/ssd drives under one installation as in todays world we usually use more than one hard drive.
Thanks again and keep up with your hard work its much appreciated.

@jaantollander
Copy link

jaantollander commented Feb 5, 2022

Thank you very much! I was able to install encrypted Arch Linux with your instructions on my ThinkPad T480s and everything seems to be working correctly. It would have taken great deal of effort to figure these steps out on my own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment