Subject: Supported macOS containment for a sandboxed worker after controller failure I'm investigating an Apple Silicon/macOS architecture in which an untrusted, signed, sandboxed worker must be independently containable by a separate trusted supervisor. The worker needs only a narrow authenticated communication channel. It requires no direct network access, external operational credentials, privileged file access or authority to launch helpers. I understand that App Sandbox does not inherently prevent child-process creation, and that RLIMIT_NPROC alone does not prevent every form of execution delegation. Could you clarify: Is there a public, supported macOS mechanism to deny all worker-originated subprocess creation and execution delegation at launch, while retaining one restricted communication channel? Alternatively, is there a supported mechanism for a surviving supervisor to identify, terminate and positively verify the complete execution domain of a worker, including any descendants, after its controller crashes or is suspended? What guarantees and limitations apply to stable identity, process exit, automatic relaunch and loss of the supervisor? I'm specifically seeking supported operating-system guarantees, not private sandbox profiles, polling, heartbeat inference or best-effort process-tree enumeration. The goal is to determine whether a bounded synthetic containment experiment is technically justified. No production implementation has been attempted.

Title: Hypervisor.framework — vCPU cessation guarantee after VM-owning process termination Hello, I'm investigating the failure-containment guarantees of Hypervisor.framework on Apple Silicon, specifically for an application that uses QEMU's HVF accelerator. In the QEMU 11.1.2 ARM64 implementation: hv_vm_create() creates the VM within the QEMU process. Each vCPU is created and executed on a QEMU pthread using hv_vcpu_create() and hv_vcpu_run(). No separate userspace VM-execution helper was identified in the reviewed execution path. The security requirement is to establish guest-execution cessation independently when the VM-owning application fails. My primary question: If a supervising parent successfully observes that the QEMU process has actually terminated through waitpid() — whether normally or following SIGKILL — is that a supported guarantee that every Hypervisor.framework vCPU belonging to that process has ceased guest execution and cannot resume? I am specifically asking about irreversible cessation of guest execution, not necessarily completion of all VM resource reclamation. A few related questions: Does an EVFILT_PROC/NOTE_EXIT notification establish the same guarantee, and is there a documented ordering relationship between that notification and cessation of all associated vCPUs? If a thread is executing hv_vcpu_run() when its process receives SIGKILL or SIGSTOP, what cessation or suspension guarantees apply? Is there a documented upper bound for cessation following process termination, or could kernel/framework blockage delay it without a specified bound? Can any other userspace process retain or acquire resources allowing those vCPUs to continue executing after the original owner has terminated? If the original supervising parent also crashes, is there a supported mechanism for a successor controller to obtain equivalent positive evidence of termination and vCPU cessation for the original execution instance? The distinction between a process merely receiving a termination request and the operating system confirming actual process termination is important here. I'm trying to establish which guarantees are supported by the framework rather than relying on experimental observations or assumptions about kernel cleanup. Any clarification would be greatly appreciated. Thanks, Gary

Title: NEFilterDataProvider — fail-closed behaviour after provider crash or suspension I'm investigating the documented failure behaviour of NEFilterDataProvider on macOS. For a content filter handling outbound socket flows: If the data provider process crashes, is terminated, or disconnects unexpectedly, what happens to existing allowed, paused and partially released flows? If the provider is suspended or its callback queue stops making progress, does macOS retain existing verdicts indefinitely, block further data, or apply some other behaviour? Can an existing passBytes allowance remain usable after the provider becomes unavailable? Is there a supported mechanism for independently confirming that all relevant existing flows and outstanding release allowances have been fenced? I'm particularly interested in documented guarantees, rather than implementation behaviour observed in individual tests. Any relevant Apple API documentation or technical clarification would be appreciated.

Virtualization.framework: guest teardown after VM-owner failure We are evaluating an ARM64 Linux guest using Virtualization.framework on macOS 26.6. If the process owning VZVirtualMachine is suspended, hangs on its VM queue, or is forcibly terminated: Does Apple provide a supported guarantee that termination of the owning process also terminates all guest execution resources? Which documentation defines this behaviour? Can a separate surviving process identify and forcibly stop that specific VM through a public API? What supported positive observation can that surviving process obtain to confirm guest execution has ended after the owner is gone? Are any teardown deadlines guaranteed, or must they be measured? We need to distinguish confirmed teardown from owner-process exit, lost telemetry or disconnected IPC. We are seeking documented lifecycle behaviour and supported APIs, without relying on private framework internals.