UC20 FDE boot flow

Hi,

Got below query while analyzing UC20 boot flow with FDE feature enabled.

If fde-reveal-key unable to unseal the key used for disk encryption, UC20 prompts user to enter the recovery key manually. But Recovery key is also a random key - generated by snapd snap. From anywhere user can get plain recovery key - which user can input to proceed the boot?

To get better understanding of boot flow, I tried to modify snapd disk unlock flow (fde-reveal-key flow) - Updated secboot_sb.go and secboot_hooks.go for this purpose. But changes are not reflecting. Whether UC20 image/base snap includes default snapd which runs before re-mounting of snapd snap in Run mode?

Hi, Can you re-phrase your question? It sounds like you are trying to change behavior in snapd, but it’s not clear what you are changing and what the overall purpose is of those changes.

Thanks,

Ian

Hi,

For our custom requirement, I am customizing FDE hook. Instead of OPTEE based encryption, planning to use custom encryption for sealing the key used for disk encryption. fde-setup hook will seal (encrypt) the key and fde-reveal-key hook will unseal (decrypt) the key. If any error during decryption, fde-reveal-key hook will fail to return unsealed key to snapd.

In this case, UC20 boot flow will halt with below message for input from user.

Please enter the recovery key for disk /dev/disk/by-partuuid/6310f368-f16b-494b-8584-15a0e2471a5d: (press TAB for no echo)

How to make use of this feature to recover and continue the boot? Do we have any method to get plain recovery key? (As my my understanding, recovery key will be generated by snapd and saved as encrypted payload with the help of FDE hook).

For understanding recovery and disk unlock flow, I added debug prints in snapd and generated custom snapd snap . But none of these debug prints are reflecting during UC20 boot. So I got doubt like UC20 image includes default snapd which runs before re-mounting of snapd snap in Run mode. Please correct me if my understanding is wrong.

If you want to see the recovery keys that are generated when the system is installed, you can do so with:

snap recovery --show-keys

while the system is running after the disk has been unlocked. This can also be accessed via the snapd REST API.

Thanks for suggesting the option to get recovery key. Why UC20 boot flow not trying to fetch recover key (ubuntu-data.recovery.sealed-key) with the help of FDE hook? instead it prompts user to input it.

Any comments on this query? Whether UC20 image includes default snapd which runs before re-mounting of snapd snap?

There are two possibilities, one if you are in recover mode, then the fallback key should be attempted to be used, and if that still fails, then we proceed to as a last attempt to unlock the encrypted partitions ask for the passphrase.

If you are not in recover mode, we do not attempt to use the recovery key, and instead immediately fallback to asking for the passphrase. I’m not sure if we have considered using the recovery key if the primary key fails in run mode, but I think the main reason why is that we don’t expect to not be able to use the primary key in run mode. Do you know why your primary key is not usable to unlock?

Well there are two places where “snapd code” runs, there is the snapd snap included in the image which runs in userspace, and there is the snap-bootstrap executable, built from snapd codebase, but included in the kernel’s initramfs image. If your boot has not progressed to userspace, then the snapd code you are seeing execute is snap-bootstrap from the initramfs. If you want to add debug prints etc to snap-bootstrap, it’s not sufficient to just rebuild the snapd snap, you also need to extract snap-bootstrap from that snapd snap, and then inject the snap-bootstrap binary into the kernel snap’s initramfs.

@ijohnson,

Thanks for your detailed reply.

Problem was in customized FDE hook.