Zkunlockifs segfaults preventing Debian (Raspbian) 12 to boot

ZYMKEY4
1

Hello.
After some recent update my Raspberry Pi4 with Debian 12 aarch64 won’t boot anymore.
The Pi has FDE with Zymkey and it fails to find /dev/mapper/cryptrfs.
I read through FDE setup script and tried to run /lib/cryptsetup/scripts/zk_get_key, which seg faults. I guess this it the cause of the boot failure.
zk_get_key MD5 is f7dae8167de29e3102e36e95ddc0bca8 which is consistent across my Pis, doesn’t seem to be corrupted.

Any suggestion on how can I debug this further? Is it a known issue with a recent Debian 12?

2

Just realized /lib/cryptsetup/scripts/zk_get_key is a script.
It looks like the script is able to find /sys/class/net/eth0, there is no /etc/zymbit_mac_address or /var/lib/zymbit/zkenv.conf configured.
/var/lib/zymbit/key.bin.lock file exists and it is not empty. However /sbin/zkunlockifs seg faults.

3

Tried to install Debian 12 on a new SD card and encrypted it with Zymkey. Worked fine and survived couple reboots.
Once I’ve installed latest Debian 12 updates the system started to fail to boot with the same symptoms.
I guess there something Zymbit needs to fix to make zkunlockifs to be compatible with latest Debian 12 (Raspberry Pi OS 12).

4

zk_get_key is a script that uses the ZYMKEY to unlock your LUKS key. The zymbit_mac_address is a hook to allow changing the MAC and is not necessary. /var/lib/zkenv.conf is used to pass environment variables for cases like when you need to move I2C, which also is not relevant to your setup. zkunlockifs seg fault is the problem.

You mentioned a recent update. Did that update your kernel? I’m wondering if you have a mismatch between your kernel and /lib/modules? Can you check that?

5

Actually you’re right.
In initrd I have /lib/modules/6.1.0-rpi7-rpi-v8, while uname in busybox reports 6.6.20-1+rpt1
It looks like upon kernel upgrade initrd wasn’t updated for some reason…

6

After re-generating initramfs for the new test SD card (I’ve added a passphrase along with Zymkey this time) I ended up with zkunlockifc reporting “ERROR: no zymkeys installed.”

Even after I’ve booted to OS, zkunlockifc still reports the same.
i2c modules are inserted (i2c_dev, i2c_bcm2708, i2c_bcm2835 & i2c_brcmstb), /dev/i2c-1 exists.
LED blinks fast, like there is no binding.
zkifc reports “could not open “/dev” dir, errno=24”. After zkifc service restart there is no error, but still LED blinks fast and zkunlockifc won’t work.

7

Can you check the udev rules in your initramfs.

We also implement a udev rule for the zymkey in /etc/udev/rules.d/80-zymkey.rules

with the entry:
KERNEL==“ttyACM[0-9]*”, SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, ATTRS{manufacturer}==“Zymbit, Inc.”, ATTRS{product}==“Zymkey”, SYMLINK+=“zymkey_%n”, OWNER=“zymbit”

8

The rule is there:

# cat /etc/udev/rules.d/80-zymkey.rules
KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{manufacturer}=="Zymbit, Inc.", ATTRS{product}=="Zymkey", SYMLINK+="zymkey_%n", OWNER="zymbit"
KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{manufacturer}=="Zymbit, Inc.", ATTRS{product}=="Zymbit Secure Compute Module", SYMLINK+="zscm_%n", OWNER="zymbit"

However there is no any ttyACM device:

# find /dev -name 'ttyA*'
#

Btw, on Debian 11 there is also no ttyACM device, only ttyAMA with serial1 symlink:

# find /dev -name 'ttyA*'
/dev/ttyAMA0
# ll /dev | grep -e serial -e ttyA
lrwxrwxrwx 1 root root           7 Dec 25 18:46 serial1 -> ttyAMA0
crw-rw---- 1 root dialout 204,  64 Dec 25 18:49 ttyAMA0
#
9

@Bob_of_Zymbit @Eric_of_Zymbit Any other idea on how to debug this?

10

@afunix I think that rule might have covered legacy OSs. I don’t think it is used in bookworm. You are correct in that the names don’t match in bookworm.

My guess is the move to 6.6.20 is still the culprit. Debian/RaspberryPi changed the way GPIO numbering is handled. Another customer ran into this issue. Can you try this?

https://community.zymbit.com/t/zymkey-doesnt-bind-properly/1633/11?u=bob_of_zymbit

11

Thank you! The GPIO numbering was indeed the issue.
I can boot now.

12

We have incorporated this fix into the install script now. New installs will properly set the WAKE_PIN.