User Profile

We're seeing reports from customers that there are issues with our NetworkExtension (NEFilterDataProvider) performance. We must see all content so we have an NERule for filtering all traffic for IPv4 and IPv6. It also seems like the issue is compounded, or perhaps exists ONLY when there are two network extensions involved--ours and a 3rd party, any third party NetworkExtension. So far we haven't been able to get a "real world" reproducible case, but we have a contrived case that involves sub-second ICMP pings using ping -i 0.001. I suspect the real world cases involve something using UDP, but no luck so far. We have sample files that indicate that most of the time is spent outside our network extension. In particular: Call graph: 541 Thread_2477: Main Thread DispatchQueue_<multiple> + 541 _dispatch_sig_thread (in libdispatch.dylib) + 49 [0x7ff80c8447f7] + 541 _dispatch_sigsuspend (in libdispatch.dylib) + 36 [0x7ff80c84481b] + 541 __sigsuspend_nocancel (in libsystem_kernel.dylib) + 10 [0x7ff80c9b71d2] 541 Thread_2830419 + 541 start_wqthread (in libsystem_pthread.dylib) + 15 [0x7ff80c9e9f57] + 541 _pthread_wqthread (in libsystem_pthread.dylib) + 426 [0x7ff80c9eb034] + 541 __workq_kernreturn (in libsystem_kernel.dylib) + 10 [0x7ff80c9b305a] 540 Thread_2832749 DispatchQueue_49: NEFilterExtensionProviderContext queue (serial) + 540 start_wqthread (in libsystem_pthread.dylib) + 15 [0x7ff80c9e9f57] + 540 _pthread_wqthread (in libsystem_pthread.dylib) + 326 [0x7ff80c9eafd0] + 540 _dispatch_workloop_worker_thread (in libdispatch.dylib) + 753 [0x7ff80c843eee] + 540 _dispatch_lane_invoke (in libdispatch.dylib) + 366 [0x7ff80c839dfd] + 528 _dispatch_lane_serial_drain (in libdispatch.dylib) + 342 [0x7ff80c8391cd] + ! 528 _dispatch_source_invoke (in libdispatch.dylib) + 2179 [0x7ff80c847208] + ! 528 _dispatch_continuation_pop (in libdispatch.dylib) + 453 [0x7ff80c835d7c] + ! 528 _dispatch_client_callout (in libdispatch.dylib) + 8 [0x7ff80c833317] + ! 520 -[NEFilterDataExtensionProviderContext handleSocketSourceEventWithSocket:] (in NetworkExtension) + 2950 [0x7ff81b2a9b16] + ! : 520 -[NEFilterDataExtensionProviderContext handleData:offset:forFlow:direction:reply:controlSocket:completionHandler:] (in NetworkExtension) + 433 [0x7ff81b2a6576] + ! : 520 -[NEFilterDataSavedMessageHandler enqueueWithFlow:context:] (in NetworkExtension) + 188 [0x7ff81b2ab67e] + ! : 515 -[NEFilterDataSavedMessageHandler executeWithFlow:context:] (in NetworkExtension) + 297 [0x7ff81b2ab7c9] + ! : | 515 -[NEFilterDataSavedMessageHandler executeVerdictHandlerWithFlow:verdict:context:] (in NetworkExtension) + 305 [0x7ff81b2ab9a6] + ! : | 515 __114-[NEFilterDataExtensionProviderContext handleData:offset:forFlow:direction:reply:controlSocket:completionHandler:]_block_invoke.317 (in NetworkExtension) + 133 [0x7ff81b2a671a] + ! : | 515 -[NEFilterSocketFlow createDataReply:controlSocket:direction:verdict:context:] (in NetworkExtension) + 86 [0x7ff81b2b1393] + ! : | 515 -[NEFilterSocketFlow writeCurrentVerdictWithMessage:controlSocket:] (in NetworkExtension) + 371 [0x7ff81b2b15ec] + ! : | 515 +[NEFilterSocketFlow writeMessageWithControlSocket:drop:socketID:inboundPassOffset:inboundPeekOffset:outboundPassOffset:outboundPeekOffset:statsReportFrequency:] (in NetworkExtension) + 158 [0x7ff81b2b1a4e] + ! : | 515 write (in libsystem_kernel.dylib) + 10 [0x7ff80c9b475e] + ! : 5 -[NEFilterDataSavedMessageHandler executeWithFlow:context:] (in NetworkExtension) + 81 [0x7ff81b2ab6f1] + ! : 5 __114-[NEFilterDataExtensionProviderContext handleData:offset:forFlow:direction:reply:controlSocket:completionHandler:]_block_invoke (in NetworkExtension) + 117 [0x7ff81b2a666a] + ! : 5 @objc FilterDataProvider.handleOutboundData(from:readBytesStartOffset:readBytes:) (in com.my.system-extension) + 91 [0x10900a02b] In this case, we're not doing much for ICMP in our handleInboundData/handleOutboundData except looking at data stream metadata, seeing it's ICMP and getting the type/code. Those frames don't even appear in the samples. Anybody else seen an issue like this?

We have a daemon that is launched by launchd, always running in the background and running as root. The daemon is installed to /Library/LaunchDaemons.To reduce its attack surface we want to move some functionality into another helper process. It doesn't have to be running as root, but since the client (the LaunchDaemon) is running as root and in the launchd context, we created another LaunchDaemon that is launched on-demand and uses the MachService key to advertise its Mach service. It is also installed to /Library/LaunchDaemons.The sandboxed daemon has little functionality in it, and its entitlements are just com.apple.security.app-sandbox. We use NSXPC to communicate between the the non-sandboxed daemon and the sandboxed daemon. The sandboxed helper daemon launches as expected.However the sandboxed application exits immediately on 10.14 with the following crash:Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Illegal instruction: 4 Termination Reason: Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [1721] External Modification Warnings: Debugger attached to process. Application Specific Information: dyld: launch, running initializers /usr/lib/libSystem.B.dylib Sandbox registration internal error: Incoming message euid:1 does not match secinitd uid:0. Application Specific Signatures: Internal error: Incoming message euid:1 does not match secinitd uid:0. Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_secinit.dylib 0x00007fff5b6e6b2a _libsecinit_setup_secinitd_client + 1929 1 libsystem_secinit.dylib 0x00007fff5b6e6340 _libsecinit_initialize_once + 13 2 libdispatch.dylib 0x00007fff5b49e63d _dispatch_client_callout + 8 3 libdispatch.dylib 0x00007fff5b49fd4c _dispatch_once_callout + 20 4 libsystem_secinit.dylib 0x00007fff5b6e6331 _libsecinit_initializer + 79 5 libSystem.B.dylib 0x00007fff582b09d4 libSystem_initializer + 136 6 dyld 0x0000000108408592 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&amp;) + 506If we remove the entielements from the sandboxed helper, thus making it non-sandboxed, it works fine but this is obviously not the intent.Any ideas?

If we create a SystemExtension using the Endpoint Security APIs, how can we communicate with another process? It looks like for a NetworkExtension, the NE framework will setup a Mach service on your behalf using the NEMachServiceName Info.plist key. I don't see anything equivalent for a plain vanilla system extension.Since the system manages the lifetime of the SystemExtension, and its location on-disk is embedded inside an application, you can't register for a launchd-managed Mach service yourself.