Trusty tipc causes panic in irq_handler

I am building a trusty/tipc based application that will store arbitrary data sets in a secure enclave. I have a client application and trusted agent built from the hwkey agent model in jetpack 4.6.1. As part of this application I have defined a set of messages to pass between the HLOS and Trusty environments. The majority of these messages are less than 200 bytes in the current implementation, but there are two messages that are 736 bytes long. Whenever I attempt to send one of these messages I encounter a trusty panic in the irq handler that looks like this:

[ 150.811896] trusty-irq trusty:irq: trusty_panic_notify: trusty crashed, disabling trusty irqs

[ 150.812087] ------------[ cut here ]------------

[ 150.812177] WARNING: CPU: 5 PID: 1940 at /home/Duane/Documents/repos/iPRDImageBuild/build/iprd/src/kernel/kernel-4.9/kernel/irq/manage.c:1882 __free_percpu_irq+0x138/0x140

[ 150.812740] —[ end trace 332d5fe92866a9ce ]—

[ 150.821581] Unable to handle kernel paging request at virtual address dead000000000200

[ 150.821753] Mem abort info:

[ 150.821805] ESR = 0x96000044

[ 150.821859] Exception class = DABT (current EL), IL = 32 bits

[ 150.821957] SET = 0, FnV = 0

[ 150.822010] EA = 0, S1PTW = 0

[ 150.822065] Data abort info:

[ 150.822114] ISV = 0, ISS = 0x00000044

[ 150.822179] CM = 0, WnR = 1

[ 150.822234] [dead000000000200] address between user and kernel address ranges

[ 150.822354] Internal error: Oops: 96000044 [#1] PREEMPT SMP

[ 150.822450] Modules linked in: xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xt_addrtype iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack br_netfilter zram overlay usbhid uvcvideo binfmt_misc ar0821 spidev ip_tables x_tables

[ 150.831063] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G W 4.9.253-g #22

[ 150.838819] Hardware name: NVIDIA Jetson Xavier NX Developer Kit (DT)

[ 150.845251] task: ffffffc3edfe0000 task.stack: ffffffc3edfe8000

[ 150.850994] PC is at trusty_irq_handler+0x64/0x160

[ 150.855973] LR is at trusty_irq_handler+0x54/0x160

[ 150.860703] pc : [] lr : [] pstate: 604001c5

[ 150.868395] sp : ffffffc3ffd94f20

[ 150.871633] x29: ffffffc3ffd94f20 x28: ffffffc3edfe0000

[ 150.877142] x27: ffffffc3ffd9cdd0 x26: ffffffc3ffd95050

[ 150.882496] x25: ffffffc3ffd91060 x24: ffffffc3edc10800

[ 150.888169] x23: 0000000000000001 x22: ffffffc3e74a3400

[ 150.893242] x21: ffffffc3e74a3420 x20: ffffffc3ffda67d8

[ 150.898580] x19: ffffffc3ffda6818 x18: 0000000000000034

[ 150.904267] x17: 000000201094e328 x16: ffffff80082d1d48

[ 150.909710] x15: 0000000000000000 x14: 0000000000429b87

[ 150.915644] x13: 000000000000060a x12: 071c71c71c71c71c

[ 150.921242] x11: 000000000000000b x10: 0000000000000040

[ 150.926597] x9 : ffffff8009d977c0 x8 : ffffffc3ed800000

[ 150.932619] x7 : ffffffc3ed800028 x6 : 0000000000000000

[ 150.938130] x5 : ffffffc3ed800000 x4 : ffffff8009d7b480

[ 150.943468] x3 : 0000000000000020 x2 : dead000000000200

[ 150.948806] x1 : ffffffc3ffda6820 x0 : dead000000000100

[ 150.954141]

[ 150.955305] Process swapper/5 (pid: 0, stack limit = 0xffffffc3edfe8000)

[ 150.961931] Call trace:

[ 150.964301] [] trusty_irq_handler+0x64/0x160

[ 150.969901] [] handle_percpu_devid_irq+0x90/0x2b0

[ 150.975761] [] generic_handle_irq+0x34/0x50

[ 150.980843] [] __handle_domain_irq+0x68/0xc0

[ 150.986705] [] gic_handle_irq+0x5c/0xb0

[ 150.991777] [] el1_irq+0xec/0x19c

[ 150.996074] [] cpuidle_enter_state+0xbc/0x380

[ 151.001924] [] cpuidle_enter+0x34/0x48

[ 151.007002] [] call_cpuidle+0x44/0x78

[ 151.011811] [] cpu_startup_entry+0x160/0x1f8

[ 151.017416] [] secondary_start_kernel+0x198/0x200

[ 151.023365] [<0000000080e731a8>] 0x80e731a8

[ 151.027570] —[ end trace 332d5fe92866a9cf ]—

[ 151.042521] Kernel panic - not syncing: Fatal exception in interrupt

[ 151.042678] SMP: stopping secondary CPUs

[ 151.042781] Kernel Offset: disabled

[ 151.046280] Memory Limit: none

[ 151.049173] trusty-log panic notifier - trusty version Built: 00:09:29 Apr 12 2023 [ 151.067026] Rebooting in 5 seconds…

����Shutdown state requested 1

Rebooting system …

When I dig in a little I see that the address 0xdead000000000200 is associated with the pprev pointer of a link list node for the link list defined in list.h.

In port_create I have set the max message size at 2048 bytes and the number of buffers at 2.

hello duane.hooton,

is it possible for moving to the latest JetPack-4.x release version for confirmation? i.e. Jetpack-4.6.3/l4t-r32.7.3

FYI,
start with Jetpack-5.x, it’s moving to OP-TEE as trusted execution environment.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.