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.

When you print the description of a NEFilterSocketFlow instance, you see the socketID value (which is displayed without a 0x but as a hex value…). When you look at the NEFilterSocketFlow header file, there are no such properties. When you google this, you end up with some sites displaying the class-dump of the NEFilterSocketFlow class and this property does exist (at least at the time of the class-dump and at the time of this writing). 2 related questions: Why is this property private? Is this property not more reliable than the identifier property when you need to identify a socket inside a flow?

In the good old times of Kernel Extensions, it was possible to set a cookie when using a socket filter and it was possible to attach a tag to a mbuf. I've noticed the identifier property for a flow but it does not look like it can provide exactly the same kind of services. In addition to this, I've not found till now some clear explanations about the lifecycle of a flow (e.g. does a data filter provider receive the handleInboundDataCompleteForFlow: message if a flow is denied by another provider, do you get a new flow if some packet is reinjected, etc.). Considering that cookies and tags could be used to avoid filtering packets that have already been processed, it's a bit mysterious so far how you can do the same thing with a Network Extension. Questions What is the equivalent of the cookie parameter of kpi socket filter callbacks? What is the equivalent of the mbuf tag? Side note: Why does typing "NetworkExtension" in the Search Forums search field return no posts with the NetworkExtension tag (at least in the first result pages)?

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.

The IN6ISADDRMCINTFACELOCAL macro is defined in Kernel.framework/.../netinet6/in6.h The IN6ISADDRMCINTFACELOCAL macro is not defined in /usr/include/netinet6/in6.h Xcode 11.4.1 Question: Which headers should be used for Network Extensions? The ones in Kernel.framework or the userland headers?

I'm a bit confused by the documentation and parameter names for some NetworkExtension and System Extension APIs: Case 1: (instancetype)activationRequestForExtension:(NSString *)identifier queue:(dispatch_queue_t)queue; identifier is said to be "The bundle identifier of the target extension." Problem: This is pretty confusing since the API will report that it can not find the system extension in the apps bundle if you provide the bundle identifier. Because the reality is that it's not the bundle identifier that you must provide but the name of the .systemextension bundle (without the extension). It just happens that the name of the system extension is required to be the bundle identifier (which is a mystery in itself). So if you have a system extension with a name that differs from its bundle identifier, you will use this API and be told that it can not find the system extension whereas you are scrupulously respecting the documentation. And it may take you some time to figure out the origin of the issue. Case 2: typedef NEFilterPacketProviderVerdict (^NEFilterPacketHandler)(NEFilterPacketContext *context, _Nonnull nw_interface_t interface, NETrafficDirection direction, const void *packetBytes, const size_t packetLength) This is a block that is used to "make a filtering decision about a network packet." and packetBytes is supposed to be "The packet bytes." Problem: I haven't found any information in the header (or documentation) about the nature of these "packets". It required to finally have a working Packet Filter prototype and try to match the raw data with a etherheader struct or ip struct to find out that these packets are actually Ethernet frames. And that a NEFilterPacketProvider content filter is actually the replacement for the interfacefiltert API. Suggestions:_ Unless it already exists somewhere, wouldn't' it be nice to have a documentation that lists the equivalence between Network Extensions and Network Kernel Extensions? As far as I understand: socket filter -> filter data provider ip filter -> MIA interface filter > filter packet provider Wouldn't it be nice to clearly indicate in the header and API documentation that the packets are Ethernet frames and not IP packets? This would avoid some possible confusions.