
Systemd-cryptsetup: Booting with encrypted root partition fails instantly - noch
https://github.com/systemd/systemd/issues/6381
======
kawsper
I wonder how elaborate their automated tests are, it is also quite interesting
that the provided fix did not introduce any new tests to the codebase for the
reported case.

~~~
andrewstuart2
Poettering does mention that the tests do not cover LUKS boots, and I would
hope they will be adding some in the near future, but I also understand that
the priority would be fix first, automated tests second (hopefully), since
this is already out in the wild and in need of a fix.

Agreed, though, that full-disk encryption is common (and important) enough
that it should merit good automated regression testing, especially simple
"does it still boot?" tests.

~~~
hobarrera
I was actually amazed they don't test this scenario (I was one of first
affected by this bug on all my systems about a week ago).

LUKS encryption is probably THE most common setup for newer desktop linux
installations, so I was amazed they didn't test this, but just rather plain
ol' unencrypted setups.

~~~
johnny22
Does any popular distro enable it by default?

~~~
bmn__
That's the wrong question, it does not matter what the default value in the
distro installer partitioning step is. What matters is that LUKS (often
labelled as full-disk encryption or similar) is easily available at install
time, and consequently enjoys popular adoption and use.

------
djsumdog
Looks like one of the people on the thread is using Gentoo, which is one of
the few distributions that offers a choice between systemd and openrc.

I currently use LUKS for full disk encryption (including /boot) on Gentoo
(openrc) with Grub doing the luks unlocking (my initrd has to unlock the
encrypted partition too/again, but I just have a key saved within the initrd
so I don't have to type the password twice).

~~~
infinisil
What do you think is the benefit of encrypting /boot? I can't imagine having
anything sensible on there.

~~~
TylerE
I would imagine it's more about making sure no one ELSE can drop a payload in
there... e.g. a backdoor'ed kernel.

~~~
Rjevski
Secure Boot should be able to defend against that if you take the time to set
it up (you'd need to enroll your own key in the system firmware and then sign
your kernel with that key).

~~~
djsumdog
That is my eventual goal. I want to re-enable Secure Boot, sign my Grub EFI
and place my CA (and only my CA; getting rid of the default ones) in the
UEFI/BIOS settings. I think you can also embed Grub with a key to verify the
kernel. (You can also just compile a kernel with UEFI Stub support, digitally
sign it and have that boot directly without Grub, but I'm not sure if you can
use luks that way as you still need the initrd to unlock the disk).

This would mean that if your laptop gets stolen, and you have a strong
password and disable booting from other devices, the thief/fencer would need
to find a way to reset the UEFI before they could install Windows on it and
resell it. It's probably still possible, but it makes it much more difficult
and they may just have to end up parting out the laptop and tossing the
motherboard.

------
jvoorhis
Two distros referenced on this thread are Gentoo and Arch - both are rolling-
release tinkerer's distros, and it has been noted that the feature in question
has been out of scope for QA by the systemd project as of late. The community
quickly found and shared workarounds and the bug will get fixed. I was bitten
by this bug, but I'm not sweating it.

------
Rjevski
Curious to see this making the front page of HN - what's so special about this
bug?

~~~
tyingq
Probably the historical animosity around systemd from those that feel it has
scope creeped into places it doesn't belong.

~~~
johnny22
I don't know where they got that idea. This was almost always in scope by
design, if not yet in implementation (at the time)

