Hi all, update On Fri, Jul 30, 2021 at 9:33 AM Brian Hutchinson wrote: > Hi Jan, > > > On Fri, Jul 23, 2021 at 9:40 AM Jan Lübbe wrote: > >> Hi Brian, >> >> On Thu, 2021-07-22 at 08:55 -0400, Brian Hutchinson wrote: >> > Hi Jan, >> > >> > On Thu, Jul 22, 2021 at 8:16 AM Jan Lübbe wrote: >> > > On Thu, 2021-07-22 at 08:11 -0400, Brian Hutchinson wrote: >> > > > I'm wanting to have a rootfs that is read-only SquashFS and a appfs >> that >> > > > is encrypted. >> > > I assume you want to have a A/B appfs. >> > >> > Yes, have A/B for Kernel, dtb, rootfs and appfs. >> >> OK, as a side-node: I'd suggest storing the kernel in the rootfs, as that >> gets >> rid of potential inconsistencies, avoids the need to reserve space in the >> kernel >> partitions and reduces the number of build artifacts to keep track of. >> >> > > How do you encrypt your appfs? dm-crypt or fscrypt? >> > So process in factory will set everything up on eMMC the first time >> with: >> > >> > cryptsetup luksFormat /dev/mmcblk2p1 & /dev/mmcblk2p2 >> > cryptsetup luksOpen /dev/mmcblk2p1 crypt_appfs1 (same thing for >> > /dev/mmcblk2p2) >> > mkfs.ext4 /dev/mapper/crypt_appfs1 & crypt_appfs2 >> >> So dm-crypt with luks header. >> >> > Then in normal use just have a script that figures out which slots we >> are >> > starting, A or B to determine with appfs partition to use and cryptsetup >> > luksOpen then mount /dev/mapper. >> >> I'd open both and only mount the active one. (see below) >> >> > > > I know a bundle can have pre and post triggers so maybe I can use >> those to >> > > > cryptsetup luksOpen the partition and then mount it and then RAUC >> can do >> > > > it's >> > > > normal thing ... but I've not researched that enough to know if >> that's the >> > > > way >> > > > to go so thought I'd ask for some guidance to point me in the right >> > > > direction >> > > > first. >> >> There is the "pre-install" slot hook: >> https://rauc.readthedocs.io/en/latest/using.html#slot-hooks >> >> It's not appropriate for your use-case, though, as it's called after RAUC >> has >> mounted the target slot, as that would be too late. >> >> > > If you use dm-crypt, you can just use the device-mapper path for the >> slot's >> > > device= propert in system.conf. That way, the encryption is >> transparent to >> > > rauc. >> >> > Not following how that would work since the inactive appfs would be >> > "closed/encrypted". >> >> You'd luksOpen both apps partitions during boot, before starting RAUC. >> >> From your other mail: >> > Sorry, forgot to reply-all to last message. So when I did my >> luksFormat etc., >> > I used a key-file that I created with openssl rand -base64 32 > >> > luks_appfs_key. >> >> Hmm, I thought you'd use a TPM or kernel trusted keyrings to store the >> key. >> Where do you store this key file, so it's not easily readable by the >> attacker? >> > > It's a long story, no requirement for "secure boot" only "encrypt files at > rest". I know, I know. I just follow schedules ;) > > >> > Are you telling me that if I add a key and put it in the rauc key ring >> in >> > /etc/rauc and in my system.conf refer to my appfs by /dev/mapper name >> rauc >> > will know what to do to "open" the inactive appfs to do the update? >> >> No. The rauc keyring is only for checking the signature on the bundle. >> >> >> > I guess I'm hung up on how the "open" will take place and how to tell >> rauc >> > about the key to use etc. >> >> rauc has no special support for any specific type of block device, as it >> just >> uses the abstraction as provided by the Linux kernel, similar to >> mkfs.ext4. >> >> So anything that can be used by i.e. ext4 can be used by rauc, you only >> have to >> setup the devices before starting rauc. This means that rauc works with >> HDDs, >> SSDs, USB-Sticks, SD-Cards, eMMCs, NVMe, RAID, LVM, >> dm-verity/-crypt/-integrity >> and anything else that's represented as a Linux block device, without >> needing >> specific code for each. >> >> In the case of block device encryption, this also avoids the need to give >> rauc >> access to the key material. Having a service/script during boot be the >> only >> place where the key is handled, avoids exposing it in the rest of the >> system, >> where it could be compromised. >> >> So my suggestion is: During boot, get the key material in your >> project-specific >> way (TPM/HSM/OP-TEE/...) and use cryptsetup/dmsetup to create both >> /dev/mapper/crypt_appfs[12] and then discard the key material from >> userspace, so >> only the dm-crypt target keeps it alive. In rauc's system.conf, you set >> device=/dev/mapper/crypt_appfs1 and /dev/mapper/crypt_appfs2 for the appfs >> slots. This way, it rauc can use them as any other block device. >> >> So here is the test I did ... that didn't work. > > I nfs booted my board. rauc thinks I've booted from slot A so it's going > to try to update slot B. > > I do: > > cryptsetup luksFormat /dev/mmcblk2p2 /boot/luks_appfs_key > cryptsetup luksOpen /dev/mmcblk2p2 crypt_appfs2 --key-file > /boot/luks_appfs_key > mkfs.ext4 /dev/mapper/crypt_appfs2 > > My /etc/rauc/system.conf looks like: > > [system] > compatible=MyBoard > bootloader=uboot > > [keyring] > path=/etc/rauc/ca.cert.pem > > [slot.kernel.0] > device=/dev/mmcblk2gp0p1 > type=vfat > parent=rootfs.0 > > [slot.kernel.1] > device=/dev/mmcblk2gp1p1 > type=vfat > parent=rootfs.1 > > [slot.rootfs.0] > device=/dev/mmcblk2gp1p2 > type=ext4 > bootname=A > > [slot.rootfs.1] > device=/dev/mmcblk2gp1p2 > type=ext4 > bootname=B > > [slot.appfs.0] > device=/dev/mmcblk2p1 > type=ext4 > parent=rootfs.0 > > [slot.appfs.1] > device=/dev/mapper/crypt_appfs2 > type=ext4 > parent=rootfs.1 > > So at this point, /dev/mapper/crypt_appfs2 is open but not mounted. > > I have my bundle scp to /tmp so I try to install it and get: > > installing > 0% Installing > 0% Determining slot states > 20% Determining slot states done. > 20% Checking bundle > 20% Verifying signature > 40% Verifying signature done. > 40% Checking bundle done. > 40% Checking manifest contents > 60% Checking manifest contents done. > 60% Determining target install group > 80% Determining target install group done. > 80% Updating slots > 80% Checking slot kernel.1 > 83% Checking slot kernel.1 done. > 83% Copying image to kernel.1 > 86% Copying image to kernel.1 done. > 86% Checking slot rootfs.1 > 90% Checking slot rootfs.1 done. > 90% Copying image to rootfs.1 > [ 1901.504350] EXT4-fs (mmcblk2gp1p2): mounted filesystem with ordered > data mode. Opts: (null) > 93% Copying image to rootfs.1 done. > [ 1927.854400] EXT4-fs (mmcblk2gp1p2): mounted filesystem with ordered > data mode. Opts: (null) > 93% Checking slot appfs.1 > 96% Checking slot appfs.1 done. > 96% Copying image to appfs.1 > 100% Copying image to appfs.1 failed. > 100% Updating slots failed. > 100% Installing failed. > LastError: Installation error: Failed updating slot appfs.1: failed to run > mkfs.ext4: Child process exited with code 1 > Installing `/tmp/./update-myboard.raucb` failed > > But yet I can do mkfs.ext4 /dev/mapper/crypt_appfs2 and mount it and the > filesystem is fine. > > Looks like I'm missing something still. > > So I think my issue was because I was nfs booted. Slot A was activated but not booted. But it looks like maybe it was using slot A /etc/rauc/system.conf instead of the currently running nfs instance /etc/rauc/system.conf because what I tried before worked once I mounted /dev/mmcblk2gp0p2 and changed that /etc/rauc/system.conf to: [slot.appfs.1] device=/dev/mapper/crypt_appfs2 type=ext4 parent=rootfs.1 So this brings up a question. If I have boards out in the field and appfs goes from plain ext4 to encrypted, I somehow need to update the currently running /etc/rauc/system.conf file first before performing an update??? How to handle system.conf changes? Regards, Brian