I am running on Sequoia 15.1 24B83 with the appropriate KDK on both my host and target systems. I am trying to examine the target when it has crashed either due to triggering an NMI or causing a crash in my company's kext. I am not getting very far! I can attach from the host to the target. But I can't run any useful commands, starting with showallkexts. It shows up in the list of 'Current user-defined commands' but fails with the above attribute error when I try to run it. I get that same error trying to use other user-defined commands. I followed the host setup instructions in the KDK readme, but this traceback leads me to think I have overlooked something. If this is something folks have seen before, I would appreciate any guidance!

My company has been developing a DriverKit Extension for our ThunderBolt attached devices. The dext is part of a set of components developed to replace a complex kext. Our testing has gone well on Intel based machines, but I seem to be able to cause kernel panics on my M1 Mac Mini when running some tests from an application that sends commands to the dext. The crashes aren't immediate; they happen apparently when the device wakes from sleeping. If I don't enable some particular capabilities on the devices the code works fine. Unfortunately they are LLC crashes and I have no way to debug them. Has anyone dealt with something like this? panic(cpu 6 caller 0xfffffe001f038b94): "LLC Bus error from cpu2: FAR=0x600102068 LLC_ERR_STS/ADR/INF=0x11000ffc00000080/0x4300040600102068/0x5 addr=0x600102068 cmd=0x18(acc_cifl2c_cmd_rd_ld)" @AppleFireStormErrorHandler.cpp:424 Debugger message: panic Memory ID: 0x6 OS release type: User OS version: 21E258 Kernel version: Darwin Kernel Version 21.4.0: Fri Mar 18 00:47:26 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T8101 Fileset Kernelcache UUID: E642C8E63C1D004A6B6639342D386514 Kernel UUID: 79A2DE0A-5FBB-32B8-B226-9D5D3F5C25A4 iBoot version: iBoot-7459.101.3 secure boot?: YES Paniclog version: 13 KernelCache slide: 0x0000000016758000 KernelCache base: 0xfffffe001d75c000 Kernel slide: 0x0000000016ef8000 Kernel text base: 0xfffffe001defc000 Kernel text exec slide: 0x0000000016fe0000 Kernel text exec base: 0xfffffe001dfe4000

Having read in the forums that it is possible for dext instances to find and invoke methods on one another, is there any way for one dext process to share a mapped buffer with another? The requirement would be for the buffer to be persistent, something like mappings created by IOConnectMapMemory, which persist until explicitly unmapped.

The video about Porting to Apple Silicon mentions the Intel/arm64 memory ordering differences and states that 'Correct code' will behave the same but data races may behave differently. What is implied by 'Correct code'? Does that include using memory barriers? Are there any limitations on using memory barriers at the application and DriverKit level? Or for IOKit kexts where they are allowed?