Post not yet marked as solved
Mine is working fine on an M1 Mini. I did have to turn Full Disk Access back on after the last install after updating, but other than that, it's working as expected.
I know that doesn't help you a lot, but it doesn't seem to be a regression.
Post not yet marked as solved
The first thing I'd check is to see if the local drive is mounted with noatime set, and the pen drive doesn't have it set. It might have nothing to do with your system extension.
You will need to use an MDM system that has a profile automatically allowing the system extension.
Couldn't you just run systemextensionsctl list | grep <your extension name> in an NSTask and parse the output, if any?
Post not yet marked as solved
This link says that it's OK now, yesterday there was a problem
https://developer.apple.com/system-status/
Post not yet marked as solved
Monterey beta 6 is behaving like Big Sur and is working. All is good in (my) the world.
Thank you again, Quinn, for letting us know to test it again.
Post not yet marked as solved
This is the same approach I used to use for debugging KEXTs, and for the same reason: Interactive debugging of low-level system components is, at best, deeply unpleasant and, in the worst case, completely infeasible.
Deeply unpleasant. Quinn, you are a master of understatement :)
Post not yet marked as solved
I believe you are running into this problem, you need to define
keyNSEndpointSecurityMachServiceName/key
string$(PRODUCT_BUNDLE_IDENTIFIER)/string
in your info.plist. It's been a while since I fought this, but I think that right now it's publishing your XPC endpoint as TeamID.bundle ID.text.xpc
I'm sure that Quinn or others will correct me if I'm wrong.
Post not yet marked as solved
kappe_m,
I had the same question back in the summer and got this work-around from an Apple rep:
There is a workaround before the fix is implemented: To implement device access control for mass-storage devices based on e.g. USB serial numbers, ES clients can, before responding to mount events, query the IOKit registry for the service object corresponding to the disk device that is about to be mounted (IOBSDNameMatching). From there they can walk the registry tree to find the responsible USB device and query its properties (IORegistryEntryGetParentEntry, IORegistryEntryCreateCFProperties, IORegistryEntryGetChildIterator etc). Based on that information, they can make a policy decision and allow or deny the ES mount event. This is for USB mass storage events, not any USB device connection. Using the suggestions offered, I was able to get some proof-of-concept code working.
Hope this helps.
The formatting got all messed up, best to just look at the header file in Xcode 12.2 beta 2 where I got this
From the header file
/**Retains an esmessaget, returning a non-const pointer to the given esmessaget for compatibility with * existing code.* @warning It is invalid to attempt to write to the returned esmessaget, despite being non-const, and * doing so will result in a crash.* @deprecated Use esretainmessage to retain a message. *@param msg The message to be retained * @return non-const pointer to the retained esmessaget.* @brief The caller must release the memory with es_free_message/OSEXPORT
APIDEPRECATED("Use esretainmessage to retain a message.", macos(10.15, 11.0))
APIUNAVAILABLE(ios, tvos, watchos)
esmessaget * Nullable
escopymessage(const esmessaget * _Nonnull msg);
Post not yet marked as solved
It's the way that the process are launched that is confusing. Here is the explanation from Apple
PIDs are assigned at fork time, not exec time. When the ES kext knows there are early boot clients, it holds up the kernel thread performing the execve. So all binaries that would get exec'd (e.g. via Loginwindow, launchd loads, etc.), will all get a new pid - they just won't have code execute if they're non-platform binaries until the ES client connects and makes its first set of subscriptions (and, if they subscribed to AUTH EXEC, the client has the opportunity to DENY the exec from continuing). None of this has anything to do with lower numbered PIDs. I did prove that this was the case by looking at log lines from my extension and my launchd process. The extension logged first, even though its PID was larger.
Sorry for the late reply, been super busy.
Yes, I was seeing the same thing, launchd agent failing to connect at startup, until I did the early boot. Then I saw PIDs that didn't make sense, but looking at timestamps of messages I added, I saw that the system extension loaded and ran before the launchd process.
This was the comment I got back from Apple when I asked back in April:
PIDs are assigned at fork time, not exec time. When the ES kext knows there are early boot clients, it holds up the kernel thread performing the execve. So all binaries that would get exec'd (e.g. via Loginwindow, launchd loads, etc.), will all get a new pid - they just won't have code execute if they're non-platform binaries until the ES client connects and makes its first set of subscriptions (and, if they subscribed to AUTH EXEC, the client has the opportunity to DENY the exec from continuing). None of this has anything to do with lower numbered PIDs.
I had the same question a while ago. Even though a launchd app has a smaller PID than your system extension, the launchd app is blocked from running until the early boot extensions load. I confirmed this with log messages at startup in each and saw the timestamps.
Post not yet marked as solved
This is from the release notes (not sure which release) and I don't know if it's still true:
Moving a kernel extension bundle out of /Library/Extensions might not completely uninstall it. (64331929
Workaround:
Remove the extension from /Library/Extensions.
Boot to macOS Recovery.
Run Terminal.
Enter the command kmutil invoke-panic-medic.
Restart your Mac.
Follow the prompt to open System Preferences and navigate to Security & Privacy.
Follow the prompt to restart.
