Suggestions and thank you !

[as400l]

Hi Maximbaz,

Above all I would like to thank you for this great tool !

I have some suggestions if you would like to make this project more popular. I was thinking about why people don't use secure boot while it's available in every machine sold nowadays. And came to the conclusion that most people are just afraid when they hear "private keys", "public keys" or encryption in general :) But your tool is good enough to remove thinking about those "scary" things from people minds. So my proposals are:

1. Improve documentation. It just does not provide enough information how this tool works. While at the same time you wrote a great post with all of the details. So please attach this information to the readme --> https://github.com/Antynea/grub-btrfs/issues/92#issuecomment-705640920

2. Not everobody uses snapper. Personally I have very bad experience with it. So make the tool conditional - with or without snapper.

And getting to the problem that I have personally. I know you might have no idea why it is happening to me but, hey - it's worth asking. When I enter my Lenovo IdeaPad uefi I just don't see any other entries except of linux-secure-boot. And I have no way to choose anything else while at the same time all the images on /efi are created and in place:

root@i5 ~# ll /efi/EFI/arch/ total 107M -rwxr-xr-x 1 root root 1008K Jul 30 19:50 secure-boot-linux-efi-shell.efi -rwxr-xr-x 1 root root 39M Jul 30 19:50 secure-boot-linux-recovery-lts.efi -rwxr-xr-x 1 root root 44M Jul 30 19:50 secure-boot-linux-recovery.efi -rwxr-xr-x 1 root root 23M Jul 30 19:50 secure-boot-linux.efi

Big thanks for you work once again ! Any ideas ?

[maximbaz]

Thanks for the kind words @as400l 🙂

1. Definitely a good point about documentation!
2. Makes sense. So far I tried to keep the code as small as possible, as one of my goals in switching from grub/systemd-boot/sbupdate/etc was to have just as little code as possible - less code, less bugs, less security issues 😄 But you have a good point too, too opinionated tool would slow spreading good habits to more people. In the meantime, in your particular case I suppose you can just drop zzz-arch-secure-boot-generate-snapshots.hook hook that generates snapper snapshots.

As to your issue, let me just say that it's very likely that Lenovo's UEFI implementation is buggy and there will be nothing you can do - I personally observed this on Dell laptops, and that was why for recovery I bundled a tested UEFI shell implementation.

But try to experiment, I'd start with efibootmgr tool - run $ efibootmgr -v, see that it outputs correct entries, try to swap them and confirm that Lenovo only shows one. Maybe you can also edit UEFI entries from Lenovo UEFI setup (I mean the thing before OS boots), maybe if you edit the list there, two entries will appear? And if yes, if you somehow find a fix, compare the output of efibootmgr -v before and after your fix, will there be any difference, that we could maybe incorporate in this tool?

[as400l]

Thanks for suggestions. Unfotunately I had to add additional boot entries from cmdline to be able to choose them from UEFI setup. $ efibootmgr -d /dev/nvme0n1p1 -p 1 -c -l "\EFI\arch\secure-boot-linux-recovery.efi" -L "secure-boot-linux-recovery"

Now I wonder how are you booting into the snapshots ? What's exactly in recovery.nsh (yes I have it but started wondering if it's generated properly) and how does snapshots.txt look like (just id,date,description) ? Asking because if I try to boot them it's just not passing the proper cmdline to kernel.

EDIT:

Ok - got it. But there is an error in script. From recovery.nsh:

else if %2 == "lts" then \EFI\arch\secure-boot-linux-lts-recovery.efi

Actual files in /efi/EFI/arch:

-rwxr-xr-x 1 root root 1008K Aug 1 22:45 secure-boot-linux-efi-shell.efi -rwxr-xr-x 1 root root 39M Aug 1 22:45 secure-boot-linux-recovery-lts.efi -rwxr-xr-x 1 root root 44M Aug 1 22:45 secure-boot-linux-recovery.efi -rwxr-xr-x 1 root root 23M Aug 1 22:45 secure-boot-linux.efi

[maximbaz]

Great catch, thanks!

As for the boot entries, I have just remembered why recovery entries are not automatically added by the script: because they don't have embedded cmdline.

With secure boot, you generally try to limit what a user can do during boot, and then you sign your decision with keypair, like confirming "yep, I approve of these actions".

If your cmdline is not embedded in the .efi image, you can modify it during boot, which is useful for recovery purposes (if e.g. embedded cmdline contains a typo, or if you intentionally want a different cmdline in order to boot into a btrfs snapshot). But an attacker could also place some malicious code in \EFI (which remember, is not encrypted), and then use the .efi image without cmdline to effectively load it, or even to load in a very old snapshot which might have an old kernel with known vulnerability.

So that's why the script only adds to the efibootmgr the image with embedded cmdline. At least on my laptop, in order to boot into a different .efi file, I must enter BIOS password, so in theory an attacker must know the BIOS password to do some harm.

This is definitely not a fail-proof approach btw, for example I was able to find a master-password for the BIOS of my previous laptop online.... So just keep that in mind while planning your threat model 🙂

[as400l]

You certainly have made some good points. Unfortunately if I don't add boot entries in my Lenovo UEFI I just can't choose them from UEFI setup.

In the meantime I have come up with a simple solution for those that don't use snapper. And they are managing snapshots themselves. Here is what I've done.

1. Removed dependency on snapper and snap-pac from PKGBUILD.
2. Edit /etc/arch-secure-boot/config and add your snapshots dir (in my case just /snapshots):

SUBVOLUME_SNAPSHOT="${SUBVOLUME_SNAPSHOT:-snapshots/%1}"

3. Removed pacman hook zzz-arch-secure-boot-generate-snapshots.hook.
4. Added one section into /usr/bin/arch-secure-boot to automate generating snaphots.txt in /efi:

generate-snapshots-file) SNAP_PATH=echo $SUBVOLUME_SNAPSHOT | tr -d "%1" ls --full-time /$SNAP_PATH | awk '{print $9,$6}' > "$ESP/snapshots.txt" ;;

5. Added two systemd units to monitor snapshots directory and create new /efi/snapshots.txt everytime new snapshot is created.

/etc/systemd/system/arch-secure-boot-snap.path:

[Unit] Description=New snapshots monitoring DefaultDependencies=no Requires=snapshots.mount After=snapshots.mount BindsTo=snapshots.mount

[Path] PathModified=/snapshots

[Install] WantedBy=snapshots.mount

/etc/systemd/system/arch-secure-boot-snap.service:

[Unit] Description=Create new snapshots.txt file when new snapshot is created

[Service] Type=oneshot Environment="PATH=/sbin:/bin:/usr/sbin:/usr/bin" ExecStart=bash -c '/usr/bin/arch-secure-boot generate-snapshots-file'

[ShellCode33]

Hijacking this issue to thank you as well, this is amazing work ! This is by far the best secure boot setup I've came across.

I hope it lands in community repo one day. Probably not do-one-thing-but-do-it-well enough to reach community repo because of the snapper thing, but I still find it very convenient and it definitely makes sense to me to handle that here.

[Firestar-Reimu]

Thanks for your awesome package!

Bootloaders (such as GRUB or systemd-boot) are intentionally not supported, as they significantly increase the amount of code that runs during boot, therefore increasing the attack surface.

But I have installed GRUB as bootloader, can I use arch-secure-boot with GRUB?

[maximbaz]

You can have GRUB and arch-secure-boot side-by-side, if your goal is to try out several things to pick what works best. In UEFI settings you can choose which efi file you want your laptop to boot, and that would either be GRUB or arch-secure-boot. But arch-secure-boot doesn't use GRUB in any way, it just skips this step entirely, you get booted directly in your kernel.

[maximbaz]

After a shamefully long time I have finally gotten around to address the first point of this thread, namely to add some more information to README (motivation and how it works). Thus closing the ticket, but as always if anyone has any feedback or questions, do feel free to continue this thread or open a new issue.

[ShellCode33]

Very nice additions to the documentation, thanks a lot !

About:

In addition, because there is less steps in the process, and especially because you aren't decrypting your disk twice (like it is the case with GRUB), the boot is so much faster!

I don't know if it's worth mentioning but I believe one of the reasons it is so much faster is because we boot into a Linux kernel which has support for all the hardware accelerated features (such as AES-NI and probably others I'm unaware of), resulting in a much faster decryption process than GRUB. I believe it's the main reason why it's faster, but I'm not sure.

[maximbaz]

Oh that's interesting! Could you tell or speculate a bit more, why do you think booting into GRUB doesn't have access to the same accelerated features?

[ShellCode33]

That's indeed only speculation, in theory it could, but I suspect GRUB is not using intrinsics functions provided by CPU vendors (intel example). It would also require to detect at boot if the CPU supports such features, and in my experience there are many subtleties to each CPU vendor and model which can be very cumbersome and is probably (wild guess) the reason why GRUB is not bothering with it (yet?). On the other hand dm-crypt (the kernel module responsible for disk encryption) only job is to handle encryption, therefore it has probably been optimized for that purpose. GRUB main purpose is not to handle encryption.

For what it's worth:

$ grep crypt /proc/modules
crypto_null 16384 1 algif_aead, Live 0x0000000000000000
crypto_user 12288 0 - Live 0x0000000000000000
dm_crypt 65536 1 - Live 0x0000000000000000
encrypted_keys 28672 1 dm_crypt, Live 0x0000000000000000
trusted 53248 2 dm_crypt,encrypted_keys, Live 0x0000000000000000
dm_mod 233472 3 dm_crypt, Live 0x0000000000000000
crypto_simd 16384 1 aesni_intel, Live 0x0000000000000000
cryptd 28672 3 ghash_clmulni_intel,crypto_simd, Live 0x0000000000000000

SIMd is also one of the hardware features that can usually speed up {en,de}cryption a lot (depending on the algorithm in use).

Again, that's only speculation, I'm not that familiar with that topic.