Raspberry Pi OS • Re: Disk Encryption since Bookworm

Experimentation is the whole point of rpi.

Indeed!

[Does sdm know about LVM? In principle, it should work for the OS (bookworm) now that "initrd" gets automatically generated. I should already know the answer but, as above, not enough free time.

sdm knows about IMGs with 2 partitions, and things that can be made to look like IMGs (directory trees and/or devices).

So, while it doesn't do anything with LVM today it certainly could do something with LVM. For instance, one of sdm's operations is to burn an SSD/SD Card. Today it dd's the IMG to the device. It's not out of the realm of possibility for it to do a "burn and convert to LVM"...after all, it's only code

sdm's mission is to take an IMG from downloads.raspberrypi.org and update it so it is configured exactly the way you want it. This includes installing and configuring packages and L10N, copying files into the IMG (e.g., SSH keys, .bashrc, etc etc etc). sdm's goal is that after the resulting SSD/SD has booted, it's 100% ready to do whatever you want it to do.

Think of sdm as a fancy IMG editor.

Most of what sdm does is implemented in plugins, which are simply scripts that are "phase"-aware. See Operating Details and Programming Plugins for information on sdm's phases and plugins.

To bring this back to Disk Encryption and Bookworm, sdm will implement this via a new plugin that sets up the system such that:

• At the end of the first boot of the system, disk encryption configuration that can be done on the running system will be done,including creating a new initramfs configured for encryption and adding sdm-provided scripts in it to make the manual initramfs steps as simple as possible
• When the system reboots it will drop into initramfs
• Using the sdm-provided scripts:
  • Copy rootfs to another device
  • Enable encryption on the system disk rootfs
  • Copy the rootfs from the other device back into the encrypted rootfs
• Once this is done, the system will reboot. After providing the rootfs password, the system will come up normally
• Last step will be to clean up and make a "normal" initramfs (so that boots proceed more quickly), and then reboot one last time

My proof of concept informs that this is all doable.

TBH the most difficult part from my perspective will be the sh scripts for use in initramfs (sh appears to be the only shell in initramfs), since sh has such a simple programming language.

I am hoping to avoid using sh by stuffing bash into the (temporary) initramfs to expedite/simplify this. Of course, it would be removed as part of the "clean up" step at the end of the process.

I've taken a cursory look at those two sdm links. I don't see anything there which strikes me as a show-stopper regards LVM.

My intention was to write a QT GUI app to do the conversion after the fact. This would require either (a) two spare partitions or (b) another empty device upon which to create two partitions from which you'd subsequently boot. I can't see me having the time to do that. However, that GUI app (at least initially) would have done little more than generate shell script to execute. If nspawn (I've never used it) can wake up LVM and generate an initramfs then it could be done directly.

LVM has the notion of a physical volume (PV). It has a notion of a volume group (VG). It has a notion of a logical volume (LV). Documentation almost always is impenetrable. Dunno why. In essence one creates a PV on an empty partition. Then you assign (one or more PV's) to a VG. Once you've got a VG, you create one or more LV's within it - which are then formatted like usual. LVM uses names (under /dev/mapper) and once activated, will look after itself, largely transparent to the operating system. Thus if I create a 32G LV called "rootfs" and format it ext4, copy the rpi OS into it, I can adjust "root=" in cmdline.txt to use the /dev/mapper/ name (ditto /etc/fstab) it will boot. The problem, previous to bookworm, was any kernel update would render the system unbootable - the only way to avoid this was to manually check, before reboot, if there had been a kernel update and type the relevant initramfs commands.

I should now be in a position to confirm if rpi bookworm solves this. I am not (time constraints again). I'm assuming it does from the /boot/firmware/ rearrangement and would be surprised if it does not now work. Add into the mix, GPT disk support, there's much flexibility to be gained - live runtime snapshots and moving disks while the operating system is running.

Wrt to /bin/sh, I had to deal with that issue back when people were dumb enough to employ me! I had to support unix (Aix/BSD) plus SuSE and Redhat. Add into the mix multiple versions across almost a decade, the only sane(*) way forward was to use /bin/sh because each had their own default shell. Moreover, some would change shell when you became root - and not all /bin/sh are equal (being restricted versions of their real shell). You can see hints of that in https://github.com/swampdawg/go/blob/master/f_var (another thing I haven't had time to finish). Essentially, everything has to be a global variable. The main "user" script will source a library (like f_go) which in turn source the above f_var. The rule was any function in that library had to be prefixed with "f_" and any variable with "F_". Then add on the name of the script itself, hence F_VAR_* and F_GO_*. I'd always argued from the outset that as SuSE/Redhat (and other linux we came to support) used 'bash' and that it was available to Aix/BSD then bash was the way to go. Almost no-one from the BSD world was interested so that left Aix which has two versions of 'ksh', the default version of which created a new file in /tmp for every subshell. eg:..yields a /tmp/ for each $(command). It would take minutes to run the initial 'configure' for gcc whereas bash would take seconds.

(*) For some definition of pointy haired boss.

You'll note from https://github.com/swampdawg/go it specifically says 'bash'. It's had the (potentially) proprietary stuff ripped out and first thing I did was require bash. 'dash' wasn't about back then although I've never had a problem in that regard - and the above link isn't something I'm likely to respond to for support requests. It does, however, form the basis of how I build QT so I will update it at some point in the future. Although it requires bash now (yeah local variables!) I've not changed anything I haven't had to thus, should you need to stick with /bin/sh, feel free to liberate what you want. Some if it harks back to redhat 4.x!

Statistics: Posted by swampdog — Sun Jan 21, 2024 10:37 pm

---