Hello all, I am interested in developing a small driver that would facilitate host-to-host communication via Thunderbolt 4/5. While I am aware of features such as Thunderbolt Bridge/Thunderbolt Networking, I find that for my application the overhead is too great. I am interested in sharing a simple, static memory buffer between the two hosts for IO and with some synchronisation primitives. The idea being that the communication is facilitated between different platforms. Would it be possible to develop a driver/service like this? Currently, going through the documentation, to use PCIDriverKit specifying a Vendor and Product Ids is required, so I doubt that this is a viable path. I know that Linux exposes the "XDomain" protocol to announce thunderbolt services (This is the same protocol that is used in macOS to discover Thunderbolt Networking peers). Is this functionality exposed to macOS driver developers?

Hi everyone, I was following the Video Modernize PCI and SCSI drivers with DriverKit and the Document to implement UserMapHBAData(), and here’s my current implementation: // kern_return_t DRV_MAIN_CLASS_NAME::UserMapHBAData_Impl(uint32_t *uniqueTaskID) kern_return_t IMPL(DRV_MAIN_CLASS_NAME, UserMapHBAData) { Log("UserMapHBAData() - Start"); // Define the vm_page_size explicitly const uint32_t vm_page_size = 4096; kern_return_t ret; IOBufferMemoryDescriptor *buffer = nullptr; IOMemoryMap *memMap = nullptr; void *taskData = nullptr; // Create a buffer for HBA-specific task data ret = IOBufferMemoryDescriptor::Create(kIOMemoryDirectionOutIn, ivars->fTaskDataSize, vm_page_size, &buffer); __Require((kIOReturnSuccess == ret), Exit); // Map memory to the driver extension's memory space ret = buffer->CreateMapping(0, 0, 0, 0, 0, &memMap); __Require((kIOReturnSuccess == ret), Exit); // Retrieve mapped memory address taskData = reinterpret_cast<void *>(memMap->GetAddress()); __Require(taskData, Exit); // WARNING: Potential leak of an object stored into 'buffer' // WARNING: Potential leak of an object stored into 'memMap' // Assign a unique task ID ivars->fTaskID++; // ERROR: No member named 'fTaskID' in 'DriverKitAcxxx_IVars' ivars->fTaskArray[ivars->fTaskID] = taskData; *uniqueTaskID = ivars->fTaskID; Log("UserMapHBAData() - End"); return kIOReturnSuccess; Exit: // Cleanup in case of failure if (memMap) { memMap->free(); // Correct method for releasing memory maps } if (buffer) { buffer->free(); // Correct method for releasing buffer memory } LogErr("ret = 0x%0x", ret); Log("UserMapHBAData() - End"); return ret; } For reference, in KEXT, memory allocation is typically done using: IOBufferMemoryDescriptor *buffer = IOBufferMemoryDescriptor::inTaskWithOptions( kernel_task, // Task in which memory is allocated kIODirectionOutIn, // Direction (read/write) 1024, // Size of the buffer in bytes 4); // Alignment requirements However, after installing the dext, macOS hangs, and I have to do a hardware reset. After rebooting, the sysctl list output shows: % sectl list 1 extension(s) --- com.apple.system_extension.driver_extension enabled active teamID bundleID (version) name [state] * - com.accusys.DriverKitAcxxx (5.0/11) com.accusys.DriverKitAcxxx [activated waiting for user] Questions: What could be causing macOS to halt? How should I approach debugging and resolving this issue? Looking forward to your insights, any suggestions would be greatly appreciated! Best regards, Charles

Hello everyone. I have been developing PCIe device driver through Thunderbolt. However, it was confirmed that up to three devices connected to the daisy chain worked normally, but the fourth device failed to operate the _CopyDeviceMemoryWithIndex() function for connection with the BAR0 App and did not work properly. The standard specification of Thunderbolt 3/4 is said to be supported by daisy chain connection up to 6-device, but in reality, it is only 3 units, so I ask the forum for technical confirmation. Of course total 4 device by 2-port x 2-device daisy chain connecting has working well. The PCI entry in System information indicates that all devices have normal load of the PCIe device driver. Thank you.

Hello everyone I have been developing PCIe device driver through Thunderbolt. However, it was confirmed that up to three devices connected to the daisy chain worked normally, but the fourth device failed to operate the _CopyDeviceMemoryWithIndex() function for connection with the BAR0 App and did not work properly. The standard specification of Thunderbolt 3/4 is said to be supported by daisy chain connection up to 6 units, but in reality, it is only 3 units, so I ask the forum for technical confirmation. Of course total 4 device by 2-port x 2-device daisy chain connecting has working well. And the PCI entry in System information app indicates that all devices have normal load of the PCIe device driver.

Hello everyone, I’m working on implementing hardware interrupt handling in DriverKit and came across the InterruptOccurred method in IOInterruptDispatchSource. I noticed that its declaration ends with a TYPE macro: virtual void InterruptOccurred(OSAction* action, uint64_t count, uint64_t time) TYPE(IOInterruptDispatchSource::InterruptOccurred); This structure seems similar to how Timer Events are set up, where an event is linked to a callback and triggered by a timer. I’m attempting to use a similar approach, but for hardware-triggered interrupts rather than timer events. I’m currently in the trial-and-error phase of the implementation, but if anyone has a working example or reference on how to properly implement and register InterruptOccurred, it would be greatly appreciated! Best regards, Charles

Hello Everyone, I'm encountering an issue while setting up a timer event in DriverKit and would appreciate any guidance. Here's my current implementation: void DRV_MAIN_CLASS_NAME::SetupEventTimer() { // 1. Create dispatch queue kern_return_t ret = IODispatchQueue::Create("TimerQueue", 0, 0, &ivars->dispatchQueue); if (ret != kIOReturnSuccess) { LogErr("Failed to create dispatch queue: 0x%x", ret); return; } // 2. Create timer source ret = IOTimerDispatchSource::Create(ivars->dispatchQueue, &ivars->dispatchSource); if (ret != kIOReturnSuccess) { LogErr("Failed to create timer: 0x%x", ret); OSSafeReleaseNULL(ivars->dispatchQueue); return; } /*! * @brief Create an instance of OSAction. * @discussion Methods to allocate an OSAction instance are generated for each method defined in a class with * a TYPE attribute, so there should not be any need to directly call OSAction::Create(). * @param target OSObject to receive the callback. This object will be retained until the OSAction is * canceled or freed. * @param targetmsgid Generated message ID for the target method. * @param msgid Generated message ID for the method invoked by the receiver of the OSAction * to generate the callback. * @param referenceSize Size of additional state structure available to the creator of the OSAction * with GetReference. * @param action Created OSAction with +1 retain count to be released by the caller. * @return kIOReturnSuccess on success. See IOReturn.h for error codes. */ // 3: Create an OSAction for the TimerOccurred method // THIS IS WHERE I NEED HELP OSAction* timerAction = nullptr; ret = OSAction::Create(this, 0, 0, 0, &timerAction); if (ret != kIOReturnSuccess) { LogErr("Failed to create OSAction: 0x%x", ret); goto cleanup; } // 4. Set handler ret = ivars->dispatchSource->SetHandler(timerAction); if (ret != kIOReturnSuccess) { LogErr("Failed to set handler: 0x%x", ret); goto cleanup; } // 5. Schedule timer (1 second) uint64_t deadline = mach_absolute_time() + NSEC_PER_SEC; ivars->dispatchSource->WakeAtTime(0, deadline, 0); cleanup: if (ret != kIOReturnSuccess) { OSSafeReleaseNULL(timerAction); OSSafeReleaseNULL(ivars->dispatchSource); OSSafeReleaseNULL(ivars->dispatchQueue); } } Problem: The code runs but the OSAction callback binding seems incorrect (Step 3). According to the OSAction documentation, I need to use the TYPE macro to properly bind the callback method. But I try to use TYPE(DRV_MAIN_CLASS_NAME::TimerOccurred) kern_return_t TimerOccurred() LOCALONLY; TYPE(TimerOccurred) kern_return_t TimerOccurred() LOCALONLY; kern_return_t TimerOccurred() TYPE(DRV_MAIN_CLASS_NAME::TimerOccurred) LOCALONLY; All results in Out-of-line definition of 'TimerOccurred' does not match any declaration in 'DRV_MAIN_CLASS_NAME' Questions: What is the correct way to declare a timer callback method using TYPE? How to get the values targetmsgid & msgid generated by Xcode? Any help would be greatly appreciated! Best Regards, Charles

Hello Everyone, I encountered an issue with PCI memory access in DriverKit. In my case, BAR0 is not available, but BAR1 is ready for use. Here’s the log output: !!! ERROR : Failed to get BAR0 info (error: 0xe00002f0). !!! BAR1 - MemoryIndex: 0x00000000, Size: 0x00040000, Type: 0 Issue Description When I initially wrote to BAR0 using memoryIndex = 0, it worked successfully: AME_Address_Write_32(pAMEData, pAMEData->memoryIndex, AME_HOST_INT_MASK_REGISTER, 0x0F); However, I mistakenly forgot to update memoryIndex to 1 for BAR1. Surprisingly, the write operation still succeeded. When I fixed memoryIndex = 1 for BAR1, the write operation no longer had any effect. There was no error, but the expected behavior did not occur. Relevant API (From IOPCIDevice.iig) /*! /*! * @brief Writes a 32-bit value to the PCI device's aperture at a given memory index. * @discussion This method writes a 32-bit register on the device and returns its value. * @param memoryIndex An index into the array of ranges assigned to the device. * @param offset An offset into the device's memory specified by the index. * @param data A 32-bit value to be written in host byte order. */ void MemoryWrite32(uint8_t memoryIndex, uint64_t offset, uint32_t data) LOCALONLY; Log Output: Writes to BAR0 (memoryIndex = 0) AME_Address_Write_32() called memoryIndex: 0, offset: 0x34, data: 0xf Wrote data 0xF to offset 52 AME_Address_Write_32() called memoryIndex: 0, offset: 0xa0, data: 0x1 Wrote data 0x1 to offset 160 AME_Address_Write_32() called memoryIndex: 0, offset: 0x20, data: 0xffffffff Wrote data 0xFFFFFFFF to offset 32 Writes to BAR1 (memoryIndex = 1) – No Response AME_Address_Write_32() called memoryIndex: 1, offset: 0x34, data: 0xf No confirmation log, no visible effect. Questions What should memoryIndex be set to for BAR1? The log shows "BAR1 - MemoryIndex: 0x00000000", but should I be using 1 instead? How can I verify if a write operation to BAR1 is successful? Is there a way to check if the memory region is actually writable? Should I use MemoryRead32() to confirm the written value? Any guidance would be greatly appreciated! Best Regards, Charles

We have a macOS application which interacts with our USB and PCI devices to perform SCSI and NVME commands on them. We use IOUSBHost, IOUSBLib and IOKitLib for USB interface and have created a custom driver to interact with PCI devices. Is there a way we can implement a similar functionality for iOS as well if we connect the cards and readers using OTG?

Hello Everyone, I am trying to create a Fake SCSI target based on SCSIControllerDriverKit.framework and inherent from IOUserSCSIParallelInterfaceController, here is the code kern_return_t IMPL(DRV_MAIN_CLASS_NAME, Start) { ... // Programmatically create a null SCSI Target SCSIDeviceIdentifier nullTargetID = 0; // Example target ID, adjust as needed ret = UserCreateTargetForID(nullTargetID, nullptr); if (ret != kIOReturnSuccess) { Log("Failed to create Null SCSI Target for ID %llu", nullTargetID); return ret; } ... } According the document UserCreateTargetForID, after creating a TargetID successfully, the framework will call the UserInitializeTargetForID() The document said: As part of the UserCreateTargetForID call, the kernel calls several APIs like UserInitializeTargetForID which run on the default dispatch queue of the dext. But after UserCreateTargetForID created, why the UserInitializeTargetForID() not be invoked automatically? Here is the part of log show init() - Start init() - End Start() - Start Start() - try 1 times UserCreateTargetForID() - Start Allocating resources for Target ID 0 UserCreateTargetForID() - End Start() - Finished. UserInitializeController() - Start - PCI vendorID: 0x14d6, deviceID: 0x626f. - BAR0: 0x1, BAR1: 0x200004. - GetBARInfo() - BAR1 - MemoryIndex: 0, Size: 262144, Type: 0. UserInitializeController() - End UserStartController() - Start - msiInterruptIndex : 0x00000000 - interruptType info is 0x00010000 - PCI Dext interrupt final value, return status info is 0x00000000 UserStartController() - End Any assistance would be greatly appreciated! Thank you in advance for your support. Best regards, Charles

Hello Everyone, I am trying to develop a DriverKit for RAID system, using PCIDriverKit & SCSIControllerDriverKit framework. The driver can detect the Vendor ID and Device ID. But before communicating to the RAID system, I would like to simulate a virtual Volume using a memory block to talk with macOS. In the UserInitializeController(), I allocated a 512K memory for a IOBufferMemoryDescriptor* volumeBuffer, but fail to use Map() to map memory for volumeBuffer. result = ivars->volumeBuffer->Map( 0, // Options: Use default 0, // Offset: Start of the buffer ivars->volumeSize, // Length: Must not exceed buffer size 0, // Flags: Use default nullptr, // Address space: Default address space &mappedAddress // Output parameter ); Log("Memory mapped completed at address: 0x%llx", mappedAddress); // this line never run The Log for Map completed never run, just restart to run the Start() and makes this Driver re-run again and again, in the end, the driver eat out macOS's memory and system halt. Are the parameters for Map() error? or I should not put this code in UserInitializeController()? Any help is appreciated! Thanks in advance. Charles

Hi Everybody, Follow Communicating between a DriverKit extension and a client app to migrate our kext to dext. The dext might have been loaded successfully by using the command systemextensionsctl list, the dext is loaded and enabled. % sectl list 1 extension(s) --- com.apple.system_extension.driver_extension enabled active teamID bundleID (version) name [state] * * K3TDMD9Y6B com.accusys.scsidriver (1.0/1) com.accusys.scsidriver [activated enabled] We try to use the CppUserClient.cpp to communicate with the dext, but can not get the dext service. The debug message as below: Failed opening service with error: 0xe00002c7. Here is the part of CppUserClient.cpp static const char* dextIdentifier = "com.accusys.scsidriver"; kern_return_t ret = kIOReturnSuccess; io_iterator_t iterator = IO_OBJECT_NULL; io_service_t service = IO_OBJECT_NULL; ret = IOServiceGetMatchingServices(kIOMasterPortDefault, IOServiceMatching("IOUserServer"), &iterator); printf("dextIdentifier = %s\n", dextIdentifier); printf("IOServiceNameMatching return = %d\n", ret); if (ret != kIOReturnSuccess) { printf("Unable to find service for identifier with error: 0x%08x.\n", ret); PrintErrorDetails(ret); } printf("Searching for dext service...\n"); while ((service = IOIteratorNext(iterator)) != IO_OBJECT_NULL) { // Open a connection to this user client as a server to that client, and store the instance in "service" ret = IOServiceOpen(service, mach_task_self_, kIOHIDServerConnectType, &connection); if (ret == kIOReturnSuccess) { printf("\tOpened service.\n"); break; } else { printf("\tFailed opening service with error: 0x%08x.\n", ret); } IOObjectRelease(service); } IOObjectRelease(iterator); if (service == IO_OBJECT_NULL) { printf("Failed to match to device.\n"); return EXIT_FAILURE; } The console output message is dextIdentifier = com.accusys.scsidriver IOServiceNameMatching return = 0 Searching for dext service... Failed opening service with error: 0xe00002c7. Failed opening service with error: 0xe00002c7. Failed opening service with error: 0xe00002c7. Failed opening service with error: 0xe00002c7. Failed to match to device. Here is the log show message fredapp start UserInitializeController pcitest: fredapp pci vendorID: 14d6 deviceID: 626f fredapp nnnnnew configuaration read32 0x10 info: 1 fredapp nnnnnew configuaration read32 0x14 info: 80100004 fredapp new 128 before enable busmaster ReqMSGport_info 0x00000040 : fffff pcitest: fredapp 131 pci ConfigurationRead16 busmaster value 0 pcitest: fredapp 134 Enable BusMaster and IO space done...... locate 139 fredapp MemoryWrite32 function done...... fredapp new 143 after enable busmaster ReqMSGport_info 0x00000040 : 0 fredapp newwww before GetBARInfo memoryIndex1 info is: 5 fredapp GetBARInfo 1 kernel return status is: 0 fredapp GetBARInfo memoryIndex1 info is: 0 fredapp GetBARInfo barSize1 info is: 262144 fredapp GetBARInfo barType1 info is: 0 fredapp GetBARInfo result0 info is: 3758097136 fredapp GetBARInfo memoryIndex0 info is: 0 fredapp GetBARInfo barSize0 info is: 0 fredapp GetBARInfo barType0 info is: 0 pcitest: newwww fredapp againnnn test ReqMSGport info: 8 fredapp Start MPIO_Init_Prepare fredapp end MPIO_Init_Prepare. fredapp call 741 Total_memory_size: 1bb900 fredapp Start MemoryAllocationForAME_Module. fredapp IOBufferMemoryDescriptor create return status info is kIOReturnSuc fredapp IOBufferMemoryDescriptor virtualAddressSegment address info: 0x1 fredapp virtualAddressSegment length info: 0x00080000 fredapp end IOBufferMemoryDescriptor Create. fredapp dmaSpecification maxAddressBits: 0x00000000 fredapp dmaSpecification maxAddressBits: 0x00000027 fredapp IODMACommand create return status info is kIOReturnSuccess fredapp end IODMACommand Create. fredapp PrepareForDMA return status info is kIOReturnSuccess fredapp PrepareForDMA return status info is 0x00000000 fredapp Allocate memory PrepareforDMA return flags info: 0x00000003 fredapp Allocate memory PrepareforDMA return segmentsCount info: 0x00000 fredapp Allocate memory PrepareforDMA return physicalAddressSegment info: fredapp IOBufferMemoryDescriptor virtualAddressSegment address info-2: 0 fredapp verify data success init() - Finished. fredapp start UserGetDMASpecification fredapp end UserGetDMASpecification fredapp start UserMapHBAData fredapp end UserMapHBAData fredapp start UserStartController fredapp interruptType info is 0x00010000 fredapp PCI Dext interrupt final value return status info is 0x00000000 Any suggestions? Best Regards, Charles

I would like to know if macOS DEXT supports the following networking features: Tx/Rx Multiqueue, RSS, RSC, NS/ARP offload, PTP or packet timestamping and TSN. I couldn't find relevant documentation for these features in the Apple Developer Documentation. If they are supported, could you let me know which features are supported and how to find the corresponding official Apple documentation? Thanks

Hi, I’m developing my own Pcie Ethernet driverkit. My Pcie Ethernet card connect on Razor Core X and connect to MacBook via thunderbolt 3. The Problem: Click Driver application and send activate system extension request, then go to System setting -> Privacy & Security, in Extension section ->click “allow” , the peripherals malfunction immediately after "allow" clicked and type in the password.I can't control all peripherals devices like touchpad, keyboard and all of thunderbolt ports. However, it can regain functionality after plugging and unplugging the device. results I expected: User approve Driver Extensions enable and all peripherals work normally and Ethernet Card works. Has anyone encountered this problem? maybe something wrong in "OSSystemExtensionRequestDelegate" but I have no idea how to fix it Please Help. My Xcode version is Version 15.3 (15E204a). Thanks

I have a DriverKit system extension (dext) that uses PCIDriverKit. I would like to get the build environment straightened out to successfully distribute the dext and associated software to end users. There are three types of software involved: The Dext-hosting application - this is the application that must be installed to /Applications/, and will perform the registration of the dext. The dext is deployed "within" this application, and can be found in the /Contents/Library/SystemExtensions folder of the app bundle. The dext itself - this is the actual binary system extension, which will be registered by its owning application, and will operate in its own application space independent of the hosting application. Additional applications that communicate with the dext - these are applications which will connect to the dext through user clients, but these applications do not contain the dext themselves. There are multiple locations where settings need to be exactly correct for each type of software to be signed, provisioned, and notarized properly in order to be distributed to users: developer.apple.com - where "identifiers" and "provisioning profiles" are managed. Note that there are differences in access between "Team Agent", "Admin", and "Developer" at this site. Xcode project's Target "Signing & Capabilities" tab - this is where "automatically manage signing" can be selected, as well as team selection, provisioning profile selection, and capabilities can be modified. Xcode project's Target "Build Settings" tab - this is where code signing identity, code signing development team, code signing entitlements file selection, Info.plist options and file selection, and provisioning profile selection. Xcode's Organizer window, which is where you manage archives and select for distribution. In this case, I am interested in "Developer ID" Direct Distribution - I want the software signed with our company's credentials (Team Developer ID) so that users know they can trust the software. Choosing "automatically manage signing" does not work for deployment. The debug versions of software include DriverKit (development) capability (under App ID configuration at developer.apple.com), and this apparently must not be present in distributable provisioning. I believe this means that different provisioning needs to occur between debug and release builds? I have tried many iterations of selections at all the locations, for all three types of binaries, and rather than post everything that does not work, I am asking, "what is supposed to work?"

I have an app that is used to control features of a device with a driverkit driver. I am having trouble creating a connection a certain device. The Sample code from "Communicating between a DriverKit extension and a client app. The sample code shows: ret = IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceNameMatching(kDextIdentifier), &iterator); I cannot use kDextIdentifier but need to find a service with a certain BSD Name. So in this case I try: ret = IOServiceGetMatchingServices(kIOMainPortDefault, IOBSDNameMatching(kIOMasterPortDefault, NULL, interface), &iterator); In each case the call completes correctly, and we get an iterator. I can also use IOServiceGetMatchingService with IOBSDNameMatching, and that completes correctly as well. However when I attempt IOServiceOpen with the first case, the connection is created correctly. However, I have four of these in the machine, and I need to select the service and subsequently connection for a certain BSD name. When I attempt the IOServiceOpen with the second/third calls, the IOServiceOpen call fails with error 0x2c7 which is unsupported. Is there an entitlement I need to make this work?

I am porting a working kernel extension IOKit driver to a DriverKit system extension. Our device is a PCI device accessed through Thunderbolt. The change from IOPCIFamily to PCIDriverKit has some differences in approach, though. Namely, in IOKit / IOPCIFamily, this was the correct way to become Bus Leader: mPCIDevice->setBusLeadEnable(true); // setBusMasterEnable(..) deprecated in OS 12.4 but now, PCIDriverKit's IOPCIDevice does not have that function. Instead I am doing the following: // Set Bus Leader and Memory Space enable uint16_t commandRegister = 0; ivars->mPCIDevice->ConfigurationRead16(kIOPCIConfigurationOffsetCommand, &commandRegister); commandRegister |= (kIOPCICommandBusLead | kIOPCICommandMemorySpace); ivars->mPCIDevice->ConfigurationWrite16(kIOPCIConfigurationOffsetCommand, commandRegister); But I am not convinced this is working (I am still experiencing unexpected errors when attempting to DMA from our device, using the same steps that work for the kernel extension). The only hint I can find in the online documentation is here, which reads: Note The endpoint driver is responsible for enabling the Memory Space Enable and Bus Master Enable settings each time it configures the PCI device. When a crash occurs, or when the system unloads your driver, the system disables these features. ...but that does not state directly how to enable bus leader status. What is the "PCIDriverKit approved" way to become bus leader? Is there a way to verify/confirm that a device is bus leader? (This would be helpful to prove that bus leadership is not the issue for DMA errors, as well as to confirm that bus leadership was granted). Thanks in advance!

I am developing a PCIDriverKit dext, and testing on Sequoia Beta (Version 15.0 Beta, 24A5298h). Both the dext and the "owning" application build on Xcode 16.0 beta 4. I can run the owning application and register the dext. When the OS attempts to load the dext, though, code signing validation errors occur: 2024-07-30 15:54:02.386 Df kernel[0:ae6a] Driver com.company.Dext-Loader.dext has crashed 0 time(s) 2024-07-30 15:54:02.386 Df kernel[0:ae6a] DK: Dext_Loader_Driver-0x100001464 waiting for server com.company.Dext-Loader.dext-100001464 2024-07-30 15:54:02.388 Df kernelmanagerd[112:abb5] Found 1 dexts with bundle identifier com.company.Dext-Loader.dext 2024-07-30 15:54:02.388 Df kernelmanagerd[112:abb5] Using unique id a0cf49ca3ea45f5d54a3e8644e2dde6b0e8666c649c1e9513ca4166919038b53 to pick dext matching bundle identifier com.company.Dext-Loader.dext 2024-07-30 15:54:02.388 Df kernelmanagerd[112:abb5] Picked matching dext for bundle identifier com.company.Dext-Loader.dext: Dext com.company.Dext-Loader.dext v34 in executable dext bundle com.company.Dext-Loader.dext at /Library/SystemExtensions/B1BF8CDC-CB24-4F25-A8CA-D7A60D814861/com.company.Dext-Loader.dext.dext 2024-07-30 15:54:02.389 I kernel[0:ae71] igmp_domifreattach: reattached igmp_ifinfo for ifp XHC 2024-07-30 15:54:02.389 I kernel[0:ae71] mld_domifreattach: reattached mld_ifinfo for ifp XHC2 2024-07-30 15:54:02.389 Df kernelmanagerd[112:abb5] DextRecordTable read from plist: { com.company.Dext-Loader.dext: MRS-> Optional(( path: /Library/SystemExtensions/B1BF8CDC-CB24-4F25-A8CA-D7A60D814861/com.company.Dext-Loader.dext.dext; state: loaded )) history-> [ ( path: /Library/SystemExtensions/B1BF8CDC-CB24-4F25-A8CA-D7A60D814861/com.company.Dext-Loader.dext.dext; state: loaded ) ] } 2024-07-30 15:54:02.389 Df kernelmanagerd[112:abb5] Launching dext com.company.Dext-Loader.dext com.company.Dext-Loader.dext 0x100001464 a0cf49ca3ea45f5d54a3e8644e2dde6b0e8666c649c1e9513ca4166919038b53 2024-07-30 15:54:02.390 I kernelmanagerd[112:abb5] [com.apple.km:DextLaunch] Skipping addBreadcrumbForDextWithIdentifier for <private> 0 2024-07-30 15:54:02.389 Df kernel[0:ae71] ifnet_attach: Waiting for all kernel threads created for interface XHC2 to get scheduled at least once. 2024-07-30 15:54:02.389 Df kernel[0:ae71] ifnet_attach: All kernel threads created for interface XHC2 have been scheduled at least once. Proceeding. 2024-07-30 15:54:02.390 Df kernelmanagerd[112:abb5] Launching driver extension: Dext com.company.Dext-Loader.dext v34 in executable dext bundle com.company.Dext-Loader.dext at /Library/SystemExtensions/B1BF8CDC-CB24-4F25-A8CA-D7A60D814861/com.company.Dext-Loader.dext.dext 2024-07-30 15:54:02.479 E kernel[0:a9fb] (Sandbox) 1 duplicate report for Sandbox: imagent(633) deny(1) mach-lookup com.apple.contactsd.persistence 2024-07-30 15:54:02.479 E kernel[0:a9fb] (Sandbox) Sandbox: taskgated-helper(2985) deny(1) user-preference-read kCFPreferencesAnyApplication 2024-07-30 15:54:02.483 Df kernel[0:ae73] (AppleMobileFileIntegrity) AMFI: code signature validation failed. 2024-07-30 15:54:02.483 Df kernel[0:ae73] (AppleMobileFileIntegrity) AMFI: bailing out because of restricted entitlements. 2024-07-30 15:54:02.483 Df kernel[0:ae73] (AppleMobileFileIntegrity) AMFI: When validating /Library/SystemExtensions/B1BF8CDC-CB24-4F25-A8CA-D7A60D814861/com.company.Dext-Loader.dext.dext/com.company.Dext-Loader.dext: Code has restricted entitlements, but the validation of its code signature failed. Unsatisfied Entitlements: 2024-07-30 15:54:02.483 Df kernel[0:ae73] mac_vnode_check_signature: /Library/SystemExtensions/B1BF8CDC-CB24-4F25-A8CA-D7A60D814861/com.company.Dext-Loader.dext.dext/com.company.Dext-Loader.dext: code signature validation failed fatally: When validating /Library/SystemExtensions/B1BF8CDC-CB24-4F25-A8CA-D7A60D814861/com.company.Dext-Loader.dext.dext/com.company.Dext-Loader.dext: Code has restricted entitlements, but the validation of its code signature failed. Unsatisfied Entitlements: 2024-07-30 15:54:02.483 Df kernel[0:ae73] validation of code signature failed through MACF policy: 1 2024-07-30 15:54:02.483 Df kernel[0:ae73] check_signature[pid: 2984]: error = 1 2024-07-30 15:54:02.483 Df kernel[0:ae73] proc 2984: load code signature error 4 for file "com.company.Dext-Loader.dext" 2024-07-30 15:54:02.485 Df kernelmanagerd[112:abb5] [com.apple.libxpc.OSLaunchdJob:all] <OSLaunchdJob | handle=46B92B57-A90A-4EBD-8EF4-54313C6EE332>: submitAndStart completed, info=spawn failed, error=162: Codesigning issue 2024-07-30 15:54:02.483 Df kernel[0:ae73] (Sandbox) /Library/SystemExtensions/B1BF8CDC-CB24-4F25-A8CA-D7A60D814861/com.company.Dext-Loader.dext.dext/com.company.Dext-Loader.dext[2984] ==> com.apple.dext 2024-07-30 15:54:02.485 E kernelmanagerd[112:abb5] [com.apple.libxpc.OSLaunchdJob:all] <OSLaunchdJob | handle=46B92B57-A90A-4EBD-8EF4-54313C6EE332>: job failed to spawn, plist={ ProcessType => Driver _ManagedBy => com.apple.kernelmanagerd CFBundleIdentifier => com.company.Dext-Loader.dext _JetsamPropertiesIdentifier => com.company.Dext-Loader.dext LimitLoadToSessionType => System _DextCheckInPort => <mach send right: 0xbd486ccc0> { name = 15679, right = send, urefs = 2 } UserName => _driverkit _NullBootstrapPort => true ReslideSharedCache => false LaunchOnlyOnce => true Label => com.company.Dext-Loader.dext-0x100001464 RunAtLoad => true ProgramArguments => [<capacity = 8> 0: /Library/SystemExtensions/B1BF8CDC-CB24-4F25-A8CA-D7A60D814861/com.company.Dext-Loader.dext.dext/com.company.Dext-Loader.dext 1: com.company.Dext-Loader.dext 2: 0x100001464 3: com.company.Dext-Loader.dext ] SandboxProfile => com.apple.dext } The Xcode project uses these signing options: Automatically manage signing Team: Company Provisioning Profile: Xcode Managed Profile Signing Certificate: Apple Development: () The same project, with the same signing options, builds and loads its dext without issues from Xcode 15.3 on Sonoma 14.5. That same dext binary from Xcode 15.3 loads and passes the signature checks on Sequoia, but using Xcode on Sequoia is when the signature validation fails. Can anyone suggest a way to resolve these signature validation errors? (Other than just developing on Sonoma and testing on Sequoia?)