Hi Jan,
On Fri, Jul 23, 2021 at 9:40 AM Jan Lübbe <j...@pengutronix.de> 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 <j...@pengutronix.de> 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. Regards, Brian
_______________________________________________ RAUC mailing list
