Explore the core architecture of the operating system, including the kernel, memory management, and process scheduling.

Posts under Core OS subtopic

Post

Replies

Boosts

Views

Activity

Core OS Resources
General: DevForums subtopic: App & System Services > Core OS Core OS is a catch-all subtopic for low-level APIs that don’t fall into one of these more specific areas: Processes & Concurrency Resources Files and Storage Resources Networking Resources Network Extension Resources Security Resources Virtualization Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"
0
0
2.1k
Aug ’25
Missing entitlement for API HomeKit error
During a test run of my HomeKit application in Xcode, after some time the app did run smoothly, I've started for one characteristic to get a pretty weird error in the readValueWithCompletionHandler: callback block: Error Domain=HMErrorDomain Code=80 "Missing entitlement for API." UserInfo={NSLocalizedFailureReason=Handler does not support background access, NSLocalizedDescription=Missing entitlement for API.} The application was launched just a couple of hours ago and the profile is still OK (though it will expire very inconveniently soon): 1044 ocs /tmp> security cms -D -i /Users/ocs/Library/Developer/Xcode/DerivedData/HomeObserverNA-hkazqlfbeuucvybpdzdgosyhhxnx/Build/Products/Debug-maccatalyst/HomeObserverNA.app/Contents/embedded.provisionprofile -o /tmp/ppp.plist 1045 ocs /tmp> plutil -extract ExpirationDate raw -o - /tmp/ppp.plist 2026-10-15T14:04:02Z 1046 ocs /tmp> Note please that immediately after launch (and for some time after that) the value was read in through the same code without any problem. Strangely enough, when I've switched the device through the Home application, I've got the update planned through enableNotification:completionHandler: all right. and the error stopped occurring, readValueWithCompletionHandler: from that moment on again works as presumed. How can I fix the problem, what's wrong in my app? Thanks!
7
0
154
1h
Title: Hypervisor.framework — vCPU cessation guarantee after VM-owning process termination
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
0
0
21
3h
Replicated File Provider: supported download representation for a directory-backed package
We implement NSFileProviderReplicatedExtension. A package item has a content type conforming to UTType.package, with a directory and ordinary nested members in remote storage. The system requests contents for the package root. What exact representation should the extension pass to the completion handler of fetchContents(for:version:request:completionHandler:) to materialize that package? The selected macOS SDK's NSFileProviderReplicatedExtension.h, line 347, states: must be a regular file on the same volume as the user-visible URL. The complete ownership comment and method declaration are in FileProvider.framework/Headers/NSFileProviderReplicatedExtension.h, lines 314–416. The current method documentation describes same-volume temporary content, ownership transfer and matching the returned content version. For a directory-backed package, is a reconstructed directory URL in the manager-provided temporary location a supported exception to the regular-file requirement? If so, please identify the applicable contract and required returned item metadata, including content type and version. If it is not supported, what documented API sequence delivers the package's directory contents? We need to preserve the existing directory representation; we are not asking for an archive convention or a storage-format change. Verified development environment: macOS 27.0.1, build 26A434. Xcode 27.1, tool build 27A9275. Selected macOS SDK reports version 27.0. The proposed isolated test host also reports macOS 27.0.1 (26A434); its developer tools have not been inspected. Observed behavior and limits: Installed callback records show our extension returning NSFileProviderError.cannotSynchronize before handing any content URL to the system. This is our current refusal, not evidence that macOS rejected a directory URL. The actual requestedVersion arguments were not captured. Native cached version values do not establish those callback arguments. The isolated directory-URL handoff test has not run. OS acceptance or rejection of that handoff on the environment above is therefore not observed. The planned minimal reproduction uses one small synthetic package containing a nested directory, a file with known bytes and an empty member, plus one ordinary-file control. In an isolated development location, we will allow system-initiated fetches, record the actual callback arguments and completion values, and verify the resulting directory structure and bytes. No customer documents, paths, identifiers or private archives are needed. The contract question above can be answered independently of that pending runtime observation.
1
0
37
17h
macOS grants half the connection-event airtime that iOS does, for the same accessory
We make a BLE peripheral that streams continuously. It's been running against Android, Windows, macOS and iOS for years. Android and Windows sit at ~1000 kbps and stay there — many host devices, many OS versions, no per-host tuning. macOS and iOS give us about half that. We've sniffed the BLE link using a Bluetooth sniffer to find out where it goes. Same board, same firmware, every session. Read off the air trace, not from host APIs: 2M PHY both directions (LL_PHY_UPDATE_IND 0x02 / 0x02) DLE max_tx_octets = 251 ATT MTU 247 15.00 ms interval, peripheral latency 0 no encryption no other BLE or BT Classic connections active during the session (all other devices removed and forgotten) WiFi turned off for around half of the sessions, didn't seem to make any difference Peripheral airtime per connection event: central airtime/event duty @ 15 ms throughput Android 11.14 ms 74% 995 kbps, sustained Windows ≥10.70 ms ≥71% ~1000 kbps, sustained macOS 6.96 ms 46% 561 kbps iOS 6.96 ms typical 46% ~560–600 kbps macOS comes out median 6.96, p90 6.96, max 7.09 across a whole session. Same number every time. iOS normally sits in the same place, with occasional brief excursions up to Android-like performance before dropping back down. Those excursions are worth describing, because they're the interesting part. In a handful of sessions out of many, iOS runs at 12.53 ms, 84% duty, ~1030 kbps. It never holds. It drops back inside 150 ms, with no renegotiation, no parameter change and no channel-map change anywhere in the trace. Sometimes it parks at 8.35 ms for ten seconds before moving again. This isn't us saying iOS is fine in practice — it clearly isn't, we can't ship against it. The point is that the radio and the stack demonstrably can fill a 12.53 ms event when they're allowed to, so whatever is holding them to 6.96 ms isn't a hardware ceiling. "It's a factor of ability" doesn't fit. This has been asked before and answered. In thread 774487, asked directly whether iOS limits packets per connection event to 4: "there is no 'limiting' going on as it is commonly understood ... We find that 4 is a more commonly true number than 6 or more some chipsets claim." In thread 770717, to a developer on iOS 18.2 running the same parameters we are: "iOS does not 'limit' the number of writes. It is just a factor of ability." Both answers need the accessory to be the variable. Ours isn't — same board, same firmware, minutes apart, and two non-Apple hosts take it to 1000 kbps and hold it indefinitely. The only thing that changes is which OS is acting as central. We don't think this can be explained by chipset capability when the chipset is the one thing held constant. It's airtime, not packet count. The "4 packets per connection event" number people quote here is the wrong unit, and we think that's why these threads go nowhere. Within one regime, as PDUs per event go up, PDU size goes down and the airtime doesn't move: iOS 9 PDUs @ 250.4 B -> 12.51 ms 10 PDUs @ 211.1 B -> 12.32 ms 11 PDUs @ 186.4 B -> 12.47 ms macOS 5 PDUs @ 239.4 B -> 6.73 ms 6 PDUs @ 178.1 B -> 6.60 ms Nothing is counting packets. The event closes on a clock. Count and airtime were the same measurement back when everything was 1M PHY and 27-byte PDUs — with 2M and DLE they aren't, and quoting a packet count now hides the mechanism instead of describing it. The peripheral isn't the limiter. The MD bit was set on the peripheral's last PDU in 2147 of 2148 connection events. It always had more data queued, and the central closed the event anyway. This isn't a new report. The same mechanism has been described here before. Thread 133092 (2019) reports macOS closing the connection event while the peripheral still has MD set — exactly what we measure. Thread 713349 reports "about 5 response packets per connection event," which is the same budget: 6.96 ms is 5 full-size PDUs. Thread 6025 reports a drop from 7 packets to 3. None of those received a reply. We're not raising them to relitigate old threads. The point is that three independent reports arriving at the same number across several years, on different accessories, points at a property of the scheduler rather than of anyone's hardware. On iOS, this looks like it changed in iOS 18. macOS has apparently behaved this way for years, going by the threads above. On iOS it's recent. We have video and screen recordings of this same peripheral tested on iOS 17, documented at the time as running consistently at around 1000 kbps. The behaviour described here started appearing when we moved to iOS 18. The firmware and the negotiated parameters are the same now as they were then, which points at a change in radio scheduling rather than anything on our side. What we're asking: Is the per-event airtime budget deliberate? ADG §55.6 and QA1931 cover interval, latency and timeout only. Neither mentions connection event length. Why do macOS and iOS give roughly half what Android and Windows give for the same accessory, and why can iOS reach 12.53 ms without staying there? Did anything change in iOS 18 around connection event scheduling? Is there anything we can do from the accessory or app side? We're already at 2M PHY, DLE 251, MTU 247 and the 15 ms floor. If the answer is "design for a floor, not a peak" — what's the floor? Right now we plan for ~560 kbps on Apple and roughly double that everywhere else, and that decides what we can ship, and whether we can count on Apple devices as a reliable platform for our product. Captures, recordings and analysis available if they're useful.
3
0
605
19h
Help with a local AI assistant on Mac — blocked verification of the RO/DE voice app
Hello everyone, I have no background in IT or programming, and I do not have technical knowledge about computers. Because of my health problems, I have been trying to build a personal assistant, with the help of AI tools, to support me in my everyday work and activities. I would like to make clear from the outset that my goal is a local AI assistant running on my own Mac, including voice conversations, with my data and conversations staying on the computer. I am looking for help building this local solution, not recommendations for cloud chatbots or cloud voice services. Using online AI tools to help with development does not change that goal. That is the purpose of this project: to have assistance I can rely on, especially with things I do not know how to do on my own. The first step is to be able to have stable conversations with it in Romanian and German. However, I have become stuck while preparing to verify the app before installation, and I do not know how to continue safely without losing existing conversations or data. If someone with macOS experience could guide me or provide practical help to get past this step, it would mean a great deal to me. The technical appendix below was prepared with the help of AI tools, based on recorded technical evidence. Technical appendix Verification goal Before replacing the existing app, a separate copy needs to be verified in an isolated environment: without access to personal files unrelated to the test, without network access, and without affecting the existing app or its data. Complete saving and restoration of the actual conversations remain requirements that must be demonstrated before replacement; we do not consider them already verified. Environment and recorded error When this question was being prepared, system information reported macOS 27.0.1, build 26A434. However, the error below comes from a saved earlier attempt, not a new reproduction. The record of that attempt does not include the macOS or Ruby versions. The preparation used a custom sandbox-exec/SBPL profile and a /usr/bin/ruby supervisor, which was intended to launch /usr/bin/codesign to ad-hoc sign a verification copy. After removing the personal path prefix, the error was: bounded_child.rb: Operation not permitted @ realpath_rec - /Users (Errno::EPERM) The Ruby supervisor exited with code 1. No PID or outcome for the codesign process was recorded, and the copy remained unchanged and unsigned. We therefore do not present this result as a demonstrated failure of the signing tool or an Apple restriction on voice apps. Findings and corrections Source inspection showed that the preparation mechanism enumerated the ancestor directories beneath /Users but omitted /Users itself. The profile restricted reads in this area and did not have an explicit exception for metadata access to that directory. This finding is consistent with the observed denial, but it is not a diagnosis confirmed by a new access test. In a separate, inert copy, the directory enumeration and preflight check were corrected: if the necessary permissions are missing, launch is stopped. Tests of this correction verify only the preparation logic, not actual access within the sandbox. The denied attempt has not been repeated, the profile has not been broadened, and the candidate has not subsequently been signed, installed, or launched. Specific question While researching the project, we found this Apple DTS explanation of the difference between custom SBPL profiles and App Sandbox configured through entitlements. I am not looking for undocumented rules or a way to bypass the access denial. What is the documented, Apple-supported approach for isolating this verification workflow? Is an App Sandbox/XPC architecture appropriate when the workflow needs to invoke an Apple signing tool, or should app preparation, signing, and verification be separated into other isolation environments, such as a dedicated macOS virtual machine? Guidance on the appropriate mechanisms and their limitations would help us define the next safe step for the local app. Help in Romanian, German, or English is welcome. My heartfelt thanks to everyone who takes the time to read this and help.
0
0
49
22h
com.apple.vm.networking for helper binary
Hi everyone & DTS engineers, I am developing a macOS application that uses Apple's Virtualization framework and vmnet APIs. In my main application bundle, I have requested and received approval for the restricted entitlement com.apple.vm.networking. The main app works as expected with bridging/vmnet features. Now, I have embedded a command-line helper binary inside the app bundle (Contents/MacOS/). The helper is configured as follows: Set up with com.apple.security.app-sandbox = true Inherits App Sandbox rules (com.apple.security.inherit = true) Signed with com.apple.vm.networking = true in its entitlements file. However, when launching or invoking networking features from this helper binary, it fails to execute the expected vmnet functions / gets blocked at runtime. My questions for DTS / Apple Engineers: Since com.apple.vm.networking is a restricted entitlement tied to a specific App ID / Provisioning Profile, does an embedded CLI helper tool with its own Bundle ID need to be explicitly registered and granted this entitlement separately in the Developer Portal? If the helper uses com.apple.security.inherit, does AMFI still strictly evaluate the helper's own provisioning profile signature against com.apple.vm.networking independently of the main app bundle? What is the recommended architectural pattern for vmnet access when using helper tools—should network creation stay strictly in the main app process and communicate via XPC, or should the helper tool be granted its own matching profile and entitlement? Thanks in advance for any insight!
9
0
373
23h
Supported pre-initializer capture and failure enforcement for macOS guests
SANITISED SUPPORTED MACOS CAPTURE API INQUIRY REVIEW CORRECTIONS APPLIED — DRAFT, NOT SENT Question ID: MACOS-PROTECTED-CAPTURE-PROVIDER-20261004-02 Purpose: identify supported public capabilities; no project acceptance or native-execution approval is requested. Is there a supported public API combination on Apple silicon for capturing unchanged Apple-signed clang, ld and codesign inside a macOS guest after authenticated loader bootstrap but before any initializer, resolver or other target code? Only individually authenticated and explicitly enumerated loader-bootstrap operations may execute before capture; no blanket system-library exemption is assumed. The required observer/enforcer must remain outside tested guest-root authority. Include compromise of the submitting host's administrator. Observation, enforcement, state, custody, revocation and expected admission pins must not rely solely on controls that administrator can forge, replace or recover; remote signing or storage of its assertions is insufficient. The barrier must bind the exact process and guest generation, stop all target threads and byte/mapping writers, and capture complete actual loaded images, shared-cache membership, mappings, segment/private relocated bytes and backing identities coherently. Absent, crashed or disconnected observers, failed captures and missing verified release must keep execution blocked or terminate it before forbidden instructions. Release must be evidence-verified, same-incarnation and one-use. Guest termination must integrate with closed admission and generation fencing against saved-state resume, clone and replay. Our previously supplied context is macOS 26.6.2/SDK 26.5, observed but unattested. We have not run native qualification. Please state required host/guest versions explicitly; an upgrade is not assumed. Current public component documentation establishes: ES_EVENT_TYPE_AUTH_EXEC is an image-execution authorization event. es_set_deadline_miss_mode with ES_DEADLINE_MISS_MODE_FAIL_CLOSED (setter introduced in macOS 27) covers missed authorization deadlines and full-queue drops. Does this also cover client crash, deletion, disconnect or unsubscription, and could any such combination enforce the required post-loader barrier? VZVirtualMachine.pause provides VM lifecycle pausing; stop provides destructive stop with completion/error reporting. VZGuestMemoryMapping (macOS 27) exposes DRAM ranges through custom Virtio devices; the overview describes Linux guests. Is supported macOS guest use available for this purpose, and what coherent-capture/other-writer guarantees exist? Please identify the exact supported symbols and deployment configuration, documented pre-entry ordering and failure guarantees, supported macOS guest applicability, and required entitlements/signing policy. Also state whether protection weakening, target re-signing or changed system components would be required. Such requirements are compatibility limitations, not permission to perform those changes. If the full capability is unsupported, identify the specific missing public interface or guarantee rather than proposing an unsupported workaround. Public references: https://developer.apple.com/documentation/endpointsecurity/es_event_type_auth_exec https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::) https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_closed https://developer.apple.com/documentation/virtualization/vzvirtualmachine/pause() https://developer.apple.com/documentation/virtualization/vzvirtualmachine/stop(completionhandler:) https://developer.apple.com/documentation/virtualization/vzguestmemorymapping https://developer.apple.com/videos/play/wwdc2026/224/ Only this sanitised text and its public references are intended for relay. No private artifacts, personal/host identifiers, credentials or logs are needed. A provider reply is capability evidence; implementation, actual bindings, independent qualification, Founder acceptance and activation remain separate.
2
0
270
23h
Instructions for debugging recent macos kernel versions?
Is there any recent and a bit authoritative documentation which explains how to debug recent versions of macos kernel? I have found some blog posts from other users but those are either outdated or don't work for some other reason. I am guessing kernel debugging is pretty common for developers working on macos itself, so I'm hoping someone in this forum would have some working instructions for that.
13
1
1.2k
1d
Does SessionGetInfo provide authoritative current-session liveness for an ASID from a Mach audit token?
Environment: macOS 26.6.2 (25G83) Xcode 26.6 (17F113) macOS command-line process Security.framework SessionGetInfo ASID obtained from the kernel-provided audit token in a received Mach message I’m implementing a security-sensitive Mach IPC receiver. The receiver obtains the sender’s audit token from the Mach message trailer and derives the sender PID, effective UID, and audit session ID (ASID). The sender executable identity is validated separately. Given the ASID, SessionGetInfo can successfully return the corresponding SecuritySessionId and session attributes. The question is about the freshness and synchronization semantics of that lookup. At the point where the receiver authorizes a request, can a successful SessionGetInfo(asid, ...) result be treated as authoritative evidence that the corresponding login/audit session is still currently valid? In particular: What happens if the session logs out, terminates, or is revoked concurrently with the lookup? Can SessionGetInfo successfully return information for a session that is no longer current due to caching or propagation delay? Are there documented ordering or synchronization guarantees between session termination and subsequent SessionGetInfo calls from another process? Can the lookup block for an unbounded period if the underlying security service is unavailable? Is there a supported timeout or cancellation mechanism? Is there another supported public macOS API better suited to establishing authoritative current-session liveness for an ASID obtained from an audit token? The security requirement is fail-closed. I’m specifically trying to avoid private APIs, process-table heuristics, diagnostic launchctl output, or assumptions that the ASID encoded in a previously received audit token necessarily represents current session state. If the public API does not provide an authoritative liveness/freshness guarantee, confirmation of that limitation would also answer the design question. I also have a minimal 122-line Xcode sample that: creates and receives a Mach message, reads the kernel-provided audit trailer, extracts the ASID, calls SessionGetInfo, and prints the returned session ID and attributes. I can provide the sample project if useful.
7
0
207
1d
Hypervisor.framework: guest RAM counted twice in phys_footprint after both host and guest write a page
Hello, I'm building a virtualization app on Hypervisor.framework (Apple silicon). Guest RAM is anonymous memory mapped with hv_vm_map. Activity Monitor and task_info(TASK_VM_INFO).phys_footprint show the VM process using much more memory than the guest is assigned. For example, a 6 GB Windows ARM64 guest shows about 8.6 GB. Here's what I've found: Pages written only from the host count once. Pages written only by the guest count once. A page written by both the host and the guest counts twice, even though it is the same physical page. The host reads back the guest's writes, so there's no second copy. In a real VM this happens all the time. The VM process writes into guest RAM for firmware loading, disk reads, virtio buffers and so on, and the guest writes the same pages. So the reported footprint keeps growing past the guest's RAM size. Minimal reproducer (needs the com.apple.security.hypervisor entitlement): // clang -O1 -o hvfootprint hvfootprint.c -framework Hypervisor // codesign -s - --entitlements hv.entitlements -f hvfootprint #include <Hypervisor/Hypervisor.h> #include <mach/mach.h> #include <stdio.h> #include <string.h> #include <sys/mman.h> #define MB (1024ull * 1024) #define GPA 0x40000000ull #define SIZE (2048 * MB) #define PAGE 16384 static uint64_t phys_footprint_mb(void) { task_vm_info_data_t info; mach_msg_type_number_t count = TASK_VM_INFO_COUNT; task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)&info, &count); return info.phys_footprint / MB; } // Guest (EL1, MMU off): x0 = start GPA, x1 = value, x2 = page count. // Stores x1 to each 16 KB page, then exits with HVC. static const uint32_t guest_code[] = { 0xf9000001, // str x1, [x0] 0x91401000, // add x0, x0, #0x4000 0xf1000442, // subs x2, x2, #1 0x54ffffa1, // b.ne 0b 0xd4000002, // hvc #0 }; static void guest_write_all(hv_vcpu_t vcpu, uint64_t value) { hv_vcpu_set_reg(vcpu, HV_REG_PC, GPA); hv_vcpu_set_reg(vcpu, HV_REG_CPSR, 0x3c5); hv_vcpu_set_reg(vcpu, HV_REG_X0, GPA + PAGE); hv_vcpu_set_reg(vcpu, HV_REG_X1, value); hv_vcpu_set_reg(vcpu, HV_REG_X2, SIZE / PAGE - 1); hv_vcpu_run(vcpu); } int main(void) { uint8_t *ram = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0); hv_vm_create(NULL); hv_vm_map(ram, GPA, SIZE, HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC); memcpy(ram, guest_code, sizeof(guest_code)); hv_vcpu_t vcpu; hv_vcpu_exit_t *exit_info; hv_vcpu_create(&vcpu, &exit_info, NULL); printf("start: phys_footprint %5llu MB\n", phys_footprint_mb()); for (uint64_t off = PAGE; off < SIZE; off += PAGE) // host writes every page ram[off] = 1; printf("host wrote 2 GB: phys_footprint %5llu MB\n", phys_footprint_mb()); guest_write_all(vcpu, 0x55); // guest writes the same pages printf("guest wrote the same 2 GB: phys_footprint %5llu MB\n", phys_footprint_mb()); printf("host sees guest data (same pages): %s\n", ram[PAGE] == 0x55 ? "yes" : "no"); guest_write_all(vcpu, 0x66); // and again printf("guest wrote the same 2 GB again: phys_footprint %5llu MB\n", phys_footprint_mb()); return 0; } Output (macOS 27.0.1, build 26A434, Apple M5): start: phys_footprint 2 MB host wrote 2 GB: phys_footprint 2050 MB guest wrote the same 2 GB: phys_footprint 4099 MB host sees guest data (same pages): yes guest wrote the same 2 GB again: phys_footprint 4099 MB 2 GB of shared guest RAM is reported as 4 GB. Other observations The result is the same whether guest RAM comes from mmap(MAP_PRIVATE | MAP_ANON), mmap(MAP_SHARED | MAP_ANON), mach_vm_allocate, or a named memory entry (mach_make_memory_entry_64 with MAP_MEM_NAMED_CREATE) mapped twice, with one view passed to hv_vm_map and the other used by the host. footprint region totals ("Footprint:" / Dirty) count only pages the host touched. When only the guest wrote 2 GB, the regions showed about 3 MB while phys_footprint showed 2,051 MB. So neither number shows real usage once both sides touch memory. System-wide anonymous memory (host_statistics64, internal_page_count + compressor_page_count) does not grow when the guest writes pages the host already wrote. That suggests this is accounting only, not a second physical copy. Parallels describes the same symptom for its VMs (https://kb.parallels.com/en/128437). Questions Is this double accounting expected for memory mapped with hv_vm_map, or is it a bug? If it's a bug, I'll file it in Feedback Assistant with this reproducer. Is there a supported way to allocate or map guest RAM so each physical page is charged to the process once? For example, a ledger tag, memory-entry ownership, or an hv_vm_map / hv_vm_allocate option. Is phys_footprint the right input for memory-pressure decisions (jetsam) for a VM process? Could the double count make such a process look larger than it is to the system? What is the recommended way to report a VM process's real memory use to users? Thank you.
2
0
264
1d
Filesystem conversion between / and :
I am aware that for filenames, somewhere between the UI components and the kernel a conversion between / and : happens. Can someone explain where this happens? It is easy enough for me to convert ':' in kernel filenames to '/' in the string shown to or accepted from the user. But maybe there is an OS function I should be using to do that, in some more portable way, or something. More challenging is what to do when the user really wants a ':' in their filename. What is best practice? I was a bit surprised to find that in Finder, if I try to create a file called 'abc/def:ghi', I get a vague error message that tells me to "try with no punctuation marks". The case that has caused me to look into this now is a desire for filenames that are dates or times. From the user's point of view, a filename '8/10/2026 14:17:42' is not an unreasonable thing to ask for, is it? What other oddities are there? '.' and '..' of course... anything else?
7
0
125
1d
WatchOS 27 throttles BLE discoveries
Hi! We have an app that highly depends on CoreBluetooth including scanning for peripherals with an advertised serviceUUID. Our app sets the CBCentralManagerScanOptionAllowDuplicatesKey flag to true while scanning. Receiving continuous discovery events about nearby devices is key to measure the RSSI before connecting. Updating some of our test devices to watchOS 27 we noticed that our app is broken. To analyze further we created a simple app to compare behavior between watchOS 26 and 27, and the difference is clear. On the 27 device it behaves like the flag is ignored and we only receive a couple of callbacks to centralManager(_:didDiscover:advertisementData:rssi:) then it stops. We could not find any documentation declaring this as a new restriction or something regarding that has changed. Is this a bug, or is there a way to get the old behavior on the new OS? The example app used for testing is available here: https://github.com/levente-gulyas-skidata/WatchBLEExperiments (Change the serviceUUID for testing if needed) Thank you, Levi
0
4
62
1d
Reading NVMe Telemetry Logs on macOS: Create Bit and Log Page Offset Support
I am developing a diagnostic tool for an external NVMe storage device connected to a Mac through USB4 PCIe tunnelling. The device appears under IONVMeController and IONVMeBlockStorageDevice, not as USB mass storage. Basic communication works through IONVMeSMARTInterface, but I have not found a supported way to request a fresh host-initiated telemetry snapshot or retrieve its data using log-page offsets. Environment macOS 26.5.1, build 25F80 Apple Silicon, arm64 NVMe SMART interface version 1, revision 0 Controller Identify reports Log Page Attributes 0x0f, including telemetry support What Works I open the interface using IOCreatePlugInInterfaceForService and QueryInterface with the UUIDs declared in the SDK’s NVMeSMARTLibExternal.h. The following operations succeed: GetIdentifyData SMARTReadData GetLogPage for the SMART/health log, LID 0x02 Reading the host-initiated telemetry header, LID 0x07 My current prototype uses Python ctypes, with the layout and signatures matching the SDK header. Required Telemetry Operations For host-initiated telemetry, the application needs to: Issue Get Log Page for LID 0x07, with LSP bit 0 set to request snapshot creation: CDW10 bit 8. Read the 512-byte telemetry header to determine the available data size. Retrieve subsequent portions of the same snapshot using the log-page offset in CDW12/CDW13. I would also like to understand whether RAE, CDW10 bit 15, can be controlled. This workflow works on Windows and Linux against the same device. We have access to device-side command logging, so we can inspect the command fields received by the firmware. Available macOS API The SDK declares: IOReturn (*GetLogPage)( void *interface, void *data, uint32_t inLogPageId, uint32_t inNumDWords); The header describes inNumDWords as zero-based and references NVMe revision 1.0c. I do not see parameters for LSP, RAE, or the log-page offset. The published documentation is: https://developer.apple.com/documentation/iokit/ionvmesmartinterface/3521169-getlogpage Observed Behavior An ordinary 512-byte telemetry read produces the following device-side command: CDW10 = 0x007f0007 CDW11 = 0x00000000 CDW12 = 0x00000000 CDW13 = 0x00000000 LID = 0x07 LSP = 0 Create = false NUMD = 127 Offset = 0 The firmware returns a valid telemetry header advertising no payload because no snapshot has been created. For comparison, the working Windows request reaches the device as: CDW10 = 0x007f0107 Create = true The firmware then creates an approximately 32 KiB diagnostic archive. Subsequent Windows requests retrieve it in chunks using nonzero CDW12 offsets. As an explicitly unsupported experiment, I passed inLogPageId = 0x0107 to test whether the additional bit could reach CDW10. The call succeeded, but the device still received CDW10 = 0x007f0007; Create was not set. Inspection of the installed NVMeSMARTLib plugin shows that its wrapper forwards the two 32-bit arguments unchanged toIOConnectCallStructMethod, selector 5. This does not establish how the kernel driver interprets them, and I am not relying on that experimental encoding as a supported API. Questions Is there a supported userspace interface for NVMe Get Log Page that exposes LSP/Create, RAE, and the 64-bit log-page offset? Does IONVMeSMARTInterface.GetLogPage support these fields through any documented mechanism that I have missed? If not, is there another supported NVMe admin-command interface available to third-party applications for external PCIe-tunnelled controllers? What transfer-size limits and privilege or entitlement requirements apply to the recommended interface? If this functionality is not currently exposed, is Feedback Assistant the appropriate place to request it, and which component should the report target? I am looking for a supported solution that works with normal macOS security settings, without disabling SIP or replacing the active storage driver. The goal is diagnostic telemetry retrieval, not firmware updating or namespace writes.
0
0
30
1d
macOS guest freezes after update reboot on M4 host with Virtualization.framework
macOS guest (Virtualization.framework) freezes with all vCPUs halted right after a macOS update reboot - 3/3 on a macOS 26.7.1 (25G309) M4 host, seen with both UTM and Parallels Summary On a macOS 26.7.1 (25G309, beta/seed build) host with an Apple M4, every macOS guest that runs an in-place macOS update freezes at the same point: the in-OS phase of the update completes and reports success, the guest requests a reboot, records a shutdown stall 9 seconds later, reboots twice, shows the update progress screen for about a minute, and then stops. All four vCPUs enter WFI and never wake, paravirtualized graphics stops submitting, no I/O is pending on the host side, and no host service logs an error. The VM never recovers and has to be killed. Reproduced 3 out of 3 times, under two different front-ends (UTM and Parallels Desktop) and two guest versions (15.7.x and 26.6.2). Environment Host: iMac (Mac16,3), Apple M4, 16 GB RAM, macOS 26.7.1 build 25G309 (seed channel), installed the evening before the first failure. Primary guest: macOS 15.7.9 (24G830), hardware model VirtualMac2,1, 4 vCPUs, 6 GB RAM, 90 GB raw disk image (virtio-blk) stored on an external USB SSD. Networking bridged to the built-in Ethernet port. Devices enabled: memory balloon, audio, entropy, clipboard sharing; display 1920x1200 with dynamic resolution. Front-end for the primary case: UTM [version], Apple Virtualization backend. Guest was the only VM running, cold-booted, window open. Update being applied: MSU_UPDATE_24H23_patch_15.8_minor (15.7.9 -> 15.8). Other cases: a macOS 26.6.2 guest under UTM; a macOS 15.7.7 -> 15.8 guest under Parallels Desktop 26.4.2 (57518). Steps to reproduce Cold-boot a macOS 15.7.9 guest under Virtualization.framework, as the only VM on the host. In the guest: System Settings > Software Update > install macOS 15.8. Let it reboot. Expected The guest installs the update and boots into 15.8. Actual — timeline of the primary case (R = the moment Software Update requested the reboot; absolute timestamps are in the attached logs) R-23 min to R-5 min: UpdateBrainService prepares the update inside the guest, writing about 25 GB (two "disk writes" resource reports: 16.5 GB then 8.5 GB). No errors. R-1:56: post-logout install configured; disk space check passes (5.7 GB required, 40.7 GB free). R-1:44: "SUOSUPostLogoutInstallOperation: Applying MSU update". R: "Applied MSU update"; FileVault stash committed ("kAppleFDEKeyStore_commitStash success"); "Rebooting (success = 1, displayAsleep = 0, shutdown = 0)". This is the last line the guest ever writes to install.log. R+9 s: the guest writes a shutdown_stall diagnostic report. R+10 s: host sees ParavirtualizedGraphics "Device reset" / "PGDisplayNub[0]: Destroyed" (reboot #1). R+1:20: second device reset (reboot #2), 70 s after the first. On the host, the vmnet interface is torn down and recreated with no error, the AppleVirtualPlatformIdentity service completes boot attestation with no error, and the guest's graphics driver renegotiates ("Guest requested binary version: 209"). R+1:38: host logs "PGDisplay[0]: Change display mode to 3606x2254" — the guest is on the update progress screen. R+1:41 to R+2:25: the guest's six PGFifoThreads go idle one at a time. The progress bar stops partway. No further activity of any kind. R+11:35: spindump of the VM host process (com.apple.Virtualization.VirtualMachine): 0.042 s of CPU over a 5 s sample all four com.apple.virtualization.thread.cpu-N threads in Hv::Vcpu::run() -> HvCore::Hypervisor::VcpuStateManager::wait_for_interrupt() -> __psynch_cvwait cpu-0/cpu-1 wake on a ~20 ms timer tick and return to WFI; cpu-2/cpu-3 had not run for seconds no thread in any file read, write or fsync (no host I/O outstanding) PGFifoThreads last ran 550–614 s earlier process state Ss (sleeping), not U Host kernel log for the window: no USB, APFS, I/O error, timeout or reset entries. No hardware video decoder (AppleAVD) errors. The VM was left for over an hour with no change, then killed. Second case (same host, same day, UTM, guest macOS 26.6.2) Identical signature: two graphics device resets 69 s apart, display mode set 3 s after the second one, last graphics activity about a second later, then all vCPUs idle in WFI for ~6.5 hours until the VM was killed. Third case (same host, same day, Parallels Desktop 26.4.2, guest 15.7.7 -> 15.8) The guest was suspended in the middle of its update and resumed later. On resume ("-[_PGDevice willResumeWithSuspendState:error:]: Begin resume", preceded by "[VirtualMachineParameterBuilder] Failed to get auxiliary file identifier"), paravirtualized graphics never came back — its FIFO threads ran once and never again — and the guest's vCPUs sat in WFI. This may be a separate save/restore defect, but the end state is the same. What I believe is ruled out The in-OS phase of the update: it completed and reported success. Guest kernel panic: vCPUs are halted, not spinning, and there is no panic report on the guest's data volume. Disk space: 40.7 GB free in the guest at install time. Host storage stall: no uninterruptible wait, no I/O frames in the spindump, no kernel storage errors. Host hardware video decoder: no AppleAVD errors in the primary case. Host services: vmnet and AppleVirtualPlatformIdentity completed normally seconds before the hang. Guest memory: 6 GB allocated. Not yet isolated The VM images live on an external USB SSD; not yet reproduced from internal storage. The memory balloon, audio and clipboard-sharing devices were enabled; not yet reproduced with them disabled. A third-party VPN client was running on the host (guest networking is bridged, so guest traffic bypasses the host tunnel, but host firewall rules could still affect bridged frames). I don't have a confirmed-good in-place guest update on this machine from before 26.7.1, so I can't state with certainty that this is a regression. Frequency 3 of 3 attempts on this host. Attachments / available on request spindumps of the hung VM host process (primary case and second case) host unified-log excerpts for both hang windows the guest's full install.log the guest's shutdown_stall report and the two UpdateBrainService disk-writes reports sysdiagnose captured while hung, if obtained Has anyone seen macOS guests stop at this point on the 26.7.x seeds? If you can reproduce, your host build, hypervisor, and whether the VM image is on internal or external storage would be useful to compare.
7
3
762
1d
Can a sandboxed Mac App Store app schedule power-on from shutdown and automatic shutdown?
Hello, I am developing a native macOS utility using SwiftUI and AppKit, and I am investigating whether its power scheduling features can be implemented in a sandboxed app distributed through the Mac App Store. The intended functionality is: Schedule power-on from a fully shut-down state, not just wake from sleep. Schedule wake from sleep and shutdown. Let the user select weekdays and times, and modify or cancel the schedule. Keep the schedule effective after the user quits the app. For example, the user could explicitly configure power-on at 08:00 and shutdown at 22:00, Monday through Friday. My local prototype uses pmset with administrator authorization. For a possible Mac App Store version, I am looking for a supported implementation that does not execute privileged shell commands or run an application helper as root. What I have checked The documentation for IOPMSchedulePowerEvent states that it must be called as root. Calling that API directly therefore does not appear to remove the privilege requirement. App Review Guideline 2.4.5 requires sandboxing and prohibits requesting escalation to root privileges. I also reviewed launchd scheduling and user-supplied scripts through NSUserAppleScriptTask, but neither appears to provide a self-contained solution for scheduling power-on from shutdown without privileged operations. Questions Is there a public API or system-mediated authorization mechanism that supports this functionality from a sandboxed third-party app? Is there a requestable entitlement specifically applicable to power-event scheduling? If the complete feature set is unsupported, which operations are available within App Sandbox: power-on from shutdown, wake from sleep, and scheduled shutdown? The current deployment target is macOS 13 or later, on Apple silicon and Intel. If a supported solution requires a newer macOS version or specific hardware, that information would also be helpful. I am asking about supported API capabilities and architecture, rather than advance App Review approval. A documentation reference—or confirmation that scheduled power-on from shutdown is unavailable under these constraints—would help me choose the appropriate distribution model. Thank you.
1
0
68
2d
Virtualization.framework: guest teardown after VM-owner process failure
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.
4
0
118
2d
Supported way for an arm64 process to map below the 4 GB __PAGEZERO floor?
Hi Quinn — following up from DTS case 22070584. I'm working on a Windows compatibility runtime (Wine plus a CPU translator) that runs natively on Apple Silicon. 64-bit x86 Windows programs work fine. 32-bit ones don't, because they need address space in the low 4 GB: guest pointers are 32-bit, and some Windows structures sit at fixed addresses like 0x7ffe0000 that programs read directly. On arm64 I can't get anything down there: task_info(TASK_VM_INFO) -> min_address 0x100ea0000 mmap(0x7ffe0000, MAP_FIXED) -> ENOMEM mach_vm_allocate(0x7ffe0000, VM_FLAGS_FIXED) -> KERN_INVALID_ADDRESS There's also nothing below 4 GB to remove: mach_vm_region finds no entry there at all, and mach_vm_deallocate(0, 4 GB) returns KERN_SUCCESS without changing anything. Building with a smaller __PAGEZERO doesn't help either — every size I tried (0x1000, 0x4000, 0x10000, 0x100000, 0x1000000, 0x10000000, 0x80000000) gets SIGKILLed before main, with no crash report. Ad-hoc signing, the hardened runtime and -no_pie made no difference. I did notice /usr/libexec/rosetta/runtime is arm64 with no __PAGEZERO segment at all and __TEXT at vmaddr 0, so the kernel can clearly do this, at least for platform binaries. Is there a supported way for a third-party arm64 process to map below 4 GB — an entitlement, a spawn attribute, something I've missed? If the answer is no, that's fine, I'd just like to know so I can stop looking and plan around it. I have two small test programs that print all of the above if they'd be useful.
11
0
915
2d
macOS 15.8.1 update installs mBoot-20457.1.29 in Virtualization.framework VMs, and the guest can then use only 1.75 GB of RAM
Summary We use Virtualization.framework to run macOS guests on Apple silicon. When the guest is updated from macOS 15.6.1 to 15.8.1 inside the VM, the update writes a new boot loader, mBoot-20457.1.29, into the VM's auxiliary storage. After the update, the guest kernel can use only about 1.75 GB of the configured memory. The kernel wires the rest as VM_KERN_COUNT_BOOT_STOLEN. The guest swaps all the time, and builds become 7 to 18 times slower. The fault stays after a cold boot. The guest boot-args value is empty. Environment Host: macOS 26.7.2 (25G320), Apple M3 Pro, 36 GB Guest before the update: macOS 15.6.1 (24G90), installed from the IPSW Guest after the update: macOS 15.8.1 (24H32), installed with softwareupdate inside the guest VM configuration: VZMacOSBootLoader with the default ROM, VZMacPlatformConfiguration, VZMacAuxiliaryStorage, memorySize = 15032385536 (14 GiB), CPUCount = 6 A customer sees the same fault on macOS 26.6.2 with an M2 Pro host. Steps to reproduce Create a macOS 15.6.1 VM from the IPSW. Set memory to 14 GiB. Boot the guest and confirm the RAM. vm_stat accounts for about 14 GiB. In the guest, run: sudo softwareupdate --install "macOS Sequoia 15.8.1-24H32" --restart --agree-to-license --user <owner> --stdinpass After the guest restarts, run sudo zprint | grep BOOT_STOLEN and vm_stat. Shut down the VM, start it again, and do step 4 again. Expected result The guest can use about 14 GiB of RAM, as it could before the update. Actual result 15.6.1, before the update 15.8.1, after the update and after a cold boot hw.memsize 15032385536 15032385536 RAM accounted for by vm_stat (free + active + inactive + speculative + wired + compressor) about 13.99 GiB about 1.75 GiB VM_KERN_COUNT_BOOT_STOLEN not measured 12,845,072 KB (about 12.25 GiB) Swap activity Swapins 0, Swapouts 0 Swapins 225,835, Swapouts 267,316 nvram boot-args empty empty Auxiliary storage contents after the update The auxiliary storage has two boot loader slots. Each slot has a 16-byte HUFA header: magic, version, upgrade count, and slot offset from 0x4000. Header offset Upgrade count Slot offset Boot loader 0x4000 1 0x24000 iBoot-11881.140.96 (the original 15.6.1 boot loader) 0x5000 2 0x224000 mBoot-20457.1.29 (written by the 15.8.1 update) The VM boots the slot with the higher count, which is mBoot-20457.1.29. Workaround test (customer) The customer worked on a copy of an affected VM. They copied the iBoot-11881.140.96 slot over the active mBoot-20457.1.29 slot in the auxiliary storage. macOS 15.8.1 then booted with about 14 GB of usable RAM, and the RAM stayed correct after cold boots. Their results: Extraction and validation of nine Xcode versions: 9 to 10 minutes (it was 68 to 102 minutes). Xcode 26.1.1 simulator installation and cache preparation: under 7 minutes (it was more than 2 hours). This workaround changes Apple's signed firmware by hand... Not really a good idea. Related report A public report describes the same fault with UTM and the same boot loader version. It also says that the kernel computes the stolen value from the memSizeActual and memSize boot parameters that the boot loader supplies. The author filed FB24992831 (https://wadetregaskis.com/the-macos-sequoia-15-8-updater-stole-my-ram/) Questions Is this a known fault in mBoot-20457.1.29? Will a later update fix it? Is there a supported way to make a VM boot a specific boot loader slot? Or a supported way to roll back the boot loader in VZMacAuxiliaryStorage? Is there a configuration on the host or in the guest that makes mBoot pass the full memory size? We'd prefer to not make nvram read only if the new mBoot is absolutely needed for some reason.
2
1
111
2d
Supported APIs for macOS screen-lock state and graphical-session binding
We are qualifying a local macOS control service on Apple Silicon, macOS 26.5.2 (25F84). Browser control sessions must be revoked on graphical screen lock; unlock must not restore old sessions. Background project execution and durable pending decisions continue independently. We built a correctly signed user-context helper using its own data protection Keychain access group and a nonsecret WhenUnlockedThisDeviceOnly item. Every call uses a fresh noninteractive LAContext and requests actual item data. In one user-confirmed stock screen lock/unlock test, reads returned errSecInteractionNotAllowed while locked and expected data after unlock. This is one observation, not a general screen-state contract. The installed EndpointSecurity SDK explicitly states that es_graphical_session_id_t is not an audit session ID. CoreGraphics public caller-session properties expose UID, on-console and login-done, but no documented lock-state/current ES graphical-session identifier. What supported API maps a caller Aqua user-context process or NSXPCConnection audit session to the relevant ES graphical_session_id? If none exists, what supported binding should a trusted user-context helper use for current graphical lock authority, including Fast User Switching and Screen Sharing contexts? Does a fresh successful macOS DP WhenUnlockedThisDeviceOnly data read imply that this graphical session is unlocked? How does the documented SSH path that unlocks the login Keychain and DP Keychain interact with a still-locked graphical session or another context of the same UID? Is there a supported coherent current-lock snapshot/subscription mechanism for initial startup or observer restart? What completeness, ordering and maximum latency contracts apply to userspace-produced ES LoginWindow lock events? Does any supported fence detect a final delayed/lost lock or a lock+unlock between two protected reads? Does any supported API bind the unlocked condition to a subsequent application control decision, such as an application-owned SQLite COMMIT? A receiver-side monotonic freshness check can reject late replies during coordinator stalls, but its final check and COMMIT remain separate operations. We seek a supported contract or OS-enforced mechanism for this boundary. We can conservatively revoke all broker control sessions on any trusted graphical lock instead of guessing an ASID→graphical-ID mapping, but this still leaves bootstrap/current-state and event completeness open. We have not assumed private CGSession keys, audit authentication flags, a helper heartbeat, or a queue-tail fence prove screen-unlocked state. Primary references: TN3137, SecItem: Pitfalls and Best Practices, ES graphical session ID, CG session dictionary, XPC audit session.
5
0
732
3d
Core OS Resources
General: DevForums subtopic: App & System Services > Core OS Core OS is a catch-all subtopic for low-level APIs that don’t fall into one of these more specific areas: Processes & Concurrency Resources Files and Storage Resources Networking Resources Network Extension Resources Security Resources Virtualization Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"
Replies
0
Boosts
0
Views
2.1k
Activity
Aug ’25
Missing entitlement for API HomeKit error
During a test run of my HomeKit application in Xcode, after some time the app did run smoothly, I've started for one characteristic to get a pretty weird error in the readValueWithCompletionHandler: callback block: Error Domain=HMErrorDomain Code=80 "Missing entitlement for API." UserInfo={NSLocalizedFailureReason=Handler does not support background access, NSLocalizedDescription=Missing entitlement for API.} The application was launched just a couple of hours ago and the profile is still OK (though it will expire very inconveniently soon): 1044 ocs /tmp> security cms -D -i /Users/ocs/Library/Developer/Xcode/DerivedData/HomeObserverNA-hkazqlfbeuucvybpdzdgosyhhxnx/Build/Products/Debug-maccatalyst/HomeObserverNA.app/Contents/embedded.provisionprofile -o /tmp/ppp.plist 1045 ocs /tmp> plutil -extract ExpirationDate raw -o - /tmp/ppp.plist 2026-10-15T14:04:02Z 1046 ocs /tmp> Note please that immediately after launch (and for some time after that) the value was read in through the same code without any problem. Strangely enough, when I've switched the device through the Home application, I've got the update planned through enableNotification:completionHandler: all right. and the error stopped occurring, readValueWithCompletionHandler: from that moment on again works as presumed. How can I fix the problem, what's wrong in my app? Thanks!
Replies
7
Boosts
0
Views
154
Activity
1h
Title: Hypervisor.framework — vCPU cessation guarantee after VM-owning process termination
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
Replies
0
Boosts
0
Views
21
Activity
3h
Replicated File Provider: supported download representation for a directory-backed package
We implement NSFileProviderReplicatedExtension. A package item has a content type conforming to UTType.package, with a directory and ordinary nested members in remote storage. The system requests contents for the package root. What exact representation should the extension pass to the completion handler of fetchContents(for:version:request:completionHandler:) to materialize that package? The selected macOS SDK's NSFileProviderReplicatedExtension.h, line 347, states: must be a regular file on the same volume as the user-visible URL. The complete ownership comment and method declaration are in FileProvider.framework/Headers/NSFileProviderReplicatedExtension.h, lines 314–416. The current method documentation describes same-volume temporary content, ownership transfer and matching the returned content version. For a directory-backed package, is a reconstructed directory URL in the manager-provided temporary location a supported exception to the regular-file requirement? If so, please identify the applicable contract and required returned item metadata, including content type and version. If it is not supported, what documented API sequence delivers the package's directory contents? We need to preserve the existing directory representation; we are not asking for an archive convention or a storage-format change. Verified development environment: macOS 27.0.1, build 26A434. Xcode 27.1, tool build 27A9275. Selected macOS SDK reports version 27.0. The proposed isolated test host also reports macOS 27.0.1 (26A434); its developer tools have not been inspected. Observed behavior and limits: Installed callback records show our extension returning NSFileProviderError.cannotSynchronize before handing any content URL to the system. This is our current refusal, not evidence that macOS rejected a directory URL. The actual requestedVersion arguments were not captured. Native cached version values do not establish those callback arguments. The isolated directory-URL handoff test has not run. OS acceptance or rejection of that handoff on the environment above is therefore not observed. The planned minimal reproduction uses one small synthetic package containing a nested directory, a file with known bytes and an empty member, plus one ordinary-file control. In an isolated development location, we will allow system-initiated fetches, record the actual callback arguments and completion values, and verify the resulting directory structure and bytes. No customer documents, paths, identifiers or private archives are needed. The contract question above can be answered independently of that pending runtime observation.
Replies
1
Boosts
0
Views
37
Activity
17h
macOS grants half the connection-event airtime that iOS does, for the same accessory
We make a BLE peripheral that streams continuously. It's been running against Android, Windows, macOS and iOS for years. Android and Windows sit at ~1000 kbps and stay there — many host devices, many OS versions, no per-host tuning. macOS and iOS give us about half that. We've sniffed the BLE link using a Bluetooth sniffer to find out where it goes. Same board, same firmware, every session. Read off the air trace, not from host APIs: 2M PHY both directions (LL_PHY_UPDATE_IND 0x02 / 0x02) DLE max_tx_octets = 251 ATT MTU 247 15.00 ms interval, peripheral latency 0 no encryption no other BLE or BT Classic connections active during the session (all other devices removed and forgotten) WiFi turned off for around half of the sessions, didn't seem to make any difference Peripheral airtime per connection event: central airtime/event duty @ 15 ms throughput Android 11.14 ms 74% 995 kbps, sustained Windows ≥10.70 ms ≥71% ~1000 kbps, sustained macOS 6.96 ms 46% 561 kbps iOS 6.96 ms typical 46% ~560–600 kbps macOS comes out median 6.96, p90 6.96, max 7.09 across a whole session. Same number every time. iOS normally sits in the same place, with occasional brief excursions up to Android-like performance before dropping back down. Those excursions are worth describing, because they're the interesting part. In a handful of sessions out of many, iOS runs at 12.53 ms, 84% duty, ~1030 kbps. It never holds. It drops back inside 150 ms, with no renegotiation, no parameter change and no channel-map change anywhere in the trace. Sometimes it parks at 8.35 ms for ten seconds before moving again. This isn't us saying iOS is fine in practice — it clearly isn't, we can't ship against it. The point is that the radio and the stack demonstrably can fill a 12.53 ms event when they're allowed to, so whatever is holding them to 6.96 ms isn't a hardware ceiling. "It's a factor of ability" doesn't fit. This has been asked before and answered. In thread 774487, asked directly whether iOS limits packets per connection event to 4: "there is no 'limiting' going on as it is commonly understood ... We find that 4 is a more commonly true number than 6 or more some chipsets claim." In thread 770717, to a developer on iOS 18.2 running the same parameters we are: "iOS does not 'limit' the number of writes. It is just a factor of ability." Both answers need the accessory to be the variable. Ours isn't — same board, same firmware, minutes apart, and two non-Apple hosts take it to 1000 kbps and hold it indefinitely. The only thing that changes is which OS is acting as central. We don't think this can be explained by chipset capability when the chipset is the one thing held constant. It's airtime, not packet count. The "4 packets per connection event" number people quote here is the wrong unit, and we think that's why these threads go nowhere. Within one regime, as PDUs per event go up, PDU size goes down and the airtime doesn't move: iOS 9 PDUs @ 250.4 B -> 12.51 ms 10 PDUs @ 211.1 B -> 12.32 ms 11 PDUs @ 186.4 B -> 12.47 ms macOS 5 PDUs @ 239.4 B -> 6.73 ms 6 PDUs @ 178.1 B -> 6.60 ms Nothing is counting packets. The event closes on a clock. Count and airtime were the same measurement back when everything was 1M PHY and 27-byte PDUs — with 2M and DLE they aren't, and quoting a packet count now hides the mechanism instead of describing it. The peripheral isn't the limiter. The MD bit was set on the peripheral's last PDU in 2147 of 2148 connection events. It always had more data queued, and the central closed the event anyway. This isn't a new report. The same mechanism has been described here before. Thread 133092 (2019) reports macOS closing the connection event while the peripheral still has MD set — exactly what we measure. Thread 713349 reports "about 5 response packets per connection event," which is the same budget: 6.96 ms is 5 full-size PDUs. Thread 6025 reports a drop from 7 packets to 3. None of those received a reply. We're not raising them to relitigate old threads. The point is that three independent reports arriving at the same number across several years, on different accessories, points at a property of the scheduler rather than of anyone's hardware. On iOS, this looks like it changed in iOS 18. macOS has apparently behaved this way for years, going by the threads above. On iOS it's recent. We have video and screen recordings of this same peripheral tested on iOS 17, documented at the time as running consistently at around 1000 kbps. The behaviour described here started appearing when we moved to iOS 18. The firmware and the negotiated parameters are the same now as they were then, which points at a change in radio scheduling rather than anything on our side. What we're asking: Is the per-event airtime budget deliberate? ADG §55.6 and QA1931 cover interval, latency and timeout only. Neither mentions connection event length. Why do macOS and iOS give roughly half what Android and Windows give for the same accessory, and why can iOS reach 12.53 ms without staying there? Did anything change in iOS 18 around connection event scheduling? Is there anything we can do from the accessory or app side? We're already at 2M PHY, DLE 251, MTU 247 and the 15 ms floor. If the answer is "design for a floor, not a peak" — what's the floor? Right now we plan for ~560 kbps on Apple and roughly double that everywhere else, and that decides what we can ship, and whether we can count on Apple devices as a reliable platform for our product. Captures, recordings and analysis available if they're useful.
Replies
3
Boosts
0
Views
605
Activity
19h
Help with a local AI assistant on Mac — blocked verification of the RO/DE voice app
Hello everyone, I have no background in IT or programming, and I do not have technical knowledge about computers. Because of my health problems, I have been trying to build a personal assistant, with the help of AI tools, to support me in my everyday work and activities. I would like to make clear from the outset that my goal is a local AI assistant running on my own Mac, including voice conversations, with my data and conversations staying on the computer. I am looking for help building this local solution, not recommendations for cloud chatbots or cloud voice services. Using online AI tools to help with development does not change that goal. That is the purpose of this project: to have assistance I can rely on, especially with things I do not know how to do on my own. The first step is to be able to have stable conversations with it in Romanian and German. However, I have become stuck while preparing to verify the app before installation, and I do not know how to continue safely without losing existing conversations or data. If someone with macOS experience could guide me or provide practical help to get past this step, it would mean a great deal to me. The technical appendix below was prepared with the help of AI tools, based on recorded technical evidence. Technical appendix Verification goal Before replacing the existing app, a separate copy needs to be verified in an isolated environment: without access to personal files unrelated to the test, without network access, and without affecting the existing app or its data. Complete saving and restoration of the actual conversations remain requirements that must be demonstrated before replacement; we do not consider them already verified. Environment and recorded error When this question was being prepared, system information reported macOS 27.0.1, build 26A434. However, the error below comes from a saved earlier attempt, not a new reproduction. The record of that attempt does not include the macOS or Ruby versions. The preparation used a custom sandbox-exec/SBPL profile and a /usr/bin/ruby supervisor, which was intended to launch /usr/bin/codesign to ad-hoc sign a verification copy. After removing the personal path prefix, the error was: bounded_child.rb: Operation not permitted @ realpath_rec - /Users (Errno::EPERM) The Ruby supervisor exited with code 1. No PID or outcome for the codesign process was recorded, and the copy remained unchanged and unsigned. We therefore do not present this result as a demonstrated failure of the signing tool or an Apple restriction on voice apps. Findings and corrections Source inspection showed that the preparation mechanism enumerated the ancestor directories beneath /Users but omitted /Users itself. The profile restricted reads in this area and did not have an explicit exception for metadata access to that directory. This finding is consistent with the observed denial, but it is not a diagnosis confirmed by a new access test. In a separate, inert copy, the directory enumeration and preflight check were corrected: if the necessary permissions are missing, launch is stopped. Tests of this correction verify only the preparation logic, not actual access within the sandbox. The denied attempt has not been repeated, the profile has not been broadened, and the candidate has not subsequently been signed, installed, or launched. Specific question While researching the project, we found this Apple DTS explanation of the difference between custom SBPL profiles and App Sandbox configured through entitlements. I am not looking for undocumented rules or a way to bypass the access denial. What is the documented, Apple-supported approach for isolating this verification workflow? Is an App Sandbox/XPC architecture appropriate when the workflow needs to invoke an Apple signing tool, or should app preparation, signing, and verification be separated into other isolation environments, such as a dedicated macOS virtual machine? Guidance on the appropriate mechanisms and their limitations would help us define the next safe step for the local app. Help in Romanian, German, or English is welcome. My heartfelt thanks to everyone who takes the time to read this and help.
Replies
0
Boosts
0
Views
49
Activity
22h
com.apple.vm.networking for helper binary
Hi everyone & DTS engineers, I am developing a macOS application that uses Apple's Virtualization framework and vmnet APIs. In my main application bundle, I have requested and received approval for the restricted entitlement com.apple.vm.networking. The main app works as expected with bridging/vmnet features. Now, I have embedded a command-line helper binary inside the app bundle (Contents/MacOS/). The helper is configured as follows: Set up with com.apple.security.app-sandbox = true Inherits App Sandbox rules (com.apple.security.inherit = true) Signed with com.apple.vm.networking = true in its entitlements file. However, when launching or invoking networking features from this helper binary, it fails to execute the expected vmnet functions / gets blocked at runtime. My questions for DTS / Apple Engineers: Since com.apple.vm.networking is a restricted entitlement tied to a specific App ID / Provisioning Profile, does an embedded CLI helper tool with its own Bundle ID need to be explicitly registered and granted this entitlement separately in the Developer Portal? If the helper uses com.apple.security.inherit, does AMFI still strictly evaluate the helper's own provisioning profile signature against com.apple.vm.networking independently of the main app bundle? What is the recommended architectural pattern for vmnet access when using helper tools—should network creation stay strictly in the main app process and communicate via XPC, or should the helper tool be granted its own matching profile and entitlement? Thanks in advance for any insight!
Replies
9
Boosts
0
Views
373
Activity
23h
Supported pre-initializer capture and failure enforcement for macOS guests
SANITISED SUPPORTED MACOS CAPTURE API INQUIRY REVIEW CORRECTIONS APPLIED — DRAFT, NOT SENT Question ID: MACOS-PROTECTED-CAPTURE-PROVIDER-20261004-02 Purpose: identify supported public capabilities; no project acceptance or native-execution approval is requested. Is there a supported public API combination on Apple silicon for capturing unchanged Apple-signed clang, ld and codesign inside a macOS guest after authenticated loader bootstrap but before any initializer, resolver or other target code? Only individually authenticated and explicitly enumerated loader-bootstrap operations may execute before capture; no blanket system-library exemption is assumed. The required observer/enforcer must remain outside tested guest-root authority. Include compromise of the submitting host's administrator. Observation, enforcement, state, custody, revocation and expected admission pins must not rely solely on controls that administrator can forge, replace or recover; remote signing or storage of its assertions is insufficient. The barrier must bind the exact process and guest generation, stop all target threads and byte/mapping writers, and capture complete actual loaded images, shared-cache membership, mappings, segment/private relocated bytes and backing identities coherently. Absent, crashed or disconnected observers, failed captures and missing verified release must keep execution blocked or terminate it before forbidden instructions. Release must be evidence-verified, same-incarnation and one-use. Guest termination must integrate with closed admission and generation fencing against saved-state resume, clone and replay. Our previously supplied context is macOS 26.6.2/SDK 26.5, observed but unattested. We have not run native qualification. Please state required host/guest versions explicitly; an upgrade is not assumed. Current public component documentation establishes: ES_EVENT_TYPE_AUTH_EXEC is an image-execution authorization event. es_set_deadline_miss_mode with ES_DEADLINE_MISS_MODE_FAIL_CLOSED (setter introduced in macOS 27) covers missed authorization deadlines and full-queue drops. Does this also cover client crash, deletion, disconnect or unsubscription, and could any such combination enforce the required post-loader barrier? VZVirtualMachine.pause provides VM lifecycle pausing; stop provides destructive stop with completion/error reporting. VZGuestMemoryMapping (macOS 27) exposes DRAM ranges through custom Virtio devices; the overview describes Linux guests. Is supported macOS guest use available for this purpose, and what coherent-capture/other-writer guarantees exist? Please identify the exact supported symbols and deployment configuration, documented pre-entry ordering and failure guarantees, supported macOS guest applicability, and required entitlements/signing policy. Also state whether protection weakening, target re-signing or changed system components would be required. Such requirements are compatibility limitations, not permission to perform those changes. If the full capability is unsupported, identify the specific missing public interface or guarantee rather than proposing an unsupported workaround. Public references: https://developer.apple.com/documentation/endpointsecurity/es_event_type_auth_exec https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::) https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_closed https://developer.apple.com/documentation/virtualization/vzvirtualmachine/pause() https://developer.apple.com/documentation/virtualization/vzvirtualmachine/stop(completionhandler:) https://developer.apple.com/documentation/virtualization/vzguestmemorymapping https://developer.apple.com/videos/play/wwdc2026/224/ Only this sanitised text and its public references are intended for relay. No private artifacts, personal/host identifiers, credentials or logs are needed. A provider reply is capability evidence; implementation, actual bindings, independent qualification, Founder acceptance and activation remain separate.
Replies
2
Boosts
0
Views
270
Activity
23h
Instructions for debugging recent macos kernel versions?
Is there any recent and a bit authoritative documentation which explains how to debug recent versions of macos kernel? I have found some blog posts from other users but those are either outdated or don't work for some other reason. I am guessing kernel debugging is pretty common for developers working on macos itself, so I'm hoping someone in this forum would have some working instructions for that.
Replies
13
Boosts
1
Views
1.2k
Activity
1d
Does SessionGetInfo provide authoritative current-session liveness for an ASID from a Mach audit token?
Environment: macOS 26.6.2 (25G83) Xcode 26.6 (17F113) macOS command-line process Security.framework SessionGetInfo ASID obtained from the kernel-provided audit token in a received Mach message I’m implementing a security-sensitive Mach IPC receiver. The receiver obtains the sender’s audit token from the Mach message trailer and derives the sender PID, effective UID, and audit session ID (ASID). The sender executable identity is validated separately. Given the ASID, SessionGetInfo can successfully return the corresponding SecuritySessionId and session attributes. The question is about the freshness and synchronization semantics of that lookup. At the point where the receiver authorizes a request, can a successful SessionGetInfo(asid, ...) result be treated as authoritative evidence that the corresponding login/audit session is still currently valid? In particular: What happens if the session logs out, terminates, or is revoked concurrently with the lookup? Can SessionGetInfo successfully return information for a session that is no longer current due to caching or propagation delay? Are there documented ordering or synchronization guarantees between session termination and subsequent SessionGetInfo calls from another process? Can the lookup block for an unbounded period if the underlying security service is unavailable? Is there a supported timeout or cancellation mechanism? Is there another supported public macOS API better suited to establishing authoritative current-session liveness for an ASID obtained from an audit token? The security requirement is fail-closed. I’m specifically trying to avoid private APIs, process-table heuristics, diagnostic launchctl output, or assumptions that the ASID encoded in a previously received audit token necessarily represents current session state. If the public API does not provide an authoritative liveness/freshness guarantee, confirmation of that limitation would also answer the design question. I also have a minimal 122-line Xcode sample that: creates and receives a Mach message, reads the kernel-provided audit trailer, extracts the ASID, calls SessionGetInfo, and prints the returned session ID and attributes. I can provide the sample project if useful.
Replies
7
Boosts
0
Views
207
Activity
1d
Hypervisor.framework: guest RAM counted twice in phys_footprint after both host and guest write a page
Hello, I'm building a virtualization app on Hypervisor.framework (Apple silicon). Guest RAM is anonymous memory mapped with hv_vm_map. Activity Monitor and task_info(TASK_VM_INFO).phys_footprint show the VM process using much more memory than the guest is assigned. For example, a 6 GB Windows ARM64 guest shows about 8.6 GB. Here's what I've found: Pages written only from the host count once. Pages written only by the guest count once. A page written by both the host and the guest counts twice, even though it is the same physical page. The host reads back the guest's writes, so there's no second copy. In a real VM this happens all the time. The VM process writes into guest RAM for firmware loading, disk reads, virtio buffers and so on, and the guest writes the same pages. So the reported footprint keeps growing past the guest's RAM size. Minimal reproducer (needs the com.apple.security.hypervisor entitlement): // clang -O1 -o hvfootprint hvfootprint.c -framework Hypervisor // codesign -s - --entitlements hv.entitlements -f hvfootprint #include <Hypervisor/Hypervisor.h> #include <mach/mach.h> #include <stdio.h> #include <string.h> #include <sys/mman.h> #define MB (1024ull * 1024) #define GPA 0x40000000ull #define SIZE (2048 * MB) #define PAGE 16384 static uint64_t phys_footprint_mb(void) { task_vm_info_data_t info; mach_msg_type_number_t count = TASK_VM_INFO_COUNT; task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)&info, &count); return info.phys_footprint / MB; } // Guest (EL1, MMU off): x0 = start GPA, x1 = value, x2 = page count. // Stores x1 to each 16 KB page, then exits with HVC. static const uint32_t guest_code[] = { 0xf9000001, // str x1, [x0] 0x91401000, // add x0, x0, #0x4000 0xf1000442, // subs x2, x2, #1 0x54ffffa1, // b.ne 0b 0xd4000002, // hvc #0 }; static void guest_write_all(hv_vcpu_t vcpu, uint64_t value) { hv_vcpu_set_reg(vcpu, HV_REG_PC, GPA); hv_vcpu_set_reg(vcpu, HV_REG_CPSR, 0x3c5); hv_vcpu_set_reg(vcpu, HV_REG_X0, GPA + PAGE); hv_vcpu_set_reg(vcpu, HV_REG_X1, value); hv_vcpu_set_reg(vcpu, HV_REG_X2, SIZE / PAGE - 1); hv_vcpu_run(vcpu); } int main(void) { uint8_t *ram = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0); hv_vm_create(NULL); hv_vm_map(ram, GPA, SIZE, HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC); memcpy(ram, guest_code, sizeof(guest_code)); hv_vcpu_t vcpu; hv_vcpu_exit_t *exit_info; hv_vcpu_create(&vcpu, &exit_info, NULL); printf("start: phys_footprint %5llu MB\n", phys_footprint_mb()); for (uint64_t off = PAGE; off < SIZE; off += PAGE) // host writes every page ram[off] = 1; printf("host wrote 2 GB: phys_footprint %5llu MB\n", phys_footprint_mb()); guest_write_all(vcpu, 0x55); // guest writes the same pages printf("guest wrote the same 2 GB: phys_footprint %5llu MB\n", phys_footprint_mb()); printf("host sees guest data (same pages): %s\n", ram[PAGE] == 0x55 ? "yes" : "no"); guest_write_all(vcpu, 0x66); // and again printf("guest wrote the same 2 GB again: phys_footprint %5llu MB\n", phys_footprint_mb()); return 0; } Output (macOS 27.0.1, build 26A434, Apple M5): start: phys_footprint 2 MB host wrote 2 GB: phys_footprint 2050 MB guest wrote the same 2 GB: phys_footprint 4099 MB host sees guest data (same pages): yes guest wrote the same 2 GB again: phys_footprint 4099 MB 2 GB of shared guest RAM is reported as 4 GB. Other observations The result is the same whether guest RAM comes from mmap(MAP_PRIVATE | MAP_ANON), mmap(MAP_SHARED | MAP_ANON), mach_vm_allocate, or a named memory entry (mach_make_memory_entry_64 with MAP_MEM_NAMED_CREATE) mapped twice, with one view passed to hv_vm_map and the other used by the host. footprint region totals ("Footprint:" / Dirty) count only pages the host touched. When only the guest wrote 2 GB, the regions showed about 3 MB while phys_footprint showed 2,051 MB. So neither number shows real usage once both sides touch memory. System-wide anonymous memory (host_statistics64, internal_page_count + compressor_page_count) does not grow when the guest writes pages the host already wrote. That suggests this is accounting only, not a second physical copy. Parallels describes the same symptom for its VMs (https://kb.parallels.com/en/128437). Questions Is this double accounting expected for memory mapped with hv_vm_map, or is it a bug? If it's a bug, I'll file it in Feedback Assistant with this reproducer. Is there a supported way to allocate or map guest RAM so each physical page is charged to the process once? For example, a ledger tag, memory-entry ownership, or an hv_vm_map / hv_vm_allocate option. Is phys_footprint the right input for memory-pressure decisions (jetsam) for a VM process? Could the double count make such a process look larger than it is to the system? What is the recommended way to report a VM process's real memory use to users? Thank you.
Replies
2
Boosts
0
Views
264
Activity
1d
No console log from WatchOS10 in Xcode or console app
I'm trying to debug a problem that's affecting customers who have upgraded to WatchOS 10, and I'm unable to get any console output from the watch when I debug the watch app in Xcode, or from the console app connecting from my Mac. The other weird thing is that my watch shows up twice in the device list in the console app. Is this a known issue?
Replies
4
Boosts
2
Views
909
Activity
1d
Filesystem conversion between / and :
I am aware that for filenames, somewhere between the UI components and the kernel a conversion between / and : happens. Can someone explain where this happens? It is easy enough for me to convert ':' in kernel filenames to '/' in the string shown to or accepted from the user. But maybe there is an OS function I should be using to do that, in some more portable way, or something. More challenging is what to do when the user really wants a ':' in their filename. What is best practice? I was a bit surprised to find that in Finder, if I try to create a file called 'abc/def:ghi', I get a vague error message that tells me to "try with no punctuation marks". The case that has caused me to look into this now is a desire for filenames that are dates or times. From the user's point of view, a filename '8/10/2026 14:17:42' is not an unreasonable thing to ask for, is it? What other oddities are there? '.' and '..' of course... anything else?
Replies
7
Boosts
0
Views
125
Activity
1d
WatchOS 27 throttles BLE discoveries
Hi! We have an app that highly depends on CoreBluetooth including scanning for peripherals with an advertised serviceUUID. Our app sets the CBCentralManagerScanOptionAllowDuplicatesKey flag to true while scanning. Receiving continuous discovery events about nearby devices is key to measure the RSSI before connecting. Updating some of our test devices to watchOS 27 we noticed that our app is broken. To analyze further we created a simple app to compare behavior between watchOS 26 and 27, and the difference is clear. On the 27 device it behaves like the flag is ignored and we only receive a couple of callbacks to centralManager(_:didDiscover:advertisementData:rssi:) then it stops. We could not find any documentation declaring this as a new restriction or something regarding that has changed. Is this a bug, or is there a way to get the old behavior on the new OS? The example app used for testing is available here: https://github.com/levente-gulyas-skidata/WatchBLEExperiments (Change the serviceUUID for testing if needed) Thank you, Levi
Replies
0
Boosts
4
Views
62
Activity
1d
Reading NVMe Telemetry Logs on macOS: Create Bit and Log Page Offset Support
I am developing a diagnostic tool for an external NVMe storage device connected to a Mac through USB4 PCIe tunnelling. The device appears under IONVMeController and IONVMeBlockStorageDevice, not as USB mass storage. Basic communication works through IONVMeSMARTInterface, but I have not found a supported way to request a fresh host-initiated telemetry snapshot or retrieve its data using log-page offsets. Environment macOS 26.5.1, build 25F80 Apple Silicon, arm64 NVMe SMART interface version 1, revision 0 Controller Identify reports Log Page Attributes 0x0f, including telemetry support What Works I open the interface using IOCreatePlugInInterfaceForService and QueryInterface with the UUIDs declared in the SDK’s NVMeSMARTLibExternal.h. The following operations succeed: GetIdentifyData SMARTReadData GetLogPage for the SMART/health log, LID 0x02 Reading the host-initiated telemetry header, LID 0x07 My current prototype uses Python ctypes, with the layout and signatures matching the SDK header. Required Telemetry Operations For host-initiated telemetry, the application needs to: Issue Get Log Page for LID 0x07, with LSP bit 0 set to request snapshot creation: CDW10 bit 8. Read the 512-byte telemetry header to determine the available data size. Retrieve subsequent portions of the same snapshot using the log-page offset in CDW12/CDW13. I would also like to understand whether RAE, CDW10 bit 15, can be controlled. This workflow works on Windows and Linux against the same device. We have access to device-side command logging, so we can inspect the command fields received by the firmware. Available macOS API The SDK declares: IOReturn (*GetLogPage)( void *interface, void *data, uint32_t inLogPageId, uint32_t inNumDWords); The header describes inNumDWords as zero-based and references NVMe revision 1.0c. I do not see parameters for LSP, RAE, or the log-page offset. The published documentation is: https://developer.apple.com/documentation/iokit/ionvmesmartinterface/3521169-getlogpage Observed Behavior An ordinary 512-byte telemetry read produces the following device-side command: CDW10 = 0x007f0007 CDW11 = 0x00000000 CDW12 = 0x00000000 CDW13 = 0x00000000 LID = 0x07 LSP = 0 Create = false NUMD = 127 Offset = 0 The firmware returns a valid telemetry header advertising no payload because no snapshot has been created. For comparison, the working Windows request reaches the device as: CDW10 = 0x007f0107 Create = true The firmware then creates an approximately 32 KiB diagnostic archive. Subsequent Windows requests retrieve it in chunks using nonzero CDW12 offsets. As an explicitly unsupported experiment, I passed inLogPageId = 0x0107 to test whether the additional bit could reach CDW10. The call succeeded, but the device still received CDW10 = 0x007f0007; Create was not set. Inspection of the installed NVMeSMARTLib plugin shows that its wrapper forwards the two 32-bit arguments unchanged toIOConnectCallStructMethod, selector 5. This does not establish how the kernel driver interprets them, and I am not relying on that experimental encoding as a supported API. Questions Is there a supported userspace interface for NVMe Get Log Page that exposes LSP/Create, RAE, and the 64-bit log-page offset? Does IONVMeSMARTInterface.GetLogPage support these fields through any documented mechanism that I have missed? If not, is there another supported NVMe admin-command interface available to third-party applications for external PCIe-tunnelled controllers? What transfer-size limits and privilege or entitlement requirements apply to the recommended interface? If this functionality is not currently exposed, is Feedback Assistant the appropriate place to request it, and which component should the report target? I am looking for a supported solution that works with normal macOS security settings, without disabling SIP or replacing the active storage driver. The goal is diagnostic telemetry retrieval, not firmware updating or namespace writes.
Replies
0
Boosts
0
Views
30
Activity
1d
macOS guest freezes after update reboot on M4 host with Virtualization.framework
macOS guest (Virtualization.framework) freezes with all vCPUs halted right after a macOS update reboot - 3/3 on a macOS 26.7.1 (25G309) M4 host, seen with both UTM and Parallels Summary On a macOS 26.7.1 (25G309, beta/seed build) host with an Apple M4, every macOS guest that runs an in-place macOS update freezes at the same point: the in-OS phase of the update completes and reports success, the guest requests a reboot, records a shutdown stall 9 seconds later, reboots twice, shows the update progress screen for about a minute, and then stops. All four vCPUs enter WFI and never wake, paravirtualized graphics stops submitting, no I/O is pending on the host side, and no host service logs an error. The VM never recovers and has to be killed. Reproduced 3 out of 3 times, under two different front-ends (UTM and Parallels Desktop) and two guest versions (15.7.x and 26.6.2). Environment Host: iMac (Mac16,3), Apple M4, 16 GB RAM, macOS 26.7.1 build 25G309 (seed channel), installed the evening before the first failure. Primary guest: macOS 15.7.9 (24G830), hardware model VirtualMac2,1, 4 vCPUs, 6 GB RAM, 90 GB raw disk image (virtio-blk) stored on an external USB SSD. Networking bridged to the built-in Ethernet port. Devices enabled: memory balloon, audio, entropy, clipboard sharing; display 1920x1200 with dynamic resolution. Front-end for the primary case: UTM [version], Apple Virtualization backend. Guest was the only VM running, cold-booted, window open. Update being applied: MSU_UPDATE_24H23_patch_15.8_minor (15.7.9 -> 15.8). Other cases: a macOS 26.6.2 guest under UTM; a macOS 15.7.7 -> 15.8 guest under Parallels Desktop 26.4.2 (57518). Steps to reproduce Cold-boot a macOS 15.7.9 guest under Virtualization.framework, as the only VM on the host. In the guest: System Settings > Software Update > install macOS 15.8. Let it reboot. Expected The guest installs the update and boots into 15.8. Actual — timeline of the primary case (R = the moment Software Update requested the reboot; absolute timestamps are in the attached logs) R-23 min to R-5 min: UpdateBrainService prepares the update inside the guest, writing about 25 GB (two "disk writes" resource reports: 16.5 GB then 8.5 GB). No errors. R-1:56: post-logout install configured; disk space check passes (5.7 GB required, 40.7 GB free). R-1:44: "SUOSUPostLogoutInstallOperation: Applying MSU update". R: "Applied MSU update"; FileVault stash committed ("kAppleFDEKeyStore_commitStash success"); "Rebooting (success = 1, displayAsleep = 0, shutdown = 0)". This is the last line the guest ever writes to install.log. R+9 s: the guest writes a shutdown_stall diagnostic report. R+10 s: host sees ParavirtualizedGraphics "Device reset" / "PGDisplayNub[0]: Destroyed" (reboot #1). R+1:20: second device reset (reboot #2), 70 s after the first. On the host, the vmnet interface is torn down and recreated with no error, the AppleVirtualPlatformIdentity service completes boot attestation with no error, and the guest's graphics driver renegotiates ("Guest requested binary version: 209"). R+1:38: host logs "PGDisplay[0]: Change display mode to 3606x2254" — the guest is on the update progress screen. R+1:41 to R+2:25: the guest's six PGFifoThreads go idle one at a time. The progress bar stops partway. No further activity of any kind. R+11:35: spindump of the VM host process (com.apple.Virtualization.VirtualMachine): 0.042 s of CPU over a 5 s sample all four com.apple.virtualization.thread.cpu-N threads in Hv::Vcpu::run() -> HvCore::Hypervisor::VcpuStateManager::wait_for_interrupt() -> __psynch_cvwait cpu-0/cpu-1 wake on a ~20 ms timer tick and return to WFI; cpu-2/cpu-3 had not run for seconds no thread in any file read, write or fsync (no host I/O outstanding) PGFifoThreads last ran 550–614 s earlier process state Ss (sleeping), not U Host kernel log for the window: no USB, APFS, I/O error, timeout or reset entries. No hardware video decoder (AppleAVD) errors. The VM was left for over an hour with no change, then killed. Second case (same host, same day, UTM, guest macOS 26.6.2) Identical signature: two graphics device resets 69 s apart, display mode set 3 s after the second one, last graphics activity about a second later, then all vCPUs idle in WFI for ~6.5 hours until the VM was killed. Third case (same host, same day, Parallels Desktop 26.4.2, guest 15.7.7 -> 15.8) The guest was suspended in the middle of its update and resumed later. On resume ("-[_PGDevice willResumeWithSuspendState:error:]: Begin resume", preceded by "[VirtualMachineParameterBuilder] Failed to get auxiliary file identifier"), paravirtualized graphics never came back — its FIFO threads ran once and never again — and the guest's vCPUs sat in WFI. This may be a separate save/restore defect, but the end state is the same. What I believe is ruled out The in-OS phase of the update: it completed and reported success. Guest kernel panic: vCPUs are halted, not spinning, and there is no panic report on the guest's data volume. Disk space: 40.7 GB free in the guest at install time. Host storage stall: no uninterruptible wait, no I/O frames in the spindump, no kernel storage errors. Host hardware video decoder: no AppleAVD errors in the primary case. Host services: vmnet and AppleVirtualPlatformIdentity completed normally seconds before the hang. Guest memory: 6 GB allocated. Not yet isolated The VM images live on an external USB SSD; not yet reproduced from internal storage. The memory balloon, audio and clipboard-sharing devices were enabled; not yet reproduced with them disabled. A third-party VPN client was running on the host (guest networking is bridged, so guest traffic bypasses the host tunnel, but host firewall rules could still affect bridged frames). I don't have a confirmed-good in-place guest update on this machine from before 26.7.1, so I can't state with certainty that this is a regression. Frequency 3 of 3 attempts on this host. Attachments / available on request spindumps of the hung VM host process (primary case and second case) host unified-log excerpts for both hang windows the guest's full install.log the guest's shutdown_stall report and the two UpdateBrainService disk-writes reports sysdiagnose captured while hung, if obtained Has anyone seen macOS guests stop at this point on the 26.7.x seeds? If you can reproduce, your host build, hypervisor, and whether the VM image is on internal or external storage would be useful to compare.
Replies
7
Boosts
3
Views
762
Activity
1d
Can a sandboxed Mac App Store app schedule power-on from shutdown and automatic shutdown?
Hello, I am developing a native macOS utility using SwiftUI and AppKit, and I am investigating whether its power scheduling features can be implemented in a sandboxed app distributed through the Mac App Store. The intended functionality is: Schedule power-on from a fully shut-down state, not just wake from sleep. Schedule wake from sleep and shutdown. Let the user select weekdays and times, and modify or cancel the schedule. Keep the schedule effective after the user quits the app. For example, the user could explicitly configure power-on at 08:00 and shutdown at 22:00, Monday through Friday. My local prototype uses pmset with administrator authorization. For a possible Mac App Store version, I am looking for a supported implementation that does not execute privileged shell commands or run an application helper as root. What I have checked The documentation for IOPMSchedulePowerEvent states that it must be called as root. Calling that API directly therefore does not appear to remove the privilege requirement. App Review Guideline 2.4.5 requires sandboxing and prohibits requesting escalation to root privileges. I also reviewed launchd scheduling and user-supplied scripts through NSUserAppleScriptTask, but neither appears to provide a self-contained solution for scheduling power-on from shutdown without privileged operations. Questions Is there a public API or system-mediated authorization mechanism that supports this functionality from a sandboxed third-party app? Is there a requestable entitlement specifically applicable to power-event scheduling? If the complete feature set is unsupported, which operations are available within App Sandbox: power-on from shutdown, wake from sleep, and scheduled shutdown? The current deployment target is macOS 13 or later, on Apple silicon and Intel. If a supported solution requires a newer macOS version or specific hardware, that information would also be helpful. I am asking about supported API capabilities and architecture, rather than advance App Review approval. A documentation reference—or confirmation that scheduled power-on from shutdown is unavailable under these constraints—would help me choose the appropriate distribution model. Thank you.
Replies
1
Boosts
0
Views
68
Activity
2d
Virtualization.framework: guest teardown after VM-owner process failure
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.
Replies
4
Boosts
0
Views
118
Activity
2d
Supported way for an arm64 process to map below the 4 GB __PAGEZERO floor?
Hi Quinn — following up from DTS case 22070584. I'm working on a Windows compatibility runtime (Wine plus a CPU translator) that runs natively on Apple Silicon. 64-bit x86 Windows programs work fine. 32-bit ones don't, because they need address space in the low 4 GB: guest pointers are 32-bit, and some Windows structures sit at fixed addresses like 0x7ffe0000 that programs read directly. On arm64 I can't get anything down there: task_info(TASK_VM_INFO) -> min_address 0x100ea0000 mmap(0x7ffe0000, MAP_FIXED) -> ENOMEM mach_vm_allocate(0x7ffe0000, VM_FLAGS_FIXED) -> KERN_INVALID_ADDRESS There's also nothing below 4 GB to remove: mach_vm_region finds no entry there at all, and mach_vm_deallocate(0, 4 GB) returns KERN_SUCCESS without changing anything. Building with a smaller __PAGEZERO doesn't help either — every size I tried (0x1000, 0x4000, 0x10000, 0x100000, 0x1000000, 0x10000000, 0x80000000) gets SIGKILLed before main, with no crash report. Ad-hoc signing, the hardened runtime and -no_pie made no difference. I did notice /usr/libexec/rosetta/runtime is arm64 with no __PAGEZERO segment at all and __TEXT at vmaddr 0, so the kernel can clearly do this, at least for platform binaries. Is there a supported way for a third-party arm64 process to map below 4 GB — an entitlement, a spawn attribute, something I've missed? If the answer is no, that's fine, I'd just like to know so I can stop looking and plan around it. I have two small test programs that print all of the above if they'd be useful.
Replies
11
Boosts
0
Views
915
Activity
2d
macOS 15.8.1 update installs mBoot-20457.1.29 in Virtualization.framework VMs, and the guest can then use only 1.75 GB of RAM
Summary We use Virtualization.framework to run macOS guests on Apple silicon. When the guest is updated from macOS 15.6.1 to 15.8.1 inside the VM, the update writes a new boot loader, mBoot-20457.1.29, into the VM's auxiliary storage. After the update, the guest kernel can use only about 1.75 GB of the configured memory. The kernel wires the rest as VM_KERN_COUNT_BOOT_STOLEN. The guest swaps all the time, and builds become 7 to 18 times slower. The fault stays after a cold boot. The guest boot-args value is empty. Environment Host: macOS 26.7.2 (25G320), Apple M3 Pro, 36 GB Guest before the update: macOS 15.6.1 (24G90), installed from the IPSW Guest after the update: macOS 15.8.1 (24H32), installed with softwareupdate inside the guest VM configuration: VZMacOSBootLoader with the default ROM, VZMacPlatformConfiguration, VZMacAuxiliaryStorage, memorySize = 15032385536 (14 GiB), CPUCount = 6 A customer sees the same fault on macOS 26.6.2 with an M2 Pro host. Steps to reproduce Create a macOS 15.6.1 VM from the IPSW. Set memory to 14 GiB. Boot the guest and confirm the RAM. vm_stat accounts for about 14 GiB. In the guest, run: sudo softwareupdate --install "macOS Sequoia 15.8.1-24H32" --restart --agree-to-license --user <owner> --stdinpass After the guest restarts, run sudo zprint | grep BOOT_STOLEN and vm_stat. Shut down the VM, start it again, and do step 4 again. Expected result The guest can use about 14 GiB of RAM, as it could before the update. Actual result 15.6.1, before the update 15.8.1, after the update and after a cold boot hw.memsize 15032385536 15032385536 RAM accounted for by vm_stat (free + active + inactive + speculative + wired + compressor) about 13.99 GiB about 1.75 GiB VM_KERN_COUNT_BOOT_STOLEN not measured 12,845,072 KB (about 12.25 GiB) Swap activity Swapins 0, Swapouts 0 Swapins 225,835, Swapouts 267,316 nvram boot-args empty empty Auxiliary storage contents after the update The auxiliary storage has two boot loader slots. Each slot has a 16-byte HUFA header: magic, version, upgrade count, and slot offset from 0x4000. Header offset Upgrade count Slot offset Boot loader 0x4000 1 0x24000 iBoot-11881.140.96 (the original 15.6.1 boot loader) 0x5000 2 0x224000 mBoot-20457.1.29 (written by the 15.8.1 update) The VM boots the slot with the higher count, which is mBoot-20457.1.29. Workaround test (customer) The customer worked on a copy of an affected VM. They copied the iBoot-11881.140.96 slot over the active mBoot-20457.1.29 slot in the auxiliary storage. macOS 15.8.1 then booted with about 14 GB of usable RAM, and the RAM stayed correct after cold boots. Their results: Extraction and validation of nine Xcode versions: 9 to 10 minutes (it was 68 to 102 minutes). Xcode 26.1.1 simulator installation and cache preparation: under 7 minutes (it was more than 2 hours). This workaround changes Apple's signed firmware by hand... Not really a good idea. Related report A public report describes the same fault with UTM and the same boot loader version. It also says that the kernel computes the stolen value from the memSizeActual and memSize boot parameters that the boot loader supplies. The author filed FB24992831 (https://wadetregaskis.com/the-macos-sequoia-15-8-updater-stole-my-ram/) Questions Is this a known fault in mBoot-20457.1.29? Will a later update fix it? Is there a supported way to make a VM boot a specific boot loader slot? Or a supported way to roll back the boot loader in VZMacAuxiliaryStorage? Is there a configuration on the host or in the guest that makes mBoot pass the full memory size? We'd prefer to not make nvram read only if the new mBoot is absolutely needed for some reason.
Replies
2
Boosts
1
Views
111
Activity
2d
Supported APIs for macOS screen-lock state and graphical-session binding
We are qualifying a local macOS control service on Apple Silicon, macOS 26.5.2 (25F84). Browser control sessions must be revoked on graphical screen lock; unlock must not restore old sessions. Background project execution and durable pending decisions continue independently. We built a correctly signed user-context helper using its own data protection Keychain access group and a nonsecret WhenUnlockedThisDeviceOnly item. Every call uses a fresh noninteractive LAContext and requests actual item data. In one user-confirmed stock screen lock/unlock test, reads returned errSecInteractionNotAllowed while locked and expected data after unlock. This is one observation, not a general screen-state contract. The installed EndpointSecurity SDK explicitly states that es_graphical_session_id_t is not an audit session ID. CoreGraphics public caller-session properties expose UID, on-console and login-done, but no documented lock-state/current ES graphical-session identifier. What supported API maps a caller Aqua user-context process or NSXPCConnection audit session to the relevant ES graphical_session_id? If none exists, what supported binding should a trusted user-context helper use for current graphical lock authority, including Fast User Switching and Screen Sharing contexts? Does a fresh successful macOS DP WhenUnlockedThisDeviceOnly data read imply that this graphical session is unlocked? How does the documented SSH path that unlocks the login Keychain and DP Keychain interact with a still-locked graphical session or another context of the same UID? Is there a supported coherent current-lock snapshot/subscription mechanism for initial startup or observer restart? What completeness, ordering and maximum latency contracts apply to userspace-produced ES LoginWindow lock events? Does any supported fence detect a final delayed/lost lock or a lock+unlock between two protected reads? Does any supported API bind the unlocked condition to a subsequent application control decision, such as an application-owned SQLite COMMIT? A receiver-side monotonic freshness check can reject late replies during coordinator stalls, but its final check and COMMIT remain separate operations. We seek a supported contract or OS-enforced mechanism for this boundary. We can conservatively revoke all broker control sessions on any trusted graphical lock instead of guessing an ASID→graphical-ID mapping, but this still leaves bootstrap/current-state and event completeness open. We have not assumed private CGSession keys, audit authentication flags, a helper heartbeat, or a queue-tail fence prove screen-unlocked state. Primary references: TN3137, SecItem: Pitfalls and Best Practices, ES graphical session ID, CG session dictionary, XPC audit session.
Replies
5
Boosts
0
Views
732
Activity
3d