On modern systems all KEXTs must be code signed with a Developer ID. Additionally, the Developer ID must be specifically enabled for KEXT development. You can learn more about that process on the Developer ID page. If your KEXT is having code signing problems, check that it’s signed with a KEXT-enabled Developer ID. Do this by looking at the certificate used to sign the KEXT. First, extract the certificates from the signed KEXT: % codesign -d --extract-certificates MyKEXT.kext Executable=/Users/quinn/Desktop/MyKEXT/build/Debug/MyKEXT.kext/Contents/MacOS/MyKEXT This creates a bunch of certificates of the form codesignNNN, where NNN is a number in the range from 0 (the leaf) to N (the root). For example: % ls -lh codesign* -rw-r--r--+ 1 quinn staff 1.4K 20 Jul 10:23 codesign0 -rw-r--r--+ 1 quinn staff 1.0K 20 Jul 10:23 codesign1 -rw-r--r--+ 1 quinn staff 1.2K 20 Jul 10:23 codesign2 Next, rename each of those certificates to include the .cer extension: % for i in codesign*; do mv $i $i.cer; done Finally, look at the leaf certificate (codesign0.cer) to see if it has an extension with the OID 1.2.840.113635.100.6.1.18. The easiest way to view the certificate is to use Quick Look in Finder. Note If you’re curious where these Apple-specific OIDs comes from, check out the documents on the Apple PKI page. In this specific case, look at section 4.11.3 Application and Kernel Extension Code Signing Certificates of the Developer ID CPS. If the certificate does have this extension, there’s some other problems with your KEXT’s code signing. In that case, feel free to create a new thread here on DevForums with your details. If the certificate does not have this extension, there are two possible causes: Xcode might be using an out-of-date signing certificate. Re-create your Developer ID signing certificate using the developer site and see if the extension shows up there. If so, you’ll have to investigate why Xcode is not using the most up-to-date signing certificate. If a freshly-created Developer ID signing certificate does not have this extension, you need to apply to get your Developer ID enabled for KEXT development per the instructions on the Developer ID page. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Change history: 20 Jul 2016 — First published. 28 Mar 2019 — Added a link to the Apple PKI site. Other, minor changes. 15 Mar 2022 — Fixed the formatting. Updated the section number in the Developer ID CPS. Made other minor editorial changes.

Hi Kevin, I need to revise my earlier assessment completely. I seriously underestimated what App Sandbox can do. My teammate Micha had already proven it. I am now officially outnumbered ;) I guess I'm getting too old for this shit. The only thing that doesn't work yet is formatting LUNs from within the app. It would be great to have this supported as well, just like with USB devices. For now we can live with it. We simply haven't found a suitable API for doing this inside the sandbox. If there is one, please let me know. Honestly, "Sandbox" is a serious understatement for what you built there. "SandOS" would fit much better ;) One example: we have now decoupled our processes with the sandbox. GUI and DEXT run separately. The GUI crashes? iSCSI keeps running. The DEXT crashes? It is back so fast that iSCSI doesn't even notice (!) Both crash? The DEXT recovers. iSCSI holds. The GUI stays closed. Once it is reopened, everything looks as if nothing had happened. Whatever happens in our stack, the storage connection stays intact as long as the OS is running. That is really incredible work by your teams. It opens up completely different possibilities for us. Thank you for challenging my assumption. Best regards, Torsten

Two field incidents show an _nstat_rwlock/UDP socket mutex ABBA deadlock followed by a configd watchdog panic. Raw wait-owner records and UUID-matched KDK stacks identify the same cycle in each incident's earlier configd diagnostic and later panic. Affected systems Both kernels: xnu-13432.1.9~1. Kernel UUIDs are in the attachments. Report AReport BmacOS27.0 (26A428)27.0.1 (26A434)HardwareMac16,10 / T8132Mac15,6 / T6030CloudShell PID87443906Blocked configd threadPID 341, TID 19794593PID 113, TID 309370Our NEDNSProxyProvider can capture CloudShell's DNS UDP traffic and forward it via a separate upstream socket. Provider flows and CloudShell sockets have separate lifetimes. Symptoms and reproduction During DNS UDP forwarding and flow/socket cleanup, CloudShell blocks in final socket close. configd's IPConfigurationAgentQueue blocks creating a UDP socket: a diagnostic is captured after 60 seconds without check-ins, followed by panic/restart after 180 seconds: userspace watchdog timeout: no successful checkins from configd (1 induced crashes) in 180 secondsExpected: socket close completes or returns an error. We have no deterministic reproducer, measured failure rate, or reconstructed per-flow close history. Direct lock-owner evidence Raw waitInfo records (mutex tokens are opaque): Report A, 26A428: thread 18691491: kernel mutex 0x61c831d7f38edbc3 owned by thread 19491850 thread 19491850: krwlock 0xfffffe000cb41730 for writing owned by thread 18691491 thread 19794593: krwlock 0xfffffe000cb41730 for writing owned by thread 18691491Report B, 26A434: thread 36984: kernel mutex 0x44aa649ef3095ae1 owned by thread 12555 thread 12555: krwlock 0xfffffe000ca01730 for writing owned by thread 36984 thread 309370: krwlock 0xfffffe000ca01730 for writing owned by thread 36984In each incident, the first two records form a cycle in both snapshots; the third is configd. All three threads are TH_WAIT / TH_UNINT. UUID-matched kernel stacks Caller-to-callee chains; listed offsets match in both kernels. Kernel worker (A: TID 18691491; B: TID 36984): nstat_idle_check + 808 -> in_pcb_checkstate + 128 -> udp_lock + 200 -> lck_mtx_lock_contended + 1212Holds _nstat_rwlock exclusively; waits for CloudShell's UDP socket mutex. CloudShell (A: TID 19491850; B: TID 12555): soclose + 212 -> soclose_locked + 2300 -> sofreelastref + 60 -> flow_divert_detach + 332 -> in_pcbdetach + 168 -> nstat_pcb_detach + 92 -> lck_rw_lock_exclusive + 180 -> lck_rw_lock_exclusive_gen + 912Holds the socket mutex; waits for _nstat_rwlock. XNU acquires these locks, not application code. configd (downstream victim): socket_common -> socreate_internal -> udp_attach -> nstat_udp_new_pcb -> lck_rw_lock_exclusivePossible enabling condition Matched 27 KDK disassembly shows a provider CLOSE path through cfil_sock_is_dead that directly marks the PCB DEAD and schedules GC without nstat cleanup. Public xnu-12377.121.6 (26.5) uses ordinary detach first. Provider CLOSE and final fd close are distinct. A DEAD PCB can retain an nstat locus/reference. Under _nstat_rwlock, nstat_idle_check removes the locus and releases the reference via in_pcb_checkstate(..., WNT_RELEASE, FALSE), which can take the socket mutex. Final close takes the reverse order; nstat_pcb_detach requests the nstat lock even when the locus is null. This is a possible enabling path from disassembly/source analysis, not proof of the preceding provider CLOSE in either incident. The older source already has opposite static lock orders; 26.5 is not proven immune. Questions for Apple Our provider calls closeReadWithError:nil and closeWriteWithError:nil when finished, as documented for NEAppProxyFlow. This does not validate the entire asynchronous lifecycle. Is this cycle known, and is there a fixed build? How is reverse locking avoided after the direct DEAD transition? Is there a supported workaround preserving flow cleanup? Close rate-limiting is not proven to eliminate the issue. Which diagnostics would help correlate provider CLOSE, DEAD, and final fd close? Attachments and timestamps Four EXCERPT attachments contain watchdog messages, raw frames, KDK annotations, and wait-owner records. Full reports are retained for private Feedback Assistant submission. 26A428_panic_excerpt.txt 26A428_configd_excerpt.txt 26A434_panic_excerpt.txt 26A434_configd_excerpt.txt 2026-10-15, +0800: configd capture -> embedded panic event: A: 04:24:43.1258 -> 04:26:44 B: 08:49:29.4349 -> 08:51:32 Use embedded panic times, not file/header timestamps. Original pairs match on boot identity; identifiers are omitted from excerpts. Sources: NEAppProxyFlow, XNU 26.5 comparison.

I'm looking into direct communication between a Mac and a Linux machine connected over Thunderbolt. Thunderbolt networking works fine, but I'd like to explore whether it's possible to transfer data using native Thunderbolt DMA, without going through the TCP/IP stack. I've looked through the IOKit and DriverKit documentation, but most of what I've found relates to drivers for PCIe devices connected over Thunderbolt rather than communication between two hosts. A couple of questions: Is there a supported API for discovering Thunderbolt XDomain services and establishing native DMA-backed send/receive paths between hosts? Can this be done from userspace or DriverKit, or would it require a kernel extension? Ideally, I'd also like to keep the existing Thunderbolt networking interface working alongside it. Any pointers to relevant APIs or documentation would be appreciated. Thanks!

I'm investigating repeated WindowServer watchdog kernel panics on a Mac mini M6 running macOS 27.0.1 (build 26A434), and would appreciate technical guidance on identifying the initiating failure. System configuration Mac mini M6, 16 GB unified memory macOS 27.0.1 (26A434) Redmi G Pro 27U external monitor Physical output: 3840 × 2160 @ 160 Hz, RGB 10-bit HDR10 USB-C-to-DisplayPort 1.4 direct connection, HBR3 ×4, DSC enabled Similar system-level crashes have occurred over both HDMI and DisplayPort The system has experienced repeated freezes and forced restarts over several days. Kernel panic signature userspace watchdog timeout: no successful checkins from WindowServer in 120 seconds WindowServer initialization not complete (post IOKitWaitQuiet)Some WindowServer recovery diagnostics involve IOMobileFramebuffer and IOMobileGraphicsFamily-DCP. Latest incident: October 24, 2026 (UTC+08:00) At 01:33:25.578, the unified log began recording repeated messages: DCPEXT1:GMailboxHandler.cpp:232 apt firmware: immediate_swap_denied landed frame_id = 1, reason = 1At 01:33:35.612, WindowServer reported: [Watchdog] display 1 has become stuck after 10.00154s of unreadiness (2463 failures)Approximately 14,264 immediate_swap_denied messages were recorded in the retrieved interval ending at 01:34:55, followed by a system restart around 01:35. The corresponding panic report is: panic-full-2026-10-24-013618.0002.panic What I have checked The failures are not limited to one video connection type. The physical display signal is 4K 160 Hz, not 5K 160 Hz. The 5120 × 2880 value reported by HiDPI utilities represents the internal scaling buffer. Crashes occurred before BetterDisplay was first used. The latest incident occurred while viewing a remote desktop stream, but available process-count samples did not reveal proliferation of the remote-control processes. Memory/resource pressure remains under investigation; there is not enough evidence to attribute the panics to memory exhaustion. It is unclear whether the initial WindowServer stall precedes or follows the DCP frame-swap errors. Questions What does immediate_swap_denied with frame_id=1, reason=1 indicate in the Apple DCP display pipeline? Can this error be a downstream symptom of an already-stalled WindowServer, or does it suggest a DCP/display frame-submission failure? Is there a known macOS 27 issue involving WindowServer watchdog failures or recovery stalls in IOMobileGraphicsFamily-DCP? What additional diagnostics would help distinguish a macOS display firmware/driver problem from external-display compatibility, memory pressure, or defective hardware? I can provide the panic report, WindowServer diagnostic samples, relevant unified-log extracts, display configuration information, and a sysdiagnose through Feedback Assistant. Feedback Assistant report: FB25300098 Any guidance from Apple DTS engineers or developers who have encountered a similar DCP/WindowServer failure would be appreciated.

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.

Hello, does anyone know how to permanently disable the built‑in display in macOS 15 on iMac M1 programmatically or via the terminal? I’m facing a problem — the display cable is broken. As a result, not only does it work poorly, but there’s also severe overheating in the upper right part of the iMac. The warranty has expired, and I don’t have the funds to replace the display right now. So I’m looking for ways to disable the built‑in screen and work only with an external display. At the moment, I’ve found a way to disable the display after logging in, but before logging in, the screen gets hot, and in this mode I won’t be able to upgrade to the new operating system. The process is lengthy, and the screen will become significantly hot. Ideally, the built‑in display should be disabled during reboot and when upgrading to a new version of macOS, and an external display should be used as the main display.

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.

Hello, I'm evaluating a local macOS helper service with a minimum deployment target of macOS 13. The service would communicate over an AF_UNIX SOCK_STREAM socket and must authenticate the signed code identity of the connecting process before accepting an operation. I'm investigating whether LOCAL_PEERTOKEN can provide a reliable audit token associated with the peer of an accepted socket. The public macOS SDK declares LOCAL_PEERTOKEN in sys/un.h, but I haven't found documentation establishing its precise security guarantees or availability across supported macOS versions. My questions are: Is LOCAL_PEERTOKEN a public, supported API on macOS 13 and later? Can it be used with getsockopt() on a file descriptor returned by accept() to retrieve an audit_token_t for the connected peer? At what point is the peer identity captured? Is the returned audit token securely bound to the original connecting process, even if that process exits and its PID is reused? Is the audit token obtained through LOCAL_PEERTOKEN officially supported as input to Security.framework APIs such as SecCodeCopyGuestWithAttributes (using kSecGuestAttributeAudit) or SecTaskCreateWithAuditToken? Does the identity remain trustworthy if the connected socket descriptor is inherited or passed to another process? Are there documented limitations concerning descriptor passing or time-of-check/time-of-use races? What is Apple's recommended public API sequence for verifying the signed code identity of an AF_UNIX peer on macOS 13+, including in an App Sandbox environment? I'm looking for documented security and availability guarantees rather than relying solely on observed behavior. Thank you!

We're seeing a recurring kernel panic across six Mac17-family Macs (Mac17,2 / Mac17,4 / Mac17,8; T8142 and T6050) in a managed fleet. 34 panic logs collected 30 Sept – 9 Oct, all with the same signature: panic(cpu N caller ...): Kernel tag check fault (expected tagged address: 0x...028), esr 0x96000011 Faulting address is always at offset 0x28 of the object Same crash PC per build: kernel text exec base + 0x48da38 on 27.0/27.0.1, + 0x46a784 on 26.7, + 0x466ee0 on 26.5 Panicked task is "Google Chrome Helper" in all 34 cases, thread Chrome_ChildIOThread (Chrome's IPC/network I/O thread) Always 3–60 s after wake from sleep, usually a dark wake with the lid closed (overnight or after a 3–18 min sleep) No third-party kexts loaded; "Post-boot loaded kexts" lists only Apple drivers Affected builds: 26.5 (25F71), 26.7 (25G229), 27.0 (26A428), 27.0.1 (26A434). Not a regression from one update: a machine still on 26.5 panics identically. Only Mac17-family hardware is affected. Older Apple silicon Macs with the same software stack are fine. Present on every affected machine: Chrome PWAs (Gmail/Chat/Meet) running in the background, keeping Chrome's network service alive across sleep. On one machine Microsoft Edge is the primary browser and never panics; only Chrome Helper does. Microsoft Defender for Endpoint with its network filter (content filter) extension, MDM-managed. This looks related to thread 821372, where DTS described a kernel networking panic on M5-family hardware with a Network Extension present (r.172793638 / FB22401652), fixed in 26.5b2. We appear to be seeing a tag-check-fault variant on 26.5 release and later. Questions: Is this a known issue, and is it the same root cause as r.172793638? Is there a build where it's fixed? Any recommended mitigation beyond preventing sleep and quitting Chrome? Feedback Assistant: FB25128015 with panic logs and sysdiagnose. Happy to collect more data or test a build. Backtrace from a 27.0.1 panic (kernel text exec base 0xfffffe003aa54000), panic PC first: lr: 0xfffffe003aee1a38 lr: 0xfffffe003aeec580 lr: 0xfffffe003b12cf34 lr: 0xfffffe003b12dc50 lr: 0xfffffe003b07b1f8 lr: 0xfffffe003b07c758 lr: 0xfffffe003b237ff4 lr: 0xfffffe003ac787f0 lr: 0xfffffe003aa576ac lr: 0x000000018747a57c (userspace)

I've noticed that when an SMB link stalls, in a scenario such as a time machine network backup, due to any cause (NAS disk or network sleep, Wi-Fi roam/drop), in-flight SMB I/O blocks uninterruptibly instead of completing or returning an error. This unfortunately leaves APFS with outstanding I/O against a backing store that will neither finish nor fail. This results in any sort of network stall turning into a kernel panic, since nothing in the I/O path enforces a timeout or error return. I've experienced this since Sequoia, and is still present in Golden Gate. I'm sure if this is the best place to post this, but I have not been able to find a workaround to-date to prevent this from consistently happening. When I open my MacBook in the morning there's a 50/50 chance that it kernel panicked overnight. I also filed a feedback (FB24460131), but have heard no response.

We have started seeing some unexplained behavioural differences in the BSD socket APIs on macos 26.6.x and macos 27. On a different front, there also seems to be some changes in the ptrace area for PT_DETACH. Historically, the release notes of macos don't include any mention of such changes. And unfortunately, prior experience of filing feedback assistant issues too hasn't been very motivating due to lack of any response on those tickets. These forums have been very helpful in trying to understand some of these changes, and I plan to raise separate topics for the issues shortly. In the past, the other useful option I have used is reading up the kernel sources published at https://opensource.apple.com/releases/. But there hasn't been any updates for macos 26.6 or macos 27. It will be very useful if macos 26.6 and 27 releases are published there. That will help expedite investigating some of these failures. BSD socket APIs in the recent releases of macos have seen several issues (feedback assistant issues have been filed). The implications of these failures is that we (in OpenJDK) have had to disable several tests on recent versions of macos which has reduced the test coverage and reliability of these very primitive networking APIs on this platform.

After scouring the XNU kernel source code, I came across restartable ranges [1]. They seem to be a task-level version of the the part of Linux's restartable sequences [2] for user requested synchronization [3] (akin to MEMBARRIER_CMD_RSEQ). Because of their differences, I would like to know more about how they work and what they are used for. From what I have gathered [4], they seem to be closer to RCU [5] that waits for eviction (as opposed to completion). But the fact that they are barely mentioned anywhere (see [4]) in the XNU source code I'd be really happy if you can point me to more information about them and how they compare to rseq (or rcu). What are the XNU devs planning on doing with them? [1] osfmk/kern/restartable.c: https://github.com/apple-oss-distributions/xnu/blob/f6217f8/osfmk/kern/restartable.c [2] https://criu.org/Restartable_Sequences [3] as opposed to (what I think is what makes rseq really cool) automatic eviction on preemption/CPU migration [4] there seems to be very little information online (including this forum) and the only places inside the XNU kernel source trees that aren't tests are in osfmk/kern/{thread,thread,sched_prim}.{c,h}, which doesn't really give much more information. [5] Read-Copy-Update: https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html

On macos 27, there appears to be a change in the setsockopt() implementation for the SO_LINGER option. It looks like the implementation now imposes a different maximum limit on the value that is accepted for linger. Consider the trivial attached C program. Rename it from main.c.txt to main.c. Compiling it (using clang main.c) and running it (using ./a.out), on older versions of macos (like 26.x), it returns: ----------------------- MacOS version: 26.7.1 Kernel version: Darwin Kernel Version 25.6.0: Tue Aug 18 17:49:13 PDT 2026; root:xnu-12377.161.15.700.19~2/RELEASE_ARM64_T6000 ----------------------- SUCCESS - set SO_LINGER to value 10 SUCCESS - set SO_LINGER to value 42 SUCCESS - set SO_LINGER to value 1024 SUCCESS - set SO_LINGER to value 32767 SUCCESS - set SO_LINGER to value 32768 SUCCESS - set SO_LINGER to value 65535 SUCCESS - set SO_LINGER to value 65536 SUCCESS - set SO_LINGER to value 65578 However, on macos 27, this now fails with EDOM error ("Numerical argument out of domain") for values greater than 32767: ----------------------- MacOS version: 27.0.1 Kernel version: Darwin Kernel Version 27.0.0: Tue Aug 11 21:02:16 PDT 2026; root:xnu-13432.1.9~1/RELEASE_ARM64_T8112 ----------------------- SUCCESS - set SO_LINGER to value 10 SUCCESS - set SO_LINGER to value 42 SUCCESS - set SO_LINGER to value 1024 SUCCESS - set SO_LINGER to value 32767 FAILURE - failed to set SO_LINGER to value 32768, reason: Numerical argument out of domain FAILURE - failed to set SO_LINGER to value 65535, reason: Numerical argument out of domain FAILURE - failed to set SO_LINGER to value 65536, reason: Numerical argument out of domain FAILURE - failed to set SO_LINGER to value 65578, reason: Numerical argument out of domain I'm guessing this is an intentional change, but I wanted to confirm nonetheless. Should the documentation of SO_LINGER and SO_LINGER_SEC socket options, in man setsockopt, mention the acceptable value range for them? main.c.txt

Please consider the trivial C program attached to this thread. The code creates a socket() and listen()s for connections, but (intentionally) doesn't accept() the connections. The listen() is done using a small backlog (of 1). This test then does several connect() attempts and expects that the connect() attempts will accumulate in the pending queue and once the queue exceeds the backlog limit, then as specified in man listen: The backlog parameter defines the maximum length for the queue of pending connections. If a connection request arrives with the queue full, the client may receive an error with an indication of ECONNREFUSED. then the connect() attempt will receive a ECONNREFUSED. However, in macos 27, such a connect() attempt leads to ECONNRESET (Connection reset by peer) instead of ECONNREFUSED. Is this expected? Experiments show that prior versions of macos were returning a ETIMEDOUT for such connect() attempts. If this new error is expected from connect() when the backlog limit has exceeded, should it be specified in the man listen documentation? Rename the attached main.c.txt to main.c. Compiling the attached program on macos 27, using clang main.c and then running ./a.out results in: ----------------------- MacOS version: 27.0.1 Kernel version: Darwin Kernel Version 27.0.0: Tue Aug 11 21:02:16 PDT 2026; root:xnu-13432.1.9~1/RELEASE_ARM64_T8112 ----------------------- started server at at 127.0.0.1:52753 with a backlog of 1 connect() attempt 1 - connected connect() attempt 2 - connected connect() attempt 3 - connected connect() attempt 4 - connected connect() attempt 5 - failed to connect() - Connection reset by peer <-- FAILURE: Unexpected error code, expected either ETIMEDOUT or ECONNREFUSED but got 54 connect() attempt 6 - connected connect() attempt 7 - connected connect() attempt 8 - connected connect() attempt 9 - failed to connect() - Connection reset by peer <-- FAILURE: Unexpected error code, expected either ETIMEDOUT or ECONNREFUSED but got 54 connect() attempt 10 - failed to connect() - Connection reset by peer <-- FAILURE: Unexpected error code, expected either ETIMEDOUT or ECONNREFUSED but got 54 connect() attempt 11 - failed to connect() - Connection reset by peer <-- FAILURE: Unexpected error code, expected either ETIMEDOUT or ECONNREFUSED but got 54 On a related note, it's unclear why several of the connect() attempts succeeded instead of just 1 of them succeeding. On prior versions of macos, the output of the same program is: ----------------------- MacOS version: 26.7.1 Kernel version: Darwin Kernel Version 25.6.0: Tue Aug 18 17:49:13 PDT 2026; root:xnu-12377.161.15.700.19~2/RELEASE_ARM64_T6000 ----------------------- started server at at 127.0.0.1:52451 with a backlog of 1 connect() attempt 1 - connected connect() attempt 2 - failed to connect() - Operation timed out connect() attempt 3 - failed to connect() - Operation timed out connect() attempt 4 - failed to connect() - Operation timed out connect() attempt 5 - failed to connect() - Operation timed out connect() attempt 6 - failed to connect() - Operation timed out connect() attempt 7 - failed to connect() - Operation timed out connect() attempt 8 - failed to connect() - Operation timed out connect() attempt 9 - failed to connect() - Operation timed out connect() attempt 10 - failed to connect() - Operation timed out connect() attempt 11 - failed to connect() - Operation timed out and this output is much more understandable and deterministic. main.c.txt

I am able to symbolicate kernel backtraces for addresses that belong to my kext. Is it possible to symbolicate kernel backtraces for addresses that lie beyond my kext and reference kernel code? Sample kernel panic log

My custom filesystem kernel extension stores ACLs as an extended attribute, com.apple.system.Security. Sanboxed apps such as TextEdit, Pages, etc., running as a non-privileged process, fail to save modified contents when permissive ACLs are in use. Running them as a privileged process, does allow for file changes to be saved though. Non-sandboxed apps, such as VSCode, and command line programs are not susceptible to this behaviour. APFS, on the other hand, seems to handle ACLs as an ATTR_CMN_EXTENDED_SECURITY filesystem attribute, rather than as an EA. In this case, sandboxed apps have no trouble accessing the ACL data. I implemented a minimal PoC within my custom kext to verify this. I construct an ACL in memory allowing a given user to write,append,delete file contents, and return it that via vnop_getattr. This allows the file contents to be modified and saved by sandboxed apps. Can you please confirm if my findings are accurate and sandboxed apps fail to read the com.apple.system.Security EA by design? Also, Is it an accurate assumption, that ACLs should be handled either as an EA, or an ATTR_CMN_EXTENDED_SECURITY, but not both? Thanks.

As part of the OpenJDK testing we run several regression tests, including for Java SE networking APIs. These APIs ultimately end up calling BSD socket functions. On macos, starting macos 26, including on recent 26.2 version, we have started seeing some unexplained but consistent exception from one of these BSD socket APIs. We receive a "ENOBUFS" errno (No buffer space available) when trying to construct a socket(). These exact same tests continue to pass on many other older versions of macos (including 15.7.x). After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached): #include <stdio.h> #include <sys/socket.h> #include <string.h> #include <unistd.h> #include <sys/errno.h> static int create_socket(const int attempt_number) { const int fd = socket(AF_INET6, SOCK_STREAM, 0); if (fd < 0) { fprintf(stderr, "socket creation failed on attempt %d," " due to: %s\n", attempt_number, strerror(errno)); return fd; } return fd; } int main() { const unsigned int num_times = 250000; for (unsigned int i = 1; i <= num_times; i++) { const int fd = create_socket(i); if (fd < 0) { return -1; } close(fd); } fprintf(stderr, "successfully created and closed %d sockets\n", num_times); } The code very trivially creates a socket() and close()s it. It does this repeatedly in a loop for a certain number of iterations. Compiling this as: clang sockbufspaceerr.c -o sockbufspaceerr.o and running it as: ./sockbufspaceerr.o consistently generates an error as follows on macos 26.x: socket creation failed on attempt 160995, due to: No buffer space available The iteration number on which the socket() creation fails varies, but the issue does reproduce. Running the same on older versions of macos doesn't reproduce the issue and the program terminates normally after those many iterations. Looking at the xnu source that is made available for each macos release here https://opensource.apple.com/releases/, I see that for macos 26.x there have been changes in this kernel code and there appears to be some kind of memory accountability code introduced in this code path. However, looking at the reproducer/application code in question, I believe it uses the right set of functions to both create as well as release the resources, so I can't see why this should cause the above error in macos 26.x. Does this look like some issue that needs attention in the macos kernel and should I report it through feedback assitant tool?

I’m trying to determine whether this is a known macOS/firmware issue, a hardware issue, or something else in the Apple-silicon sleep/power-management path. Hardware / software: MacBook Pro 14-inch (Nov 2023), M3 Pro Model identifier: Mac15,6 11-core CPU, 14-core GPU, 18 GB RAM macOS Tahoe 26.6.2 (25G83) SoC T6030, revision 11 iBoot / firmware: mBoot-18000.161.10 Symptom: The Mac intermittently performs a full reset/reboot while the lid is closed and it should be asleep. I usually discover this when I open the lid and find that the machine has rebooted rather than waking normally. A particularly disruptive aspect is that this happens when I transport the Mac while the lid is closed. If I put the sleeping MacBook in a backpack and carry it, or even simply carry it in my hands with the lid closed, I can later find that it has reset (the startup sound plays) and booted to the startup disk selection / startup options screen instead of remaining asleep. This behavior makes normal closed-lid transport unreliable. The correlation with movement while the lid is closed is one of the reasons I initially suspected something involving the lid sensor, sleep-state handling, or another hardware/power-management component. However, I can also reproduce the reset with the computer completely stationary on a desk, so physical movement is not required to trigger the failure. The failure is strongly correlated with clamshell sleep/dark-wake transitions. It can happen shortly after closing the lid or several minutes later. This is not just an application crash. Multiple reproductions have generated ResetCounter reports and PMU watchdog/reset fault data. Most recent reproduction (verified Safe Mode): I booted using Apple-silicon Safe Mode and personally verified that “Safe Boot” was displayed before testing. I then closed the lid normally and left the Mac alone. It rebooted after a few minutes, while the lid was closed. Immediately afterward macOS created a new type-115 ResetCounter report. Relevant fields: Boot failure count: 1 Boot faults: rst btn_rst,btn_seq_reset target_off_shutdown Boot stage: 0x40 socId: 6030 socRevision: 11 DumpPanic then read auxiliary PMU fault data containing: wdog,reset_in_1 rst_in,reset_in_1_deassert During the same boot, the AppleSPMIPMU driver logged: rst crash,crash_in wdog,reset_in_1 rst_in,reset_in_1_deassert and another PMU entry contained the same sequence plus: rst btn_rst,btn_seq_reset target_off_shutdown I am not assuming undocumented meanings for every PMU flag. For example, I am not treating btn_rst as proof that a physical power button was pressed. The important point is that the same low-level watchdog/reset pattern has occurred repeatedly. Also, DumpPanic successfully read 3,145,728 bytes from the panic area, but reported: it did not contain any paniclog data (buffer was all zeros) No paniclog data found in local device So there is no normal surviving kernel panic report to inspect. Earlier controlled reproduction after reinstalling macOS: I performed an in-place reinstall of macOS from Recovery. The machine was confirmed to be running 26.6.2 (25G83) afterward. Immediately after the reinstall I ran another controlled test while recording kernel/powerd/powerexperienced/DumpPanic logs. I closed the lid once and did not touch the machine. The logs showed a normal physical close sequence: SMC HID Event: 03 01 00 PMRD: Clamshell closed clamshell closed 1 sleep reason Clamshell Sleep macOS then entered the clamshell sleep path. Shortly afterward it transitioned from dark wake to full wake due to HID activity, even though I had not physically reopened the lid. A corresponding low-level Clamshell opened event was not present in the captured stream, and the kernel continued to report: clamshell closed 1 It then attempted clamshell sleep again and entered dark wake with: DarkWake: sleepASAP 1, clamshell closed 1 The machine later reset. On the following boot a new ResetCounter reported Boot failure count: 1, and the auxiliary PMU fault data again contained: wdog,reset_in_1 rst_in,reset_in_1_deassert The kernel PMU log also contained crash,crash_in. DumpPanic again read 3,145,728 bytes and found the panic buffer all zeros. There was another earlier controlled reproduction with the same PMU watchdog/reset class, so this is not a single isolated event. Lid-angle / clamshell testing: I separately monitored the low-level lid events while deliberately opening and closing the display. Normal physical movements produced coherent pairs such as: SMC HID Event: 03 01 00 / PMRD: Clamshell closed and: SMC HID Event: 03 00 01 / PMRD: Clamshell opened I did not observe simple spontaneous open/close flickering while the display was stationary. This does not completely rule out an intermittent lid sensor/flex/magnet issue, but it does not look like a straightforward continuously-failing lid sensor. Other troubleshooting: Apple Diagnostics reports no issues. The issue survived an in-place macOS Recovery reinstall. The issue reproduces in verified Safe Mode. I have not found a conventional kernel panic payload for these failures. I am not attributing the issue to Wi-Fi, Bluetooth, Chrome, ANE, or any other subsystem based only on incidental log messages. Previous Apple repair: Earlier this year Apple serviced the machine for the same exact symptoms. The service summary says the following parts were replaced: Logic board — symptom category: System Startup/Stability/Unexpected Restart/Shutdown Lid Angle Sensor — symptom category: System Startup/Stability/Will Not Sleep Touch ID board MagSafe 3 board The same closed-lid reset problem continues after that repair. What I’m trying to understand: Is this PMU watchdog/reset pattern known on M3 Pro / T6030 systems during clamshell sleep or dark wake? Are there specific sysdiagnose, power-management, PMU, or firmware logs that would be useful to Apple engineering? Would a DFU firmware Revive be a meaningful next isolation step given that Recovery reinstall, Safe Mode, diagnostics, and a prior logic-board/lid-sensor replacement have not resolved it? I can provide sanitized ResetCounter output and relevant unified-log excerpts. I have intentionally omitted serial numbers, repair identifiers, CrashReporter keys, account information, and other identifying details here.

I am porting Wine to macOS to run Windows on ARM (WOA) binaries. Windows PE files place .text and .data in the same page, which macOS’s JIT/W^X model cannot handle. pthread_jit_write_protect_np() cannot be used for foreign ARM64 code. Apple Silicon reserves x18, breaking the Windows ARM64 ABI. Wine also must reserve 0x7FFE0000 for the Windows TEB, but macOS cannot guarantee this address. These issues make it impossible for Wine to load or execute WOA binaries. I am requesting mechanisms to safely execute foreign ARM64 code, support mixed W/X pages, emulate x18, and reserve the Windows TEB region. Branch is here: https://github.com/trcrsired/wine/tree/apple-silicon-mac-woa