When you try to load a kernel extension in macOS Big Sur b7, kextload gives you the silent treatment: it does not load the kernel extension. it does not print any error. Using kmutil directly does not solve the issue. Using the --verbose option of kmutil does not print anything. kextstat shows only Apple kernel extensions.

I've observed at least 3 kernel panics in Apple code on Catalina and Big Sur related to Network Extensions. I'm a bit surprised and disappointed. Network Extensions were allegedly created because we, mere 3rd party developers, are not worthy to work in Kernel land. And by using Network Extensions, we will avoid causing kernel panics. Well, it looks like that using Network Extensions does not prevent Kernel Panics. So 2 questions: is it recommended not to use Network Extensions until the switch to Apple Processor based Macs? Why all the scary alerts about Kernel Extensions when Network Extensions can KP a Mac?

I'm observing something unexpected in macOS Big Sur: If I have an indeterminate progress (bar) indicator, the animation is the Cylon one. If I have a determinate progress (bar) indicator and I set it to be indeterminate (through the appropriate property), the animation is a pulse/throb. Even if I set the min,double,max value to 0. Is it no more possible to alternate between determinate and indeterminate in macOS Big Sur?

The checkbox to enable/disable autolayout in a xib file is MIA in Xcode 12 File inspector. Question: Where is the option to disable/get rid of auto-layout in a xib file? I would like to disable it for 2 main reasons: I don't do autolayouts. When autolayout is enabled, the contextual HID window to connect outlets/actions is replaced by a autolayout window that is not useful when you do not do autolayouts.

Let's say I have a system extension distributed in a bundle application: wrapper.app. Version 1.0 of wrapper.app is installed on the Mac with version 1.0 of the system extension. Now, some changes are made in the code of the system extension and we now have version 1.1 of wrapper.app with version 1.1 of the system extension that is available. Version 1.1 of the wrapper.app bundle is installed either manually or using an Installer package. The user does not and will not open wrapper.app 1.1 once the installation (i.e. update) is completed. As far as I understand, this means that version 1.0 of the system extension will still be running and will also be running at the next startup. Maybe it could be possible to fake the opening of the wrapper.app from a postinstallation script in the case of an Installer package solution. But what if this is a background installation without any user logged in (no Aqua Session)? It probably will not work as expected. Question: Is there an officially recommended strategy when it comes to updating Network Extensions (as system extension)?

In the release notes for Big Sur b4, we can find the same note as for b4: "Updating to macOS Big Sur 11 beta from previous versions of macOS might take significantly longer than expected." What does "significantly longer" mean? 10 minutes ? 30 minutes ? 2 hours? From what I'm observing, updating from b3 to b4 is a bad as updating from b2 to b3. The "Preparing macOS Big Sur beta X…" step is taking an eternity to complete while the fans are spinning crazily. No processes are reported to use a lot of CPU time in Activity Monitor. Question: Do we need to erase the disk and install a fresh copy of Big Sur betas for each new beta?

Is there a known solution other than filing a bug report when the Network Extensions pops up with an unidentified application name|identifier|metadata? Would I be an end user, I would not click the Allow button in this dialog.

I have a NEFilterDataProvider subclass with the handleNewFlow: method overridden. The custom method just does this: Check if we're dealing with AFINET or AFINET6. gather some data using the audit token and proc_pidpath send a XPC to another process with a completionHandler. pause the flow by returning [NEFilterNewFlowVerdict pauseVerdict] When the completionHandler is called, it calls: [self resumeFlow:theFlow withVerdict:[NEFilterNewFlowVerdict allowVerdict]]; So far what I'm observing is that this does not work as expected: the network connections work for a while. then web pages are no more displayed in Safari. based on some logs, it looks like that the DNS requests do not complete. The XPC listener does reply almost immediately and I can see that the resumeFlow: call is correctly called. Yet, it looks like the flow is not resumed. Questions: Is the pauseVerdict + resumeFlow:withVerdict: mechanism reliable? What could be checked since step-by-step-debugging shows that the expected steps are performed to resume the flows?

In the good old times of Kernel Extensions, when using a socket filter, it was possible to be informed that a socket entered the listen state. Now, with the NEFilterDataProvider API there does not seem to be an obvious or intuitive way to be notified about this "event". Questions: Is a new flow supposed to be created for a listen "event"? If this is the case, are we supposed to check that the flow is an incoming one with a nil remote endpoint? It's not really possible to verify this theory as the documentation says about the remote endpoint property of a NEFilterSocketFlow: This endpoint object may be nil when [NEFilterDataProvider handleNewFlow:] is invoked; without mentioning in which cases the endpoint object would be nil.

It is/was possible to set up a Kernel Extension to be loaded even during safe boot. Is it possible to achieve the same thing with a Network Extension?

I want/need/would like the Network Extension to send a XPC message to a XPC listener of a launchd daemon. So far, what I'm observing is: the NE is apparently able to obtain a remote proxy object for the XPC service name defined by the launchd daemon. when the proxy invokes one of the methods of the remote interface, it does nothing: the completion handler of the method is not called in the Network Extension. the proxy error handler is not called either. In Console, I'm seeing: com.xxxxxxxxx.extension    Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service on pid 0 named com.xxxxxxx.logListener was invalidated." UserInfo={NSDebugDescription=The connection to service on pid 0 named com.xxxxxxx.logListener was invalidated.} This is a bit mysterious considering that the pid for the listener is not 0 (i.e. the kernel_task). Questions: Is it possible to send XPC messages from a Network Extension to a launchd daemon? Maybe this requires to use some specific service names too or specific bundle identifier for the launchd daemon. Which ones? I would rather not have to send a XPC message from the launchd daemon to the NE as this would mean that the launchd daemon would need to be launched at startup. Also this would not make a lot of sense from an architectural point of view since it's the launchd daemon that is supposed to be a service for the network extensions and no the opposite.

I'm trying to figure out whether it's possible to authenticate a user as an admin using Touch ID on macOS. And Using _public_ APIs (*)Basically, what I'm trying to achieve is:1. User clicks on a button to perform a task that can only performed by a user who is allowed to administer the computer.2. A standard security authentication dialog appears and allows to authenticate using Touch ID.3. A AuthenticationRef is retrieved.When I look at the Local Authentication API, I see multiple limitations (by design or not):- it lets you prove you are the current user. But it does not check that you are an admin user.- the dialog does not work as the one in Installer.app for instance: . if you move the authentication dialog to a screen corner and then click the User Password… button, the Password window is displayed on the center of the screen.- it does not seem possible to retrieve a AuthorizationRef.QuestionAre there public API or services that allows to check for admin privileges which support Touch ID?* I know it's possible using private frameworks since this for instance what the Startup Disk preference pane does.