Cubox i CRYPTROOT_ENABLE won't unlock

[nezhac]

Hi,

I've been trying to setup a Cubox i with a buster image, encrypted root and ssh unlock. I cloned the git on 15th of August at commit `1a06bea5f31767b4983985c6592b78e288a85b99`.

I used the following build options:

./compile.sh BOARD=cubox-i CRYPTROOT_ENABLE=yes CRYPTROOT_PASSPHRASE="abc" CRYPTROOT_SSH_UNLOCK=yes CRYPTROOT_SSH_UNLOCK_PORT=2222 KERNEL_ONLY=no KERNEL_CONFIGURE=no BUILD_DESKTOP=no BRANCH=next RELEASE=buster

I've tried using both 'dd' and 'etcher-cli' to burn the image, with identical results. The board boots, I can see the initial u-boot startup screen, then it goes black. Which something I've seen many times with the Cubox i on various distributions: the screen goes black after u-boot and then comes back on later in the boot process.

 

I can ssh in from my laptop using the key provided during the build. However, when I try to `cryptroot-unlock` nothing happens. There is no error message, no password prompt, no return message. A quick look at `top` shows the board isn't doing much, load is low and no process is using much CPU. A `cat /proc/modules` returns nothing either, I would have thought at least some modules should be present.

 

I then tried the normal buster image from the torrent. This booted fine, with the same black screen after u-boot, and screen output returning later on in the boot process. Things seemed to work perfectly, network, USB, updating the system.

I then used this buster image to try and create an encrypted Armbian install on another microSD card, using this post as a starting point. Again, I got a similar result as before, `cryptroot-unlock` didn't do anything and `cat /proc/modules` showed nothing was loaded.

 

I've previously used the build system to successfully build and boot an encrypted buster install with the same options but for an Olimex Lime2 board, so I assume my builds are working. On the lime2, when I do `cat /proc/modules` I can see several modules, some of which are related to `dm-crypt`. I'm using a dedicated Ubuntu 18.04 x86 machine, as per the documentation, for my build environment.

 

Is this a problem with the Cubox i? I've got the feeling the necessary modules aren't properly added when building the initramfs, although the following commands seem to show they're there:

gunzip -c /boot/initrd.img* | cpio --quiet -t | grep cryptsetup

 

I should note I've previously successfully setup a similar encrypted root + dropbear unlock system using Arch, although the u-boot and kernel versions were different.

 

Any ideas or insights?

Thanks

[Igor]

That's all we did with this feature. It's more or less an uncharted territory.

[sfx2000]

On 8/16/2019 at 1:38 AM, nezhac said:

Is this a problem with the Cubox i?

 

Could be - as once one gets into secure boot - one of the ARM chips I'm working on right now - it has a separate boot processor that is underneath the application space (e.g. Linux) - in my case, it's another core - ARM11 vs the ARMv7A that the OS runs on.

 

There are OTP's and/or eFuses that are popped depending on the SoC, along with the stored keys.

 

That's all I can say right now (forrest gump voice)

[nezhac]

This seems to have been solved with the upgrade to 5.3 kernel

I can get a bootable rootfs with LVM on LUKS by transferring it over from a non-encrypted standard Armbian image

Haven't tried build option CRYPTROOT_ENABLE but I suspect it'll be solved too