search

alpernebbi / depthcharge-tools

Tools to manage the Chrome OS bootloader
GNU General Public License v2.0
27 stars 3 forks source link

LUKS encryption support #3

Open alyssarosenzweig opened 4 years ago

alyssarosenzweig commented 4 years ago

LUKS requires special handling. For my system, my /etc/fstab is empty. But my /etc/crypttab contains "root /dev/mmcblk0p2 none luks"

My /proc/cmdline reads

cros_secure cryptdevice=/dev/mmcblk0p2:root:allow-discards root=/dev/mapper/root rootfstype=ext4 console=tty1 quiet systemd.showstatus=0 rootwait rw

By contrast when using depthchargectl build I get the warning

depthchargectl build: warning: Couldn't figure out a root cmdline parameter from /etc/fstab. Will use 'root=/dev/mapper/root' from kernel.

And the built image will not be bootable due to the wrong cmdline:

kern_guid=%U root=/dev/mapper/root quiet splash

(The cryptdevice parameter is used for LUKS.)

More generally, I'm not sure if it's really our job to support LUKS? How are command lines usually generated on Debian? (where LUKS commandlines are automatically generated, as far as I know, based on the /etc/crypttab file which the installer should setup).

alpernebbi commented 4 years ago

I don't think you should need to add any LUKS-specific command-line arguments with the Debian initramfs. Make sure you have cryptsetup-initramfs installed, that should be handling it. Adding something like /dev/mapper/root / ext4 defaults 0 1 to /etc/fstab might actually be necessary, it might be only including info for the essential mounts (based on /etc/fstab) in the initramfs (also needs an update-initramfs -u after that).

I haven't really tried to boot Debian from a LUKS root with this though, so I will try such an installation soon and write back here.

In the worst case you can set arbitrary cmdlines using $PREFIX/etc/depthcharge-tools/{config,config.d/*} files.

alpernebbi commented 4 years ago

OK, I did an encrypted-root installation through (a custom build of) debian-installer. With that default commandline, the system starts booting, displays some messages and does nothing (unresponsive keyboard, no prompt). But when I add console=tty1 to the cmdline, it asks for the passphrase and boots just fine. Maybe it's trying to ask on a serial console in the first case?

Here's the files the installer set up, /etc/fstab:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/sda3_crypt /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda2 during installation
UUID=48b91d86-696a-44b0-9711-80c45502cd56 /boot           ext4    defaults        0       2

/etc/crypttab (also included in the initramfs as /cryptroot/crypttab):

sda3_crypt UUID=d93a0989-7234-4ffb-87f0-12dfea4bb093 none luks,discard

and it could boot with the command line:

kern_guid=%U root=/dev/mapper/sda3_crypt console=tty1 quiet splash

It might not be necessary to derive LUKS cmdlines for Debian, but I'm not sure it's the same for other distros. It's easy to say 'people should configure that manually in that case' but I'd like to reduce friction wherever possible, so I might end up implementing that in the future.

alyssarosenzweig commented 4 years ago

Maybe it's trying to ask on a serial console in the first case?

Possibly.

Here's the files the installer set up, /etc/fstab:

/dev/mapper/sda3_crypt / ext4 errors=remount-ro 0 1

/boot was on /dev/sda2 during installation

UUID=48b91d86-696a-44b0-9711-80c45502cd56 /boot ext4 defaults 0 2

/etc/crypttab (also included in the initramfs as /cryptroot/crypttab):

sda3_crypt UUID=d93a0989-7234-4ffb-87f0-12dfea4bb093 none luks,discard

and it could boot with the command line:

kern_guid=%U root=/dev/mapper/sda3_crypt console=tty1 quiet splash

OK, that seems reasonable then :)

It might not be necessary to derive LUKS cmdlines for Debian, but I'm not sure it's the same for other distros. It's easy to say 'people should configure that manually in that case' but I'd like to reduce friction wherever possible, so I might end up implementing that in the future.

Who knows? If it works for Debian it's good enough for the moment; if other distros need special changes, folks from those distros can chime in then.

--

Do we need any changes for the tty= bit then?

alpernebbi commented 4 years ago

Do we need any changes for the tty= bit then?

I think that might be a bug on the Debian side, will look into it.

alpernebbi commented 4 years ago

I've added console=tty0 to the default cmdline (in commit b1003a8). Some more discussion about the console issue at Debian bug report 952452.

In short, the serial console is preferred as it is set as the default console in device-tree files, installing plymouth and/or setting console=tty0 makes prompts available on the screen.

alyssarosenzweig commented 4 years ago

Makes sense, thank you for investigating :)