Ptrauth failure with IA key panic on M1 using IOKit

I have a driver that was written with IOKit. It works fine on BigSur with an Intel Processor. It is compiled as a universal binary. Each time I try to use kextload to load the kext, the machine crashes with the following....
panic(cpu 5 caller 0xfffffe001e0b9320): Break 0xC470 instruction exception from kernel. Ptrauth failure with IA key resulted in 0xbffffe001cbc0630 at pc 0xfffffe001df2a5d4, lr 0x0addfe001df2a548 (saved state: 0xfffffe306b8c34e0)  x0: 0xfffffe306b8c3860 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0xfffffe306b8c3890  x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x00626778632e7265 x7: 0x0000000000000d80  x8: 0x000000000000000c x9: 0xfffffe0020892df8 x10: 0x00000000016a016a x11: 0x0000000000000001  x12: 0x00000000016a016a x13: 0x000000000000016a x14: 0xfffffe16669f5448 x15: 0x00000000016a016b  x16: 0xbffffe001cbc0630 x17: 0xfffffe001cbc0630 x18: 0x0000000000000000 x19: 0xfffffe233197ee60  x20: 0x0000000000000001 x21: 0x0000000000000001 x22: 0x8a8afe001cbc0630 x23: 0xfffffe001cb90000  x24: 0xfffffe001d88d971 x25: 0xfffffe001cb88000 x26: 0x0000000000000006 x27: 0x0000000000000006  x28: 0xcda1fe233197ee60 fp: 0xfffffe306b8c38f0 lr: 0x0addfe001df2a548 sp: 0xfffffe306b8c3830  pc: 0xfffffe001df2a5d4 cpsr: 0x80401208    esr: 0xf200c470     far: 0xfffffe30193c4000

Debugger message: panic Memory ID: 0x6 OS release type: User OS version: 20G80 Kernel version: Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:27 PDT 2021; root:xnu-7195.141.2~5/RELEASE_ARM64_T8101 Fileset Kernelcache UUID: E46841F89DC3FD7ACEC6F404AC995579 Kernel UUID: AC4A14A7-8A8E-3AE6-85A6-55E6B2502BF9 iBoot version: iBoot-6723.140.2 secure boot?: YES Paniclog version: 13 KernelCache slide: 0x0000000015c9c000 KernelCache base: 0xfffffe001cca0000 Kernel slide:   0x00000000167e4000 Kernel text base: 0xfffffe001d7e8000 Kernel text exec base: 0xfffffe001d8b4000 mach_absolute_time: 0xc434196c Epoch Time:    sec   usec  Boot  : 0x610c5768 0x00000e2f  Sleep : 0x00000000 0x00000000  Wake  : 0x00000000 0x00000000  Calendar: 0x610c57eb 0x000ebce6

CORE 0 recently retired instr at 0xfffffe001da26d6c CORE 1 recently retired instr at 0xfffffe001da26d6c CORE 2 recently retired instr at 0xfffffe001da26d6c CORE 3 recently retired instr at 0xfffffe001da26d6c CORE 4 recently retired instr at 0xfffffe001da26d70 CORE 5 recently retired instr at 0xfffffe001da256a4 CORE 6 recently retired instr at 0xfffffe001da26d70 CORE 7 recently retired instr at 0xfffffe001da26d70 CORE 0 PVH locks held: None CORE 1 PVH locks held: None CORE 2 PVH locks held: None CORE 3 PVH locks held: None CORE 4 PVH locks held: None CORE 5 PVH locks held: None CORE 6 PVH locks held: None CORE 7 PVH locks held: None CORE 0: PC=0xfffffe00205f0ff0, LR=0xfffffe00205c3c10, FP=0xfffffe3097d5b440 CORE 1: PC=0xfffffe001da1cadc, LR=0xfffffe001db463c4, FP=0xfffffe3097e3b690 CORE 2: PC=0xfffffe001d92da64, LR=0xfffffe001d92da5c, FP=0xfffffe309978bee0 CORE 3: PC=0xfffffe001d92da64, LR=0xfffffe001d92da5c, FP=0xfffffe3097d3bee0 CORE 4: PC=0xfffffe001d92da64, LR=0xfffffe001d92da5c, FP=0xfffffe3097e2bee0 CORE 5 is the one that panicked. Check the full backtrace for details. CORE 6: PC=0xfffffe001d92da64, LR=0xfffffe001d92da5c, FP=0xfffffe3097e1bee0 CORE 7: PC=0xfffffe001d92da64, LR=0xfffffe001d92da5c, FP=0xfffffe3097a2bee0 Panicked task 0xfffffe1667fe1b70: 1825 pages, 3 threads: pid 101: kernelmanagerd Panicked thread: 0xfffffe166a254000, backtrace: 0xfffffe306b8c2bf0, tid: 11112  lr: 0xfffffe001d902b68 fp: 0xfffffe306b8c2c60  lr: 0xfffffe001d90294c fp: 0xfffffe306b8c2cd0  lr: 0xfffffe001da2c1c8 fp: 0xfffffe306b8c2cf0  lr: 0xfffffe001da1d674 fp: 0xfffffe306b8c2da0  lr: 0xfffffe001d8bb7e8 fp: 0xfffffe306b8c2db0  lr: 0xfffffe001d9025dc fp: 0xfffffe306b8c3140  lr: 0xfffffe001d9025dc fp: 0xfffffe306b8c31b0  lr: 0xfffffe001e0b4e80 fp: 0xfffffe306b8c31d0  lr: 0xfffffe001e0b9320 fp: 0xfffffe306b8c3340  lr: 0xfffffe001da1fa50 fp: 0xfffffe306b8c3410  lr: 0xfffffe001da1d9b8 fp: 0xfffffe306b8c34c0  lr: 0xfffffe001d8bb7e8 fp: 0xfffffe306b8c34d0  lr: 0xfffffe001df2a548 fp: 0xfffffe306b8c38f0  lr: 0xfffffe001df2b898 fp: 0xfffffe306b8c3970  lr: 0xfffffe001df30d14 fp: 0xfffffe306b8c39f0  lr: 0xfffffe001df3eaf4 fp: 0xfffffe306b8c3a50  lr: 0xfffffe001df41650 fp: 0xfffffe306b8c3af0  lr: 0xfffffe001df5ce24 fp: 0xfffffe306b8c3b80  lr: 0xfffffe001d967e0c fp: 0xfffffe306b8c3bd0  lr: 0xfffffe001d9082b0 fp: 0xfffffe306b8c3c40  lr: 0xfffffe001d8df960 fp: 0xfffffe306b8c3cc0  lr: 0xfffffe001d8f86f8 fp: 0xfffffe306b8c3d70  lr: 0xfffffe001da11ffc fp: 0xfffffe306b8c3e40  lr: 0xfffffe001da1d6f0 fp: 0xfffffe306b8c3ef0  lr: 0xfffffe001d8bb7e8 fp: 0xfffffe306b8c3f00

last started kext is my kext, which makes sense.

Anyone seen this before and been successful in debugging it?

Thanks

Replies

Apple silicon Macs use arm64e for KEXTs [1], which is why pointer authentication [2] is in the mix here.

As to what’s causing this panic, it’s hard to say based purely on a panic log. If you trigger this with the kernel debugger attached, what does the backtrace look like?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] This, btw, is the only place where we support third-party arm64e code right now.

[2] For more background on this, see Preparing Your App to Work with Pointer Authentication. This is focused on user space code, not KEXTs, so it’s not directly relevant to your issue.

Hi Apple support:

Can you please provide instruction how to enable pointer authentication in the kext code?

Thanks

Peter