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?"
PCIDriverKit
RSS for tagDevelop device drivers for Peripheral Component Interconnect accessories.
Posts under PCIDriverKit tag
12 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
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?)
Hi,
I have a PCI DriverKit System Extension project that our team has tested, and the entitlements are not a problem.
Once we decided to place the project to the Apple Store the review team requested to add "App Sandbox" entitlement to the project. Then I added the entitlement manually to the ".entitlements" file ( I couldn't do that using the Xcode add entitlement section because since it is a driverkit project, the "App sandbox" is not visible in the entitlements page ) and re-packaged the project for distribution. Later on, I saw that the entitlement was removed during the packaging process.
I also tried to add that using the "build settings" page in Xcode (the signing section ), but I had no luck.
I feel like I'm being misled by the review team. Do you know if the "App sandbox" entitlement is applicable to a DriverKit project ?
The situation:
1A) On last week our development team applied on-line for three idVendors with the format as the following:
USB-VendorID: 547h(1351), 3488h(13448),4B4h(1204)
Describe your apps: it shall be functional equivalence of existing Android-SDK for X-ray sensor-models:...with 15..25 text lines of the description below
1B) We received auto-reply, that we granted all the the entitlements. We've expected to have entitlements like approx like the these:
<key>com.apple.developer.driverkit.transport.usb</key> <array>
<dict> <key>idVendor</key> <integer>1351</integer> </dict>
<dict> <key>idVendor</key> <integer>131448</integer> </dict>
<dict> <key>idVendor</key> <integer>1204</integer> </dict> </array>
1C) Unexpectingly (for us) ASCII-strings-fragment from our iOS-target-binary "com.rayence.dexta.driver" (built with automatic signing; seemingly this shall be our actual granted prvisionintg profile) looks as the next:
<plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/><key>com.apple.developer.driverkit.transport.usb</key>
<array><dict> <key>idVendor</key> <string>*</string> </dict></array> </dict>
1D) Repectively, now we shall specify (in our dext's entitlements in XCOde-project)
<key>com.apple.developer.driverkit.transport.usb</key> <array>
<dict> <key>idVendor</key> <string>*</string> </dict> </array>
In DExt's info.plist we have "normal":
<key>IOKitPersonalities</key> <dict>
<key>IOKitPersonality_EzHD</key> <dict> blah-blah
<key>idVendor</key><integer>1351</integer>
<key>IOKitPersonality_EzR</key> <dict> blah-blah
<key>idVendor</key><integer>131448</integer>
<key>IOKitPersonality_EzR</key> <dict> blah-blah
<key>idVendor</key><integer>1204</integer>
blah-blah
Our ambiguities:
2a) Without exact "1D)", our DExt-installer-application never starts in iPAD. OS-loader generates obectievly-meaningless error-messages and seemingly-meaninglessly suggest to look "system-logs" (which seemingly don't contain relevant information)
2b) With exatct "1D)",
2ba) the reaction (presence/absence and timing of relevant console.app's messages) of our iPAD 17.4 on plugging/unplugging our gadgets look "non-logical". It isn't completly wrong but suspicious. E.g. our Swift-module randomly receive/dontreceive relevant events and can't connect communicate driver's instance for newly-attached physical gadgets. We realize, thses it could be our bugs; but we need disambiguation to debug the issues (or at least to be sure that the quirks are like in production system).
2bd) we would prefer debug/develop rather with real "idVendor=number nnn"s in provisioning profile (than with "idVendor=string *"). So we could be sure that quircs "2ba" are like in a production system.
Respective question:
Which format in on-line application ~1A) shall we use to obtain provisioning profile 1B)
My company has been developing a DriverKit Extension for our ThunderBolt attached devices. Our testing has gone well on Intel based machines but it seems to be able to cause kernel panics on my M1/M2 Mac when click "Allow"
in Privacy & Security. It always crash immediately. Unfortunately it is " ApplePPMCPMS: Could not register client id 5. Error code 0xe00002bc " and I have no way to debug it. Has anyone deal with something like this?
panic(cpu 5 caller 0xfffffe002fd92b7c): "ApplePPM: virtual IOReturn ApplePPMCPMS::callPlatformFunction(const OSSymbol *, bool, void *, void *, void *, void *):2003 " "ApplePPMCPMS: Could not register client id 5. Error code 0xe00002bc\n" @ApplePPMCPMS.cpp:2003
Debugger message: panic
Memory ID: 0x6
OS release type: User
OS version: 22G90
Kernel version: Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:52 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8103
Fileset Kernelcache UUID: 593DE91B6B9F1B49F8178C99AC56A8C2
Kernel UUID: CE831117-201E-35F6-A293-FCC0F02097A3
Boot session UUID: EB9DE635-C521-4672-9251-955CEC7BC487
iBoot version: iBoot-8422.141.2
secure boot?: YES
roots installed: 0
Paniclog version: 14
KernelCache slide: 0x00000000264e4000
KernelCache base: 0xfffffe002d4e8000
Kernel slide: 0x00000000264ec000
Kernel text base: 0xfffffe002d4f0000
Kernel text exec slide: 0x00000000278a4000
Kernel text exec base: 0xfffffe002e8a8000
mach_absolute_time: 0x3b74899144
Epoch Time: sec usec
Boot : 0x66176032 0x000c0192
Sleep : 0x00000000 0x00000000
Wake : 0x00000000 0x00000000
Calendar: 0x661789be 0x0006abb4
Zone info:
Zone map: 0xfffffe10002b4000 - 0xfffffe30002b4000
. VM : 0xfffffe10002b4000 - 0xfffffe14ccf80000
. RO : 0xfffffe14ccf80000 - 0xfffffe1666918000
. GEN0 : 0xfffffe1666918000 - 0xfffffe1b335e4000
. GEN1 : 0xfffffe1b335e4000 - 0xfffffe20002b0000
. GEN2 : 0xfffffe20002b0000 - 0xfffffe24ccf7c000
. GEN3 : 0xfffffe24ccf7c000 - 0xfffffe2999c48000
. DATA : 0xfffffe2999c48000 - 0xfffffe30002b4000
Metadata: 0xfffffe3efce64000 - 0xfffffe3f04e64000
Bitmaps : 0xfffffe3f04e64000 - 0xfffffe3f06478000
Extra : 0 - 0
CORE 0 recently retired instr at 0xfffffe002ea385fc
CORE 1 recently retired instr at 0xfffffe002ea385fc
CORE 2 recently retired instr at 0xfffffe002ea385fc
CORE 3 recently retired instr at 0xfffffe002ea385fc
CORE 4 recently retired instr at 0xfffffe002ea385fc
CORE 5 recently retired instr at 0xfffffe002ea36edc
CORE 6 recently retired instr at 0xfffffe002ea385fc
CORE 7 recently retired instr at 0xfffffe002ea385fc
TPIDRx_ELy = {1: 0xfffffe166798e020 0: 0x0000000000000005 0ro: 0x0000000000000000 }
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=0xfffffe002e919618, LR=0xfffffe002e90f630, FP=0xfffffe5d6457bc00
CORE 1: PC=0xfffffe002e936000, LR=0xfffffe002e936000, FP=0xfffffe5d6429bef0
CORE 2: PC=0xfffffe002eaacaa8, LR=0xfffffe002eaacae8, FP=0xfffffe5d63fe3690
CORE 3: PC=0xfffffe002e936000, LR=0xfffffe002e936000, FP=0xfffffe5d64693ef0
CORE 4: PC=0xfffffe002e92fbac, LR=0xfffffe002e914b70, FP=0xfffffe5d65befc60
CORE 5 is the one that panicked. Check the full backtrace for details.
CORE 6: PC=0x0000000199b5b5b4, LR=0x000000018c06db24, FP=0x000000016f324ff0
CORE 7: PC=0xfffffe002ef4937c, LR=0xfffffe002ef492f0, FP=0xfffffe5d657e7de0
Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space
Panicked task 0xfffffe24cd09a738: 0 pages, 970 threads: pid 0: kernel_task
Panicked thread: 0xfffffe166798e020, backtrace: 0xfffffe5d643735d0, tid: 62085
lr: 0xfffffe002e8fe5fc fp: 0xfffffe5d64373650
lr: 0xfffffe002ea3e6e4 fp: 0xfffffe5d64373670
lr: 0xfffffe002ea2fe4c fp: 0xfffffe5d643736e0
lr: 0xfffffe002ea2e518 fp: 0xfffffe5d643737a0
lr: 0xfffffe002e8af7f8 fp: 0xfffffe5d643737b0
lr: 0xfffffe002e8fdee4 fp: 0xfffffe5d64373b60
lr: 0xfffffe002f07a548 fp: 0xfffffe5d64373b80
lr: 0xfffffe002fd92b7c fp: 0xfffffe5d64373d30
lr: 0xfffffe002f13c88c fp: 0xfffffe5d64373d80
lr: 0xfffffe002ef44b08 fp: 0xfffffe5d64373de0
lr: 0xfffffe002ef4c3ac fp: 0xfffffe5d64373e50
lr: 0xfffffe002ef51cc8 fp: 0xfffffe5d64373f20
lr: 0xfffffe002e8b8e98 fp: 0x0000000000000000
Kernel Extensions in backtrace:
com.apple.AGXG13G(227.7.14)[9A593B36-8560-3700-B806-A6531D4F72EC]@0xfffffe002f0be6a0->0xfffffe002f15dbbf
dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5478478E-CF49-3A40-9437-4298C08DC081]@0xfffffe002f2123d0->0xfffffe002f263173
dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[28D5832D-79F4-3C81-AA70-0775A365BA35]@0xfffffe002fca3580->0xfffffe002fccf587
dependency: com.apple.driver.RTBuddy(1.0.0)[8695C672-1FB4-3954-A525-C10AE1CE4E57]@0xfffffe0031348720->0xfffffe003138444b
dependency: com.apple.iokit.CoreAnalyticsFamily(1)[38EC9902-05F4-3412-8CB3-1B5001455BCA]@0xfffffe00303385f0->0xfffffe0030340407
dependency: com.apple.iokit.IOGPUFamily(65.60.1)[683A153B-7683-363B-B6E8-6DC60D57D55F]@0xfffffe0030a85180->0xfffffe0030abab17
dependency: com.apple.iokit.IOReportFamily(47)[FE904E47-8D35-3152-8035-2BFA7B69A77E]@0xfffffe0030d44820->0xfffffe0030d478bf
dependency: com.apple.iokit.IOSurface(336.60.1)[64104E9B-CF29-3BAC-ABF7-134DCEE9A195]@0xfffffe0030e15d20->0xfffffe0030e450e3
dependency: com.apple.kec.Libm(1)[BA66FD46-3E12-378D-A1A3-67C765DB2A21]@0xfffffe00313313c0->0xfffffe0031334e4b
com.apple.driver.ApplePassthroughPPM(3.0)[495FD94A-224A-3C8B-B377-925FF62F0257]@0xfffffe002fd7ac40->0xfffffe002fdbb7c3
dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5478478E-CF49-3A40-9437-4298C08DC081]@0xfffffe002f2123d0->0xfffffe002f263173
dependency: com.apple.driver.ApplePMGR(1)[8202FFB5-EBDB-333D-9001-9A2582407585]@0xfffffe002fd26380->0xfffffe002fd6c30f
dependency: com.apple.iokit.IOReportFamily(47)[FE904E47-8D35-3152-8035-2BFA7B69A77E]@0xfffffe0030d44820->0xfffffe0030d478bf
dependency: com.apple.kec.Libm(1)[BA66FD46-3E12-378D-A1A3-67C765DB2A21]@0xfffffe00313313c0->0xfffffe0031334e4b
last started kext at 254801217669: com.apple.filesystems.exfat 1.4 (addr 0xfffffe002de1c690, size 6208)
last stopped kext at 252590757699: com.apple.filesystems.exfat 1.4 (addr 0xfffffe002de1c690, size 6208)
Hardware and software configuration
MacBook Air M2 2022 16GB,
MacOS Ventura 13.2.1
Full description
This is a DriverKit that controls PCIE FPGA devices for low-latency data exchange.
This driver has been implemented on Iokit, and now it needs to be launched on Driverkit to adapt to newer Macs.
Driverkit lacks the IOMemoryDescriptor::withAddressRange(Iokit) function to convert the app's memory of any size to a Descriptor.
Currently, we use args->structureOutputDescriptor->CreateMapping to map the Descriptor passed by the application to the kernel layer.
// App
size_t ***::xxRead(long long addr, size_t size, void * buff){
std::lock_guard<std::mutex> guard(usrLock);
kern_return_t kr;
uint64_t info[2] = {(uint64_t)addr, (uint64_t)size};
kr = IOConnectCallMethod(
connect,
kUserReadIO,
info,
2,
NULL, NULL, NULL, NULL,
buff,
&size);
return size;
}
// Driverkit
const IOUserClientMethodDispatch sMethods[kNumMethods] = {
[kUserReadIO] =
{
(IOUserClientMethodFunction) &SmiPcieUc::sUserReadIo,
.checkCompletionExists = false,
.checkScalarInputCount = 2, // Read Addr, size
.checkStructureInputSize = 0,
.checkScalarOutputCount = 0,
.checkStructureOutputSize = kIOUserClientVariableStructureSize} // Read Data
};
kern_return_t SmiPcieUc::sUserReadIo (OSObject * target, void* reference, IOUserClientMethodArguments* args){
IOMemoryMap * memMap = nullptr;
uint32_t * buffKptr = nullptr;
kern_return_t rt = 0;
if(target == nullptr){
Log("***Err***: sUserReadIo Target is Null!");
return kIOReturnError;
}
if(args->structureOutputDescriptor){
rt = args->structureOutputDescriptor->CreateMapping(0,0,0,0,0, &memMap);
if(rt == kIOReturnSuccess){
buffKptr = reinterpret_cast<uint32_t *>(memMap->GetAddress());
}
else {
Log("***Err***: sUserReadIo Mapping Failed!");
return kIOReturnNoMemory;
}
} else {
buffKptr = (uint32_t *) args->structureOutput;
}
rt = ((SmiPcieUc *)target)->UserReadIo((uint64_t *)&args->scalarInput[0], (size_t *)&args->scalarInput[1], buffKptr);
OSSafeReleaseNULL(memMap);
return rt;
}
phenomenon
When StructureOutputSize is greater than 4096, args>structureOutputDescriptor exists, and when it is less than or equal to 4096, args->structureOutputDescriptor and args->structureOutput are both equal to nullptr, (in IOkit, args->structureOutput is not empty)。
How to properly convert any size of application memory into the kernel space of Driverkit?
We have been doing a R&D work related to the NVMe controller on Mac platform, where we need to get control of the admin queues(submission as well as completion). From the spec of NVMe it’s very clear that what are all registers do we need to deal with to get access of the queues. We are accordingly following those registers to create our own queues. Also we have prepared and enqueued a sample admin command to the newly created submission queue. But surprisingly we can’t get any assurance whether the command got processed by the controller or not, because from the completion queue entry we can see all the entries are zero, which is not expected anyway. So here the question is, how to communicate with the controller properly ? We are also aware of the fact of existing NVMe driver(IONVMeFamily) on Mac platform, is this somehow crossing our way ? We have done all the proper setup for registers, DMAs and interrupt. Path is very ok if we use builtin driver with the XNVME user space application (we can trigger limited admin commands over there). But here we need to have our own created queues up and running with seamless admin command transaction. Here we must tell about our setup, we have one SSD which is connected via a thunderbolt cable to Mac laptop using type C usb port. We have tried to access pre-configured admin queues from IONVMeFamily driver but that is also a blocker for us, as we can’t see any valid data from submission/completion queues.
Request you to all please help us coming out of this trapped zone.
Hi,I am trying to write Dext code for my existing Kext,How to convert this code to be compatible with Dext?
BufferMemoryDescriptorAME_Module = NULL;
IOMemoryMap *MemMap;
BufferMemoryDescriptorAME_Module= IOBufferMemoryDescriptor::inTaskWithPhysicalMask(kernel_task,kIOMemoryPhysicallyContiguous,otal_memory_size);
BufferMemoryDescriptorAME_Module->prepare(kIODirectionInOut);
MemMap = BufferMemoryDescriptorAME_Module->map(kIOMapInhibitCache);
logicalAddressAME_Module = (UInt8 *) MemMap->getVirtualAddress();
physicalAddressAME_Module = MemMap->getPhysicalAddress();
Thanks,
Frederic
I'm looking for a fast and efficient way for user-space to send I/O to my driver. One way I'd have hoped to do this, was through a shared memory ring-buffer.
In the WWDC19 presentation on System Extensions and DriverKit, at roughly 17:00, they mention an IOSharedDataQueueDispatchSource. This doesn't exist in the DriverKit API. An IODataQueueDispatchSource is available, but doesn't seem to be meant to be shared.
In the old IOKit framework, there are similar IOSharedDataQueue and IODataQueue, but they are unavailable in DriverKit.
So, what are my options for implementing a fast, efficient I/O path to my driver?
I'm currently working on developing a PCI driver using PCIDriverKit, but I'm encountering challenges, particularly with the driver's extension. I need some insights on the APIs and methods to follow the best practices in generating PCI drivers for retrieving PCI devices information and running NVMe commands on the devices.