Bug#849400: debian-installer: LUKS on rootfs and boot
On 2023-07-03 00:57 +01:00 BST, "Cyril Brulebois" <kibi@debian.org> wrote:
> Hi,
>
> Jinesh Choksi <jinesh@onelittlehope.com> (2023-07-02):
>> The issue is this block of code:
>> https://salsa.debian.org/installer-team/partman-crypto/-/blob/master/check.d/crypto_check_mountpoints#L94-102
>>
>> This 17 year old "Check - Is there a /boot partition for encrypted
>> root?" is no longer valid.
>
> It is.
>
>> Grub2 added support for accessing LUKS1 partitions in 2011 -
>> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a251b71915e40194d12995dbac9efd787687f988
>
> Sure, that's known, and there were two talks during Mini-DebConfs in
> 2019 about this and LUKS2 (Marseille, Hamburg).
>
>> Grub2 support for LUK2 is also present but only for PBKDF2 keys -
>> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755
>
> And since default LUKS2 settings are argon2id (argon2i previously), that
> means that cannot work.
>
>> For people who use LUKS1 to do full disk encryption, this "Check - Is
>> there a /boot partition for encrypted root?" is a blocker in the
>> Debian installer.
>
> People finding their way to use LUKS1 instead of the default LUKS2 can
> remove this check on their own.
>
>> Dear maintainer(s), please review this bug report and remove this
>> check.
>
> Not until GRUB gets support for argon2i{d,}. And that's where my focus
> is right now when it comes to d-i vs. LUKS.
>
> PoC at https://salsa.debian.org/kibi/grub/-/commits/luks2-argon2-v0
> but I have better plans to investigate.
>
>
> Cheers,
> --
> Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
>
Unhelpful and disappointing that users who need to setup FDE in Bookworm have to jump through hoops.
To the future reader(s), setting up FDE in Bookworm as it is now, with luks1 can be achieved via the following (assuming disk = /dev/sda):
- Perform an Expert Install
- Choose manual disk partitioning
- Setup a GPT partition table
- Setup an EFI partition (min 100MB), mounted as /boot/efi
- Setup a DMCRYPT partition using remaining free space. (i.e. Physical volume for encryption)
- Choose to "Configure encrypted volumes"
- Set a password for the encrypted volume
- Switch to TTY2, activate console and type in: (you need to do the following as cryptsetup defaults to luks2 (since 2019) and the installer doesn't provide options to select which luks format to use)
- cryptsetup luksClose sda2_crypt
- cryptsetup luksFormat --type luks1 /dev/sda2
- cryptsetup luksOpen /dev/sda2 sda2_crypt
- Select "Go back", and select "Detect Disks" (needed to refresh partman's state)
- Select "Partition Disks" again
- Set the file system for the encrypted volume to "physical volume for LVM". You need to do this because of the issue mentioned in this bug. By using LVM, it bypasses the issue in this bug. Even though you don't actually need LVM. The alternative suggested by the D-I release manager is to remove the following block of code in the /lib/partman/check.d/07crypto_check_mountpoints file before you finalise your partitioning:
--snip--
# Check - Is there a /boot partition for encrypted root?
if [ $crypto_root = yes ] && [ $have_boot = no ]; then
templ="partman-crypto/crypto_root_needs_boot"
db_set $templ false
db_fset $templ seen false
db_input critical $templ
db_go || true
exit 1
fi
--snip--
- Select "Configure the Logical Volume Manager"
- Create a volume group e.g. vgDEBIANVM
- Create a logical volume for '/'' e.g. lvROOT
- (optional) Create logical volume for '/home' e.g. lvHOME
- Create logical volume 'swap' e.g. lvSWAP
- Set up the file system and mount point for the above logical volumes as required and finalise partitioning.
- Proceed with installation as normal until you get to the "Install Grub Boot Loader" stage. You will find that this stage errors at the "grub-install (dummy)" step.
- If you look at msgs on TTY4, you will note it says to add GRUB_ENABLE_CRYPTODISK=y. Switch console on TTY2 and edit /target/etc/default/grub file and add this line. (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925134)
- Run the "Install Grub Boot Loader" stage again and it will work and rest of the install will progress normally.
Dear Maintainer,
- This bug was raised in 2016.
- Grub2 added support for accessing LUKS1 partitions in 2011.
- Between 2016 and 2019 (when cryptsetup defaulted to luks2 - https://gitlab.com/cryptsetup/cryptsetup/-/commit/ae90497762bc4e3f04064e0ebbbde8c64bf27c4a) the issue described in this bug could have been addressed by removing the "Check - Is there a /boot partition for encrypted root?" check.
- Were there any other factors as to why the check was still valid in those 4 years and hence not removed ?
Reply to: