0
nezhac

Cubox i CRYPTROOT_ENABLE won't unlock

Recommended Posts

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

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
0