CAAM api change
caam_jr_enqueue, a function which once returned 0 on success now returns a non-zero value for a pending transaction and existing logic being forward ported was breaking as a result; the kernel was consistently panicking. The resulting splatter made recognizing the issue surprisingly tricky. Luckily I ran into this:
https://github.com/usbarmory/caam-keyblob/issues/11
in particular this glorious mofo:
https://github.com/usbarmory/caam-keyblob/issues/11#issuecomment-955053044
who shared this:
I think, the problem lies in
https://github.com/f-secure-foundry/caam-keyblob/blob/2e303fa357f6ec69199ba6e45ae9e9088a43ca3b/caam_keyblob.c#L413
and
https://github.com/f-secure-foundry/caam-keyblob/blob/2e303fa357f6ec69199ba6e45ae9e9088a43ca3b/caam_keyblob.c#L513
The return behavior of caam_jr_enqueue slightly changed in kernel 5.7. When
previously it returned 0 on success, it now returns EINPROGRESS:
torvalds/linux@4d370a1#diff-8acc41c534456288daba59a125ddb3f779635dc493ff4888545adbf1dd0a17c1R417
https://github.com/torvalds/linux/blob/4d370a1036958d7df9f1492c345b4984a4eba7f6/drivers/crypto/caam/jr.c#L417
Accordingly, the next lines should not be
if(!res) {
but
if(res == -EINPROGRESS) {
It's probably just this fix in line
https://github.com/f-secure-foundry/caam-keyblob/blob/2e303fa357f6ec69199ba6e45ae9e9088a43ca3b/caam_keyblob.c#L415
and
https://github.com/f-secure-foundry/caam-keyblob/blob/2e303fa357f6ec69199ba6e45ae9e9088a43ca3b/caam_keyblob.c#L515
Unfortunately, I don't have any hardware available to test and debug right now,
so I'll have to leave the actual fix to someone else.
Which swiftly led to cthulu’s noodle appendages retreating from my personal foreground as doors opened.
dtb loadaddr suddenly needs to be specified
Another issue I hit was that my device would not longer boot. The device died at:
Starting Linux ...
if you enabled early printk, you then get to see roughly this
Starting kernel ...
Error: invalid dtb and unrecognized/unsupported machine ID
r1=0x00000f8c, r2=0x10000100
r2[]=05 00 00 00 01 00 41 54 00 00 00 00 00 00 00 00
Available machine support:
ID (hex) NAME
ffffffff Generic DT based system
ffffffff Freescale i.MX6 Quad/DualLite (Device Tree)
ffffffff SCI XPHUB (Device Tree)
ffffffff Freescale i.MX6 SoloLite (Device Tree)
ffffffff Freescale i.MX6 SoloX (Device Tree)
ffffffff Freescale i.MX6 Ultralite (Device Tree)
ffffffff Freescale i.MX7 Dual (Device Tree)
ffffffff Freescale i.MX50 (Device Tree Support)
ffffffff Freescale i.MX51 (Device Tree Support)
ffffffff Freescale i.MX53 (Device Tree Support)
ffffffff Freescale Vybrid VF5xx/VF6xx (Device Tree)
ffffffff Freescale LS1021A
ffffffff ARM-Versatile Express
You should read the NXP thread:
https://community.nxp.com/t5/i-MX-Processors/Kernel-bump-from-3-0-35-to-5-10/td-p/1539576
I did not find the responses particularly helpful.
My dtb which is packed in a fitimage appeared to now suddenly be being unpacked to a bogus location. Kind odd bug to hit when jumping kernel versions. This intepretation was bolstered by the fact NFS booting the same kernel with an explicitly placed version of the same device tree was working. I assumed some secondary mechanism had previously been making this work, despite a malconfigured (turns out an actually absent) fitimage loadaddr. Introducing an explicit loadaddr to the dtb entry in fitimage config did acually end up resolving the issue and the kernel proceeded to boot.