15 ms·

Apple’s Darwin OS and XNU Kernel Deep Dive

485 points by tansanrao 1y ago

ladyanita22 1y ago
I'm a bit disappointed at the lack of interest Apple seems to have on Rust, given their focus on performance, UX and security.
- pjmlp 1y ago
  They created Swift as replacement for C, C++ and Objective-C, why should they bother with Rust? Even Google on Android and ChromeOS is not exposing Rust to userspace, Java, Kotlin, C, C++, Javascript, Typescript, remain the official userspace languages.
  - ladyanita22 1y ago
    Low-level code is being written in Rust. Of course userspace doesn't require low-level languages (and I don't quite get why C and C++ are exposed to the userspace and Rust is not). Swift is not a replacemente for C and C++, but rather for Objective-C. Do you have any sources for those claims?
    - pjmlp 1y ago
      Yes, Apple themselves, apparently folks wanting Apple to use Rust don't read Apple's documentation or watch talks done by Apple compiler developers. > Swift was designed from the outset to be safer than C-based languages, and eliminates entire classes of unsafe code. -- https://www.swift.org/about/ https://www.swift.org/about/ > Swift is a successor to the C, C++, and Objective-C languages. It includes low-level primitives such as types, flow control, and operators. It also provides object-oriented features such as classes, protocols, and generics. -- https://developer.apple.com/swift/ https://developer.apple.com/swift/ "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw "So we feel pretty strongly, obviously at Apple our sucessor language is Swift and I am here to talk about features of Swift, both to try to sell you on to it, but also to talk about the things we think are pretty necessary and the ways in which a programming language can support, you know, clear code, safer and more correct code." "Like I said before, Apple has always intended for Swift to be a sucessor language for all of our predecessors, from the top to the bottom of our stack, accessible to novices, powerful enough for experts, it is real a tall order. From https://youtu.be/lgivCGdmFrw?t=1996 https://youtu.be/lgivCGdmFrw?t=1996 to https://youtu.be/lgivCGdmFrw?t=2042 https://youtu.be/lgivCGdmFrw?t=2042 "Swift as C++ Successor in FoundationDB" https://www.youtube.com/watch?v=ZQc9-seU-5k https://www.youtube.com/watch?v=ZQc9-seU-5k
      - ladyanita22 1y ago
        Oh, you seem to be right. But isn't Swift lower-performing than C, C++ or Rust?
        pjmlp 1y ago
        Not only does Metal use Swift bindings alongside Objective-C, as per John McCall's own words, that is the plan and to fix where that might still not be the case. Embedded Swift project also started as means to replace Safe C use cases at Apple, like iBoot firmware. https://support.apple.com/en-jo/guide/security/sec30d8d9ec1/web https://support.apple.com/en-jo/guide/security/sec30d8d9ec1/... https://github.com/swiftlang/swift-evolution/blob/main/visions/embedded-swift.md https://github.com/swiftlang/swift-evolution/blob/main/visio... Once upon a time, C compilers were quite lousy versus handwritten 8 and 16 bit Assembly code.
    - ramesh31 1y ago
      >Swift is not a replacemente for C and C++, but rather for Objective-C. Swift is not a replacement for anything; Apple will even say as much. It just fills the hole for a scripting language that they had for decades. Plenty of new Obj-C is still (and will continue to be) written for a long time.
- melodyogonna 1y ago
  I believe their plan is to make Swift good enough to use in high-performance low-level scenarios. Some of their recent work has been to reduce implicit copies
deleted 1y ago
[deleted]
whalesalad 1y ago
I’ve been wanting to understand Darwin at this depth for a long time. Great read!
- tansanrao 1y ago
  It’s my first time condensing my research notes into a blog post like this, glad you liked it!
  - ForOldHack 1y ago
    It was easily comprehensive enough, that I printed it out and was showing people today what the differences were in the last couple of os releases, while ruminating about snow leopard. No one mentions that the blue box became Rosetta, and Rosetta II did the same thing in the switch from Intel to ARM. There are some very tiny points, but this is easily very best to date. ( I started with Rhapsody, and Linux in swedish, and NT 3.1 )( Ran MKLinux on a 7100, but never got accelerated video to work. )
    - ForOldHack 1y ago
      I should add, I have never seen accelerated video in Linux, except for built in Intel video and it's fine.
- jshier 1y ago
  Mac OS X Internals by Singh is one of my favorite books, such a great in depth examination of Mac OS X circa 10.4. I really wish there was an updated version. Edit: I see it's even cited at the end of this article. Truly a source for the (macOS) ages.
  - wpm 1y ago
    Jonathan Levin’s three part series “*OS Internals” is that update, but they stopped working on and writing about Darwin around Catalina.
- kccqzy 1y ago
bch 1y ago
> Mach’s virtual memory (VM) system was influential beyond the project – it was adopted by 4.4BSD and later FreeBSD as their memory management subsystem. …and NetBSD[0], OpenBSD[1], but apparently not DragonFly BSD[2]. [0] https://netbsd.org/docs/kernel/uvm.html https://netbsd.org/docs/kernel/uvm.html [1] https://man.openbsd.org/OpenBSD-3.0/uvm.9 https://man.openbsd.org/OpenBSD-3.0/uvm.9 [2] https://www.dragonflybsd.org/mailarchive/kernel/2011-04/msg00034.html https://www.dragonflybsd.org/mailarchive/kernel/2011-04/msg0...
- tansanrao 1y ago
  Ohhh interesting! I’ll update the post to include this soon, thanks!
- inkyoto 1y ago
  Sadly, that is not entirely correct. Whilst all three BSDs (386BSD, FreeBSD, and NetBSD; there was no OpenBSD in the beginning) did inherit the legacy Mach 2.5-style design, it did not live on in FreeBSD, whose core team started pretty quickly replacing all remaining vestiges of the Mach VM[0] with a complete, modern, and highly performant rewrite of the entire VM. FreeBSD 4 had none of the original Mach code left in the kernel codebase, and that happened in the late 1990s. Therefore, FreeBSD can't be referenced in a relationship to Mach apart from the initial separation/very early foundation stage. NetBSD (and OpenBSD) went on for a while but also quickly hit the wall with the Mach design (performance, SMP/scalability, networking) and also set out on a complete rewrite with UVM (unified virtual memory) designed and led by Chuck Cranor, who wrote his dissertation on the UVM. OpenBSD later borrowed and adopted the UVM implementation, which remains in use today. So out of all living BSD's[1], only XNU/Darwin continues to use Mach, and not Mach 2.5 but Mach 3. There have been Mach 2.5, 3 and 4 (GNU/Hurd uses Mach 4) in existence, and the compatibility between them is rather low, and remains mostly at the overall architectural level. They are better to be treated as distinct design with shared influence. [0] Of which there were not that many to start off with. [1] I am not sure whether DragonBSD is dead or alive today at all.
  - o11c 1y ago
    > I am not sure whether DragonBSD is dead or alive today at all. It seems to have about the same level of activity as NetBSD. Take that how you will.
swatson741 1y ago
Whenever I see the Darwin kernel brought into the discussion I can't help but wonder how different things could have been if Apple had just forked Linux and ran their OS services on top of that. Especially when I think about how committed they are to Darwin it really paints a poor image in my mind. The loss that open source suffers from that, and the time and money Apple has to dedicate to this with a disproportionate return.
- skissane 1y ago
  > Whenever I see the Darwin kernel brought into the discussion I can't help but wonder how different things could have been if Apple had just forked Linux XNU is only partially open sourced – the core is open sourced, but significant chunks are missing, e.g. APFS filesystem. Forking Linux might have legally compelled them to make all kernel modules open source–which while that would likely be a positive for humanity, isn't what Apple wants to do
  - mattl 1y ago
    At one point NeXT considered distributing GCC under the GPL with some proprietary parts linked at first boot into the binary. Stallman after speaking with lawyers rejected this. https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Why-CLISP-is-under-GPL https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Wh... Look for "NeXT" on this page.
    - leoh 1y ago
      Stallman’s insistence that a judge would side with him is pretty arrogant in my opinion; eg looking at Oracle v. Google decades later and how folks deciding the case seemed to be confused about technical matters.
      - skissane 1y ago
        I don't think it was "arrogant" – if you read the link, he explains that he originally thought differently, but he changed his mind based on what his lawyer told him. I don't think you can label a non-lawyer "arrogant" for accepting the legal advice of their own attorney – whether that advice is correct or not can be debated, but it isn't arrogant for someone to trust the correctness of their own lawyer's advice.
emchammer 1y ago
Couldn't Apple have used ZFS instead of inventing APFS? Maybe modifying it to use less physical memory?
- inkyoto 1y ago
  Supporting ZFS in a UNIX kernel requires excessively extensive modifications to the design and implementation of the VMM, namely: 1. Integration of the kernel's VM with ZFS's adaptive replacement cache which runs in user space – memory pressure cooperation, page accounting and unified memory management. It also requires extensive VM modifications to support ZFS's controlled page eviction, fine-grained dirty page tracking, plus other stuff. 2. VMM alignment with the ZFS transactional semantics and intent logs – delayed write optimisations, efficient page syncing. 3. Support for large memory pages and proper memory page alignment – support for superpages (to reduce the TLB pressure and to efficiently map large ZFS blocks efficiently) and I/O alignment awareness (to ensure proper alignment of memory pages to avoid unnecessary copies). 4. Memory-mapped I/O: different implementation of mmap and support for lazy checksumming for mmap pages. 5. Integration with kernel thread management and scheduling, co-opertation with VMM memmory allocators. 6. … and the list goes on and on. ZFS is just not the right answer for consumer facing and mobile/portable devices due being a heavyweight server design with vastly different design provisions and due to being the answer to a entirely different question.
  - AndrewDavis 1y ago
    > Supporting ZFS in a UNIX kernel requires excessively extensive modifications to the design and implementation of the VMM, namely: FYI: Apple did a bunch of that work. They ported ZFS to OSX shortly after it was open sourced. With with only support landing in 10.5. With it being listed as an upcoming feature in 10.6. But something happened and they abandoned it. The rumour is a sun exec let the cat out of the bag about it being the next main filesystem for osx (ie not just support for non root drives) and this annoyed Jobs so much he canned the whole project.
    - lunarlull 1y ago
agentkilo 1y ago
The article states that "pager daemons" that manage swap files runs in user space, and the kernel memory can also get swapped out, but never explained how a user space daemon swaps out kernel memory. Do they have hard-coded exceptions for special daemons, or use special system calls? Where can I find out more details about the user space memory management specifically?
- jjtheblunt 1y ago
  https://github.com/apple-oss-distributions/xnu https://github.com/apple-oss-distributions/xnu
- comex 1y ago
  The claim is inaccurate and mixes together multiple different things: - The Mach microkernel originally supported true userland paging, like mmap but with an arbitrary daemon in place of the filesystem. You can see the interface here: https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/memory_object_data_request.html https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/memory_... But I'm not sure if Darwin ever used this functionality; it certainly hasn't used it for the last ~20 years. - dynamic_pager never used this interface. It used a different, much more limited Mach interface where xnu could alert it when it was low on swap; dynamic_pager would create swap files, and pass them back into the kernel using macx_swapon and macx_swapoff syscalls. But the actual swapping was done by the kernel. Here is what dynamic_pager used to look like: https://github.com/apple-oss-distributions/system_cmds/blob/171b4c816e8aee4f16d85d080d0de154e4678e0f/dynamic_pager.tproj/dynamic_pager.c https://github.com/apple-oss-distributions/system_cmds/blob/... But that functionality has since moved into the kernel, so now dynamic_pager does basically nothing: https://github.com/apple-oss-distributions/system_cmds/blob/main/dynamic_pager/dynamic_pager.c https://github.com/apple-oss-distributions/system_cmds/blob/... - The vast majority of kernel memory is wired and cannot be paged out. But the kernel can explicitly ask for pageable memory (e.g. with IOMallocPageable), and yes, that memory can be swapped to disk. It's just rarely used. Still, any code that does this needs to be careful to avoid deadlocks. Even though userland is no longer involved in "paging" per se, it's still possible and in fact common for userland to get involved one or two layers down. You can have userland filesystems with FSKit (or third-party FUSE). You can have filesystems mounted on disk images which rely on userland to convert reads and writes to the virtual block device into reads and writes to the underlying dmg file (see `man hdiutil`). You can have NFS or SMB connections going through userland networking extensions. There are probably other cases I'm not thinking of. EDIT: Actually, I may be wrong about that last bit. You can definitely have filesystems that block on userspace, but it may not be supported to put swap on those filesystems.
fithisux 1y ago
They should have fostered a better FOSS community around XNU, now that they moved to ARM there should have been a runnable distribution for x64
larusso 1y ago
I’m not sure if I/O kit was written in this c++ subset just for speed. There was this controversial at the time. Apple announced MacOS X and said that it won’t be compatible with current software. All partners would need to rewrite the software in Objective-C. This didn’t go over well. Apple back paddelt and introduced “carbon”. An API layer for cpp applications as well as “Core Foundation” an underpinning to the objective-c base Framework “Foundation”. Also the reason why we have Obj-c++. The interesting part is that they managed to get the memory management toll free. Means an object allocated in the c/cpp world can be passed to obj-c without extra overhead.
- comex 1y ago
  IOKit C++ is running in the kernel, so it's not really related to any of the technologies you mentioned which are all userland-only.
  - dcrazy 1y ago
    Being able to port your existing C++ driver to IOKit instead of rewriting it in Objective-C is a selling point. For some reason people a lot of people seem to dislike writing an Objective-C shell around their C++.
  - larusso 1y ago
    You may underestimate how many drivers had to be shipped and developed by external companies compared to today. For software / hardware companies that was a huge deal.
comex 1y ago
At the risk of nitpicking, there are a bunch of things that are not quite right. Nonexhaustive list: - Discussion of paging mixes together some concepts as I described in [1]. - Mach port "rights" are not directly related to entitlements. Port rights are port of the original Mach design; entitlements are part of a very different, Apple-specific security system grafted on much later. They are connected in the sense that Mach IPC lets the receiver get an "audit token" describing the process that sent them, which it can then use to look up entitlements. - All IOKit calls go through Mach IPC, not just asynchronous events. - "kmem" (assuming this refers to the kmem_* functions) is not really a “general-purpose kernel malloc”; that would be kalloc. The kmem_* functions are sometimes used for allocations, but they’re closer to a “kernel mmap” in the sense that they always allocate new whole pages. - It’s true that xnu can map the same physical pages into multiple tasks read-only, but that’s nothing special. Every OS does that if you use mmap or similar APIs. What does make the shared cache special is that it can also share physical page tables between tasks. - The discussion about “shared address space” is mixing things up. The current 64-bit behavior is the same as the traditional 32-bit behavior: the lower half of the address space is reserved for the current user process, and the upper half is reserved for the kernel. This is typically called a shared address space, in the sense that the kernel page tables are always loaded, and only page permissions prevent userland from accessing kernel memory. Though you could also think of it as a 'separate' address space in the sense that userland and kernel stick to separate addresses. Anyway, this approach is more efficient (because you don't have to swap page tables for every syscall) and it's the standard thing kernels do. What was tricky and unusual was the intermediate 32-bit behavior where the kernel and user page tables actually were completely independent (so the same address would mean one thing in user mode and another thing in kernel mode). This allowed 32-bit user processes to use more memory (4GB rather than 2GB), but at the cost of making syscalls more expensive. Even weirder, in the same era, xnu could even run 64-bit processes while itself being 32-bit! [2] - The part about Secure Enclave / Exclaves does not explain the main difference between them: the Secure Enclave is its own CPU, while Exclaves are running on the main CPU, just in a more-trusted context. - Probably shouldn't describe dispatch queues as a "new technique". They're more than 15 years old, and now they're sort of being phased out, at least as a programming model you interact with directly, in favor of Swift Concurrency. To be fair, Swift Concurrency uses libdispatch as a backend. [1] https://news.ycombinator.com/item?id=43599230 https://news.ycombinator.com/item?id=43599230 [2] https://superuser.com/questions/23214/why-does-my-mac-os-x-10-6-kernel-run-in-32-bit-mode https://superuser.com/questions/23214/why-does-my-mac-os-x-1...
opengears 1y ago
Does this give us any indication on when Apple will be ditching x86 support?
- SG- 1y ago
  any day now, usually after 6-7 years after hardware releases.
  - icedchai 1y ago
    We probably have a few more years to go then. Consider that they were still selling Mac Pro 2019 Intel systems as late as June, 2023.
    - philistine 1y ago
      I'm not convinced this year's OS release will support Intel. When they switched to Intel, Apple was quicker to dump PowerPC than people remember.
      - icedchai 1y ago
        I'd be surprised if they don't support it for at least one more release. With Intel, they discontinued the PowerPC systems much faster (by the end of 2006.) They were still selling Intel hardware 2 years ago, a couple years into the ARM / Apple Silicon transition.
- snovymgodym 1y ago
  Late 2027 or 2028 most likely. MacOS version lifespan is about 3 years give or take so we'll have a better idea once they announce whether or not MacOS 16 (Sequoia's successor) will support Intel Macs. I have a hunch we'll get one more MacOS version with Intel support since they were still making Mac Minis and Pros with Intel chips in the first half of 2023.
devmtk 1y ago
oh interesting
pjmlp 1y ago
Lots of love and work went into this article, as someone around for most of this history, ported code from NeXTSTEP into Windows, dived into the GNUStep attempts to clone the experience, remembers YellowBox and OpenStep, read the internals books, regular consumer of WWDC content, I would say the article matches pretty much my recollection on most of the systems have evolved.
lapcat 1y ago
Question for the author, who is here in the comments: for clarification, to what extent is the article a deep dive into the OS itself (e.g., reverse engineering) vs. a deep dive into the extant literature on the OS?
- tansanrao 1y ago
  I suppose this would depend on the context. As a PhD student, I primarily focus on building an understanding of systems through existing literature, so I would define a deep dive as a sufficiently thorough explanation of the system, its motivation, and it’s history. In the case of XNU and Darwin, a lot of the sources are also blog posts from reverse engineering efforts by security researchers and jailbreaking communities so it blurs the lines.
naves 1y ago
Jobs tried to hire Torvalds to work on Mac OS X and Linus declined: https://www.macrumors.com/2012/03/22/steve-jobs-tried-to-hire-linux-creator-linus-torvalds-to-work-on-os-x/ https://www.macrumors.com/2012/03/22/steve-jobs-tried-to-hir...
- tux3 1y ago
  Hard to imagine Torvalds working on a microkernel, of all people
mike_hearn 1y ago
That's a good history, but it skips over a lot of the nice security work that really distinguishes Apple's operating systems from Linux or Windows. There's a lack of appreciation out there for just how far ahead Apple now is when it comes to security. I sometimes wonder if one day awareness of this will grow and people working in sensitive contexts will be required to use a Mac by their CISO. The keystone is the code signing system. It's what allows apps to be granted permissions, or to be sandboxed, and for that to actually stick. Apple doesn't use ELF like most UNIXs do, they use a format called Mach-O. The differences between ELF and Mach-O aren't important except for one: Mach-O supports an extra section containing a signed code directory. The code directory contains a series of hashes over code pages. The kernel has some understanding of this data structure and dyld can associate it with the binary or library as it gets loaded. XNU checks the signature over the code directory and the VMM subsystem then hashes code pages as they are loaded on demand, verifying the hashes match the signed hash in the directory. The hash of the code directory therefore can act as a unique identifier for any program in the Apple ecosystem. There's a bug here: the association hangs off the Mach vnode structure so if you overwrite a signed binary and then run it the kernel gets upset and kills the process, even if the new file has a valid signature. You have to actually replace the file as a whole for it to recognize the new situation. On top of this foundation Apple adds code requirements. These are programs written in a small expression language that specifies constraints over aspects of a code signature. You can write a requirement like, "this binary must be signed by Apple" or "this binary can be of any version signed by an entity whose identity is X according to certificate authority Y" or "this binary must have a cdhash of Z" (i.e. be that exact binary). Binaries can also expose a designated requirement, which is the requirement by which they'd like to be known by other parties. This system initially looks like overkill but enables programs to evolve whilst retaining a stable and unforgeable identity. The kernel exposes the signing identity of tasks to other tasks via ports. Requirements can then be imposed on those ports using a userspace library that interprets the constraint language. For example, if a program stores a key in the system keychain (which is implemented in user space) the keychain daemon examines the designated requirement of the program sending the RPC and ensures it matches future requests to use the key. This system is abstracted by entitlements. These are key=value pairs that express permissions. Entitlements are an open system and apps can define their own. However, most entitlements are defined by Apple. Some are purely opt-in: you obtain the permission merely by asking for it and the OS grants it automatically and silently. These seem useless at first, but allow the App Store to explain what an app will do up front, and more generally enable a least-privilege stance where apps don't have access to things unless they need them. Some require additional evidence like a provisioning profile: this is a signed CMS data structure provided by Apple that basically says "apps with designated requirement X are allowed to use restricted entitlement Y", and so you must get Apple's permission to use them. And some are basically abused as a generic signed flags system; they aren't security related at all. The system is then extended further, again through cooperation of userspace and XNU. Binaries being signable is a start but many programs have data files too. At this point the Apple security system becomes a bit hacky IMHO: the kernel isn't involved in checking the integrity of data files. Instead a plist is included at a special place in the slightly ad-hoc bundle directory layout format, the plist contains hashes of every data file in the bundle (at file not page granularity), the hash of the plist is placed in the code signature, and finally the whole thing is checked by Gatekeeper on first run. Gatekeeper is asked by the kernel if it's willing to let a program run and it decides based on the presence of extended attributes that are placed on files and then propagated by GUI tools like web browsers and decompression utilities. The userspace OS code like Finder invokes Gatekeeper to check out a program when it's been first downloaded, and Gatekeeper hashes every file in the bundle to ensure it matches what's signed in the binaries. This is why macOS has this slow "Verifying app" dialog that pops up on first run. Presumably it's done this way to avoid causing apps to stall when they open large data files without using mmap, but it's a pity because on fast networks the unoptimized Gatekeeper verification can actually be slower than the download itself. Apple doesn't care because they view out-of-store distribution as legacy tech. Finally there is Seatbelt, a Lisp-based programming language for expressing sandbox rules. These files are compiled in userspace to some sort of bytecode that's evaluated by the kernel. The language is quite sophisticated and lets you express arbitrary rules for how different system components interact and what they can do, all based on the code signing identities. The above scheme has an obvious loophole that was only closed in recent releases: data files might contain code and they're only checked once. In fact for any Electron or JVM app this is true because the code is in a portable format. So, one app could potentially inject code into another by editing data files and thus subvert code signing. To block this in modern macOS Seatbelt actually sandboxes every single app running. AFAIK there is no unsandboxed code in a modern macOS. One of the policies the sandbox imposes is that apps aren't allowed to modify the data files of other apps unless they've been granted that permission. The policy is quite sophisticated: apps can modify other apps if they're signed by the same legal entity as verified by Apple, apps can allow others matching code requirements to modify them, and users can grant permission on demand. To see this in action go into Settings -> Privacy & Security -> App Management, then turn it off for Terminal.app and (re)start it. Run something like "vim /Applications/Google Chrome.app/Contents/Info.plist" and observe that although the file has rw permissions vim thinks it's read-only. Now, I'll admit that my understanding of how this works ends here because I don't work for Apple. AFAIK the kernel doesn't understand app bundles, and I'm not sure how it decides whether an open() syscall should be converted to read only or not. My guess is that the default Seatbelt policy tells the kernel to do an upcall to a security daemon which understands the bundle format and how to read the SQLite permission database. It then compares the designated requirement of the opener against the policies expressed by the bundle and the sandbox to make the decision.
jlcases 1y ago
What impresses me most about technical documentation like this is how it structures knowledge into comprehensible layers. This article manages to explain an extremely complex system by establishing clear relationships between components. I've been experimenting with similar approaches for documentation in open source projects, using knowledge graphs to link concepts and architectural decisions. The biggest challenge is always keeping documentation synchronized with evolving code. Has anyone found effective tools for maintaining this synchronization between documented architecture and implemented code? Large projects like Darwin must have established processes for this.
- rollcat 1y ago
  > Has anyone found effective tools for maintaining this synchronization between documented architecture and implemented code? Yes, it's called structure, discipline, and iterative improvement. Keep the documentation alongside the code. Think in BSD terms: the OS is delivered as a whole; if I modify /bin/ls to support a new flag, then I update the ls.1 man page accordingly, preferably in the same commit/PR. The man pages are a good reference if you already have familiarity with the employed concepts, so it's good to have an intro/overview document that walks you through those basics. This core design rarely sees radical changes, it tends to evolve - so adapt the overview as you make strategic decisions. The best benchmark is always a new hire. Find out what is it that they didn't understand, and task them with improving the document.
  - worik 1y ago
    > Has anyone found effective tools for... Managing management? Code comments and documentation make no money, only features make money. Bitter experience...
    - rollcat 1y ago
      Try working as a manager. Software development is just one piece of the bigger picture that your manager is concerned with, same way as adding features is just one among your many responsibilities. Managers understand risk. Communicate the risk of disregarding bugfixes, documentation, technical debt, even if it takes a lot of handholding. Expect no less from your manger: if they can communicate client expectations, budget constraints, and most importantly: long-term strategy, together you may be able to devise a better plan to address your own concerns. In other words, empathy can go both ways. And yeah, there are bad managers, just like there are bad coders. Sometimes it's an interpersonal problem. It's called life.
darksaints 1y ago
It seems like the XNU kernel is architecturally super close to the Mach kernel, and XNU drivers architecturally work like Mach drivers, but just that they are compiled into the kernel instead of running in userspace as a separate process. And it seems like the only reason for doing so is performance. That makes me wonder: how hard would it be to run the XNU kernel in something like a “Mach mode”, where you take the same kernel and drivers but run them separately as the Mach microkernel was intended? I feel like from a security standpoint, a lot of situations would gladly call for giving up a little bit of performance for the process isolation security benefits that come from running a microkernel. Is anybody here familiar enough with XNU to opine on this?
- dcrazy 1y ago
  Many drivers are gradually moving back into userspace via DriverKit: https://developer.apple.com/documentation/driverkit https://developer.apple.com/documentation/driverkit
llincerd 1y ago
Darwin is interesting because of the pace of radical changes to its core components. From dropping syscall backwards compatibility to mandatory code signing to dyld_shared_cache eliminating individual system library files to speed up dynamic executable loading. It's a very results-oriented design approach with no nostalgia and no sacred cows. I think only a big hardware vendor like Apple could pull it off.
- conradev 1y ago
  Totally. The march continues with userspace drivers and exclaves[1]. I think it's fair to say that security is a big driver for their kernel evolution. [1] https://www.theregister.com/2025/03/08/kernel_sanders_apple_rearranges_xnu/ https://www.theregister.com/2025/03/08/kernel_sanders_apple_...
mannyv 1y ago
I suppose with unified memory there's no real difference between the kernel and userspace; it's just different security zones. The MMU era used separate memory spaces to enforce security, but it's probably safer in the log run to actually have secure areas instead of 'accidentslly secure areas" that aren't that secure.
- dcrazy 1y ago
  I think you’re misunderstanding “unified memory”. That term refers to whether the GPU has its own onboard memory chips which must be populated by a DMA transfer. It doesn’t refer to whether the system has an MMU.
adolph 1y ago
Can someone speak to the below statement from the article? I thought Objective-C did not have a runtime like memory managed languages like C#. > avoid the runtime overhead of Objective-C in the kernel From Apple docs[0]: You typically don’t need to use the Objective-C runtime library directly when programming in Objective-C. This API is useful primarily for developing bridge layers between Objective-C and other languages, or for low-level debugging. 0. https://developer.apple.com/documentation/objectivec/objective-c-runtime https://developer.apple.com/documentation/objectivec/objecti...
- twoodfin 1y ago
  Objective-C does have a runtime that maintains all the state necessary to implement the APIs in the documentation you linked. For example, how to map class objects to string representations of their names.
  - dcrazy 1y ago
    Yep, ObjC programs call into the runtime every time they call a method.
wuming2 1y ago
Where is Scott Forstall mark in all of this evolution I wonder. He was responsible for adapting macOS, hence XNU, to iPhone. The most successful Apple product of all times. And where is he now?
- philjohn 1y ago
  Well, he was one of the producers[1] of the musical Hadestown, which won 8 Tony awards. [1] https://thebroadwayproducers.com/scott-forstall-2/ https://thebroadwayproducers.com/scott-forstall-2/
astrange 1y ago
> This is likely the origin of boosts and throttles that iOS uses to ensure the foreground app gets more CPU than background apps. The purpose of these is for daemons to inherit the priority of their client apps when doing work for them. I don't remember what thread groups/workloads are for.

485 points by tansanrao 1y ago

I'm a bit disappointed at the lack of interest Apple seems to have on Rust, given their focus on performance, UX and security.

pjmlp 1y ago
They created Swift as replacement for C, C++ and Objective-C, why should they bother with Rust? Even Google on Android and ChromeOS is not exposing Rust to userspace, Java, Kotlin, C, C++, Javascript, Typescript, remain the official userspace languages.
- ladyanita22 1y ago
  Low-level code is being written in Rust. Of course userspace doesn't require low-level languages (and I don't quite get why C and C++ are exposed to the userspace and Rust is not). Swift is not a replacemente for C and C++, but rather for Objective-C. Do you have any sources for those claims?
  - pjmlp 1y ago
    Yes, Apple themselves, apparently folks wanting Apple to use Rust don't read Apple's documentation or watch talks done by Apple compiler developers. > Swift was designed from the outset to be safer than C-based languages, and eliminates entire classes of unsafe code. -- https://www.swift.org/about/ https://www.swift.org/about/ > Swift is a successor to the C, C++, and Objective-C languages. It includes low-level primitives such as types, flow control, and operators. It also provides object-oriented features such as classes, protocols, and generics. -- https://developer.apple.com/swift/ https://developer.apple.com/swift/ "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw "So we feel pretty strongly, obviously at Apple our sucessor language is Swift and I am here to talk about features of Swift, both to try to sell you on to it, but also to talk about the things we think are pretty necessary and the ways in which a programming language can support, you know, clear code, safer and more correct code." "Like I said before, Apple has always intended for Swift to be a sucessor language for all of our predecessors, from the top to the bottom of our stack, accessible to novices, powerful enough for experts, it is real a tall order. From https://youtu.be/lgivCGdmFrw?t=1996 https://youtu.be/lgivCGdmFrw?t=1996 to https://youtu.be/lgivCGdmFrw?t=2042 https://youtu.be/lgivCGdmFrw?t=2042 "Swift as C++ Successor in FoundationDB" https://www.youtube.com/watch?v=ZQc9-seU-5k https://www.youtube.com/watch?v=ZQc9-seU-5k
    - ladyanita22 1y ago
      Oh, you seem to be right. But isn't Swift lower-performing than C, C++ or Rust?
      - pjmlp 1y ago
        Not only does Metal use Swift bindings alongside Objective-C, as per John McCall's own words, that is the plan and to fix where that might still not be the case. Embedded Swift project also started as means to replace Safe C use cases at Apple, like iBoot firmware. https://support.apple.com/en-jo/guide/security/sec30d8d9ec1/web https://support.apple.com/en-jo/guide/security/sec30d8d9ec1/... https://github.com/swiftlang/swift-evolution/blob/main/visions/embedded-swift.md https://github.com/swiftlang/swift-evolution/blob/main/visio... Once upon a time, C compilers were quite lousy versus handwritten 8 and 16 bit Assembly code.
  - ramesh31 1y ago
    >Swift is not a replacemente for C and C++, but rather for Objective-C. Swift is not a replacement for anything; Apple will even say as much. It just fills the hole for a scripting language that they had for decades. Plenty of new Obj-C is still (and will continue to be) written for a long time.
melodyogonna 1y ago
I believe their plan is to make Swift good enough to use in high-performance low-level scenarios. Some of their recent work has been to reduce implicit copies

deleted 1y ago

[deleted]

whalesalad 1y ago

I’ve been wanting to understand Darwin at this depth for a long time. Great read!

tansanrao 1y ago
It’s my first time condensing my research notes into a blog post like this, glad you liked it!
- ForOldHack 1y ago
  It was easily comprehensive enough, that I printed it out and was showing people today what the differences were in the last couple of os releases, while ruminating about snow leopard. No one mentions that the blue box became Rosetta, and Rosetta II did the same thing in the switch from Intel to ARM. There are some very tiny points, but this is easily very best to date. ( I started with Rhapsody, and Linux in swedish, and NT 3.1 )( Ran MKLinux on a 7100, but never got accelerated video to work. )
  - ForOldHack 1y ago
    I should add, I have never seen accelerated video in Linux, except for built in Intel video and it's fine.
jshier 1y ago
Mac OS X Internals by Singh is one of my favorite books, such a great in depth examination of Mac OS X circa 10.4. I really wish there was an updated version. Edit: I see it's even cited at the end of this article. Truly a source for the (macOS) ages.
- wpm 1y ago
  Jonathan Levin’s three part series “*OS Internals” is that update, but they stopped working on and writing about Darwin around Catalina.
kccqzy 1y ago

bch 1y ago

> Mach’s virtual memory (VM) system was influential beyond the project – it was adopted by 4.4BSD and later FreeBSD as their memory management subsystem. …and NetBSD[0], OpenBSD[1], but apparently not DragonFly BSD[2]. [0] https://netbsd.org/docs/kernel/uvm.html https://netbsd.org/docs/kernel/uvm.html [1] https://man.openbsd.org/OpenBSD-3.0/uvm.9 https://man.openbsd.org/OpenBSD-3.0/uvm.9 [2] https://www.dragonflybsd.org/mailarchive/kernel/2011-04/msg00034.html https://www.dragonflybsd.org/mailarchive/kernel/2011-04/msg0...

tansanrao 1y ago
Ohhh interesting! I’ll update the post to include this soon, thanks!
inkyoto 1y ago
Sadly, that is not entirely correct. Whilst all three BSDs (386BSD, FreeBSD, and NetBSD; there was no OpenBSD in the beginning) did inherit the legacy Mach 2.5-style design, it did not live on in FreeBSD, whose core team started pretty quickly replacing all remaining vestiges of the Mach VM[0] with a complete, modern, and highly performant rewrite of the entire VM. FreeBSD 4 had none of the original Mach code left in the kernel codebase, and that happened in the late 1990s. Therefore, FreeBSD can't be referenced in a relationship to Mach apart from the initial separation/very early foundation stage. NetBSD (and OpenBSD) went on for a while but also quickly hit the wall with the Mach design (performance, SMP/scalability, networking) and also set out on a complete rewrite with UVM (unified virtual memory) designed and led by Chuck Cranor, who wrote his dissertation on the UVM. OpenBSD later borrowed and adopted the UVM implementation, which remains in use today. So out of all living BSD's[1], only XNU/Darwin continues to use Mach, and not Mach 2.5 but Mach 3. There have been Mach 2.5, 3 and 4 (GNU/Hurd uses Mach 4) in existence, and the compatibility between them is rather low, and remains mostly at the overall architectural level. They are better to be treated as distinct design with shared influence. [0] Of which there were not that many to start off with. [1] I am not sure whether DragonBSD is dead or alive today at all.
- o11c 1y ago
  > I am not sure whether DragonBSD is dead or alive today at all. It seems to have about the same level of activity as NetBSD. Take that how you will.

swatson741 1y ago

Whenever I see the Darwin kernel brought into the discussion I can't help but wonder how different things could have been if Apple had just forked Linux and ran their OS services on top of that. Especially when I think about how committed they are to Darwin it really paints a poor image in my mind. The loss that open source suffers from that, and the time and money Apple has to dedicate to this with a disproportionate return.

skissane 1y ago
> Whenever I see the Darwin kernel brought into the discussion I can't help but wonder how different things could have been if Apple had just forked Linux XNU is only partially open sourced – the core is open sourced, but significant chunks are missing, e.g. APFS filesystem. Forking Linux might have legally compelled them to make all kernel modules open source–which while that would likely be a positive for humanity, isn't what Apple wants to do
- mattl 1y ago
  At one point NeXT considered distributing GCC under the GPL with some proprietary parts linked at first boot into the binary. Stallman after speaking with lawyers rejected this. https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Why-CLISP-is-under-GPL https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Wh... Look for "NeXT" on this page.
  - leoh 1y ago
    Stallman’s insistence that a judge would side with him is pretty arrogant in my opinion; eg looking at Oracle v. Google decades later and how folks deciding the case seemed to be confused about technical matters.
    - skissane 1y ago
      I don't think it was "arrogant" – if you read the link, he explains that he originally thought differently, but he changed his mind based on what his lawyer told him. I don't think you can label a non-lawyer "arrogant" for accepting the legal advice of their own attorney – whether that advice is correct or not can be debated, but it isn't arrogant for someone to trust the correctness of their own lawyer's advice.

emchammer 1y ago

Couldn't Apple have used ZFS instead of inventing APFS? Maybe modifying it to use less physical memory?

inkyoto 1y ago
Supporting ZFS in a UNIX kernel requires excessively extensive modifications to the design and implementation of the VMM, namely: 1. Integration of the kernel's VM with ZFS's adaptive replacement cache which runs in user space – memory pressure cooperation, page accounting and unified memory management. It also requires extensive VM modifications to support ZFS's controlled page eviction, fine-grained dirty page tracking, plus other stuff. 2. VMM alignment with the ZFS transactional semantics and intent logs – delayed write optimisations, efficient page syncing. 3. Support for large memory pages and proper memory page alignment – support for superpages (to reduce the TLB pressure and to efficiently map large ZFS blocks efficiently) and I/O alignment awareness (to ensure proper alignment of memory pages to avoid unnecessary copies). 4. Memory-mapped I/O: different implementation of mmap and support for lazy checksumming for mmap pages. 5. Integration with kernel thread management and scheduling, co-opertation with VMM memmory allocators. 6. … and the list goes on and on. ZFS is just not the right answer for consumer facing and mobile/portable devices due being a heavyweight server design with vastly different design provisions and due to being the answer to a entirely different question.
- AndrewDavis 1y ago
  > Supporting ZFS in a UNIX kernel requires excessively extensive modifications to the design and implementation of the VMM, namely: FYI: Apple did a bunch of that work. They ported ZFS to OSX shortly after it was open sourced. With with only support landing in 10.5. With it being listed as an upcoming feature in 10.6. But something happened and they abandoned it. The rumour is a sun exec let the cat out of the bag about it being the next main filesystem for osx (ie not just support for non root drives) and this annoyed Jobs so much he canned the whole project.
  - lunarlull 1y ago

agentkilo 1y ago

The article states that "pager daemons" that manage swap files runs in user space, and the kernel memory can also get swapped out, but never explained how a user space daemon swaps out kernel memory. Do they have hard-coded exceptions for special daemons, or use special system calls? Where can I find out more details about the user space memory management specifically?

jjtheblunt 1y ago
https://github.com/apple-oss-distributions/xnu https://github.com/apple-oss-distributions/xnu
comex 1y ago
The claim is inaccurate and mixes together multiple different things: - The Mach microkernel originally supported true userland paging, like mmap but with an arbitrary daemon in place of the filesystem. You can see the interface here: https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/memory_object_data_request.html https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/memory_... But I'm not sure if Darwin ever used this functionality; it certainly hasn't used it for the last ~20 years. - dynamic_pager never used this interface. It used a different, much more limited Mach interface where xnu could alert it when it was low on swap; dynamic_pager would create swap files, and pass them back into the kernel using macx_swapon and macx_swapoff syscalls. But the actual swapping was done by the kernel. Here is what dynamic_pager used to look like: https://github.com/apple-oss-distributions/system_cmds/blob/171b4c816e8aee4f16d85d080d0de154e4678e0f/dynamic_pager.tproj/dynamic_pager.c https://github.com/apple-oss-distributions/system_cmds/blob/... But that functionality has since moved into the kernel, so now dynamic_pager does basically nothing: https://github.com/apple-oss-distributions/system_cmds/blob/main/dynamic_pager/dynamic_pager.c https://github.com/apple-oss-distributions/system_cmds/blob/... - The vast majority of kernel memory is wired and cannot be paged out. But the kernel can explicitly ask for pageable memory (e.g. with IOMallocPageable), and yes, that memory can be swapped to disk. It's just rarely used. Still, any code that does this needs to be careful to avoid deadlocks. Even though userland is no longer involved in "paging" per se, it's still possible and in fact common for userland to get involved one or two layers down. You can have userland filesystems with FSKit (or third-party FUSE). You can have filesystems mounted on disk images which rely on userland to convert reads and writes to the virtual block device into reads and writes to the underlying dmg file (see `man hdiutil`). You can have NFS or SMB connections going through userland networking extensions. There are probably other cases I'm not thinking of. EDIT: Actually, I may be wrong about that last bit. You can definitely have filesystems that block on userspace, but it may not be supported to put swap on those filesystems.

fithisux 1y ago

They should have fostered a better FOSS community around XNU, now that they moved to ARM there should have been a runnable distribution for x64

larusso 1y ago

I’m not sure if I/O kit was written in this c++ subset just for speed. There was this controversial at the time. Apple announced MacOS X and said that it won’t be compatible with current software. All partners would need to rewrite the software in Objective-C. This didn’t go over well. Apple back paddelt and introduced “carbon”. An API layer for cpp applications as well as “Core Foundation” an underpinning to the objective-c base Framework “Foundation”. Also the reason why we have Obj-c++. The interesting part is that they managed to get the memory management toll free. Means an object allocated in the c/cpp world can be passed to obj-c without extra overhead.

comex 1y ago
IOKit C++ is running in the kernel, so it's not really related to any of the technologies you mentioned which are all userland-only.
- dcrazy 1y ago
  Being able to port your existing C++ driver to IOKit instead of rewriting it in Objective-C is a selling point. For some reason people a lot of people seem to dislike writing an Objective-C shell around their C++.
- larusso 1y ago
  You may underestimate how many drivers had to be shipped and developed by external companies compared to today. For software / hardware companies that was a huge deal.

comex 1y ago

At the risk of nitpicking, there are a bunch of things that are not quite right. Nonexhaustive list: - Discussion of paging mixes together some concepts as I described in [1]. - Mach port "rights" are not directly related to entitlements. Port rights are port of the original Mach design; entitlements are part of a very different, Apple-specific security system grafted on much later. They are connected in the sense that Mach IPC lets the receiver get an "audit token" describing the process that sent them, which it can then use to look up entitlements. - All IOKit calls go through Mach IPC, not just asynchronous events. - "kmem" (assuming this refers to the kmem_* functions) is not really a “general-purpose kernel malloc”; that would be kalloc. The kmem_* functions are sometimes used for allocations, but they’re closer to a “kernel mmap” in the sense that they always allocate new whole pages. - It’s true that xnu can map the same physical pages into multiple tasks read-only, but that’s nothing special. Every OS does that if you use mmap or similar APIs. What does make the shared cache special is that it can also share physical page tables between tasks. - The discussion about “shared address space” is mixing things up. The current 64-bit behavior is the same as the traditional 32-bit behavior: the lower half of the address space is reserved for the current user process, and the upper half is reserved for the kernel. This is typically called a shared address space, in the sense that the kernel page tables are always loaded, and only page permissions prevent userland from accessing kernel memory. Though you could also think of it as a 'separate' address space in the sense that userland and kernel stick to separate addresses. Anyway, this approach is more efficient (because you don't have to swap page tables for every syscall) and it's the standard thing kernels do. What was tricky and unusual was the intermediate 32-bit behavior where the kernel and user page tables actually were completely independent (so the same address would mean one thing in user mode and another thing in kernel mode). This allowed 32-bit user processes to use more memory (4GB rather than 2GB), but at the cost of making syscalls more expensive. Even weirder, in the same era, xnu could even run 64-bit processes while itself being 32-bit! [2] - The part about Secure Enclave / Exclaves does not explain the main difference between them: the Secure Enclave is its own CPU, while Exclaves are running on the main CPU, just in a more-trusted context. - Probably shouldn't describe dispatch queues as a "new technique". They're more than 15 years old, and now they're sort of being phased out, at least as a programming model you interact with directly, in favor of Swift Concurrency. To be fair, Swift Concurrency uses libdispatch as a backend. [1] https://news.ycombinator.com/item?id=43599230 https://news.ycombinator.com/item?id=43599230 [2] https://superuser.com/questions/23214/why-does-my-mac-os-x-10-6-kernel-run-in-32-bit-mode https://superuser.com/questions/23214/why-does-my-mac-os-x-1...

opengears 1y ago

Does this give us any indication on when Apple will be ditching x86 support?

SG- 1y ago
any day now, usually after 6-7 years after hardware releases.
- icedchai 1y ago
  We probably have a few more years to go then. Consider that they were still selling Mac Pro 2019 Intel systems as late as June, 2023.
  - philistine 1y ago
    I'm not convinced this year's OS release will support Intel. When they switched to Intel, Apple was quicker to dump PowerPC than people remember.
    - icedchai 1y ago
      I'd be surprised if they don't support it for at least one more release. With Intel, they discontinued the PowerPC systems much faster (by the end of 2006.) They were still selling Intel hardware 2 years ago, a couple years into the ARM / Apple Silicon transition.
snovymgodym 1y ago
Late 2027 or 2028 most likely. MacOS version lifespan is about 3 years give or take so we'll have a better idea once they announce whether or not MacOS 16 (Sequoia's successor) will support Intel Macs. I have a hunch we'll get one more MacOS version with Intel support since they were still making Mac Minis and Pros with Intel chips in the first half of 2023.

devmtk 1y ago

oh interesting

pjmlp 1y ago

Lots of love and work went into this article, as someone around for most of this history, ported code from NeXTSTEP into Windows, dived into the GNUStep attempts to clone the experience, remembers YellowBox and OpenStep, read the internals books, regular consumer of WWDC content, I would say the article matches pretty much my recollection on most of the systems have evolved.

lapcat 1y ago

Question for the author, who is here in the comments: for clarification, to what extent is the article a deep dive into the OS itself (e.g., reverse engineering) vs. a deep dive into the extant literature on the OS?

tansanrao 1y ago
I suppose this would depend on the context. As a PhD student, I primarily focus on building an understanding of systems through existing literature, so I would define a deep dive as a sufficiently thorough explanation of the system, its motivation, and it’s history. In the case of XNU and Darwin, a lot of the sources are also blog posts from reverse engineering efforts by security researchers and jailbreaking communities so it blurs the lines.

naves 1y ago

Jobs tried to hire Torvalds to work on Mac OS X and Linus declined: https://www.macrumors.com/2012/03/22/steve-jobs-tried-to-hire-linux-creator-linus-torvalds-to-work-on-os-x/ https://www.macrumors.com/2012/03/22/steve-jobs-tried-to-hir...

tux3 1y ago
Hard to imagine Torvalds working on a microkernel, of all people

mike_hearn 1y ago

That's a good history, but it skips over a lot of the nice security work that really distinguishes Apple's operating systems from Linux or Windows. There's a lack of appreciation out there for just how far ahead Apple now is when it comes to security. I sometimes wonder if one day awareness of this will grow and people working in sensitive contexts will be required to use a Mac by their CISO. The keystone is the code signing system. It's what allows apps to be granted permissions, or to be sandboxed, and for that to actually stick. Apple doesn't use ELF like most UNIXs do, they use a format called Mach-O. The differences between ELF and Mach-O aren't important except for one: Mach-O supports an extra section containing a signed code directory. The code directory contains a series of hashes over code pages. The kernel has some understanding of this data structure and dyld can associate it with the binary or library as it gets loaded. XNU checks the signature over the code directory and the VMM subsystem then hashes code pages as they are loaded on demand, verifying the hashes match the signed hash in the directory. The hash of the code directory therefore can act as a unique identifier for any program in the Apple ecosystem. There's a bug here: the association hangs off the Mach vnode structure so if you overwrite a signed binary and then run it the kernel gets upset and kills the process, even if the new file has a valid signature. You have to actually replace the file as a whole for it to recognize the new situation. On top of this foundation Apple adds code requirements. These are programs written in a small expression language that specifies constraints over aspects of a code signature. You can write a requirement like, "this binary must be signed by Apple" or "this binary can be of any version signed by an entity whose identity is X according to certificate authority Y" or "this binary must have a cdhash of Z" (i.e. be that exact binary). Binaries can also expose a designated requirement, which is the requirement by which they'd like to be known by other parties. This system initially looks like overkill but enables programs to evolve whilst retaining a stable and unforgeable identity. The kernel exposes the signing identity of tasks to other tasks via ports. Requirements can then be imposed on those ports using a userspace library that interprets the constraint language. For example, if a program stores a key in the system keychain (which is implemented in user space) the keychain daemon examines the designated requirement of the program sending the RPC and ensures it matches future requests to use the key. This system is abstracted by entitlements. These are key=value pairs that express permissions. Entitlements are an open system and apps can define their own. However, most entitlements are defined by Apple. Some are purely opt-in: you obtain the permission merely by asking for it and the OS grants it automatically and silently. These seem useless at first, but allow the App Store to explain what an app will do up front, and more generally enable a least-privilege stance where apps don't have access to things unless they need them. Some require additional evidence like a provisioning profile: this is a signed CMS data structure provided by Apple that basically says "apps with designated requirement X are allowed to use restricted entitlement Y", and so you must get Apple's permission to use them. And some are basically abused as a generic signed flags system; they aren't security related at all. The system is then extended further, again through cooperation of userspace and XNU. Binaries being signable is a start but many programs have data files too. At this point the Apple security system becomes a bit hacky IMHO: the kernel isn't involved in checking the integrity of data files. Instead a plist is included at a special place in the slightly ad-hoc bundle directory layout format, the plist contains hashes of every data file in the bundle (at file not page granularity), the hash of the plist is placed in the code signature, and finally the whole thing is checked by Gatekeeper on first run. Gatekeeper is asked by the kernel if it's willing to let a program run and it decides based on the presence of extended attributes that are placed on files and then propagated by GUI tools like web browsers and decompression utilities. The userspace OS code like Finder invokes Gatekeeper to check out a program when it's been first downloaded, and Gatekeeper hashes every file in the bundle to ensure it matches what's signed in the binaries. This is why macOS has this slow "Verifying app" dialog that pops up on first run. Presumably it's done this way to avoid causing apps to stall when they open large data files without using mmap, but it's a pity because on fast networks the unoptimized Gatekeeper verification can actually be slower than the download itself. Apple doesn't care because they view out-of-store distribution as legacy tech. Finally there is Seatbelt, a Lisp-based programming language for expressing sandbox rules. These files are compiled in userspace to some sort of bytecode that's evaluated by the kernel. The language is quite sophisticated and lets you express arbitrary rules for how different system components interact and what they can do, all based on the code signing identities. The above scheme has an obvious loophole that was only closed in recent releases: data files might contain code and they're only checked once. In fact for any Electron or JVM app this is true because the code is in a portable format. So, one app could potentially inject code into another by editing data files and thus subvert code signing. To block this in modern macOS Seatbelt actually sandboxes every single app running. AFAIK there is no unsandboxed code in a modern macOS. One of the policies the sandbox imposes is that apps aren't allowed to modify the data files of other apps unless they've been granted that permission. The policy is quite sophisticated: apps can modify other apps if they're signed by the same legal entity as verified by Apple, apps can allow others matching code requirements to modify them, and users can grant permission on demand. To see this in action go into Settings -> Privacy & Security -> App Management, then turn it off for Terminal.app and (re)start it. Run something like "vim /Applications/Google Chrome.app/Contents/Info.plist" and observe that although the file has rw permissions vim thinks it's read-only. Now, I'll admit that my understanding of how this works ends here because I don't work for Apple. AFAIK the kernel doesn't understand app bundles, and I'm not sure how it decides whether an open() syscall should be converted to read only or not. My guess is that the default Seatbelt policy tells the kernel to do an upcall to a security daemon which understands the bundle format and how to read the SQLite permission database. It then compares the designated requirement of the opener against the policies expressed by the bundle and the sandbox to make the decision.

jlcases 1y ago

What impresses me most about technical documentation like this is how it structures knowledge into comprehensible layers. This article manages to explain an extremely complex system by establishing clear relationships between components. I've been experimenting with similar approaches for documentation in open source projects, using knowledge graphs to link concepts and architectural decisions. The biggest challenge is always keeping documentation synchronized with evolving code. Has anyone found effective tools for maintaining this synchronization between documented architecture and implemented code? Large projects like Darwin must have established processes for this.

rollcat 1y ago
> Has anyone found effective tools for maintaining this synchronization between documented architecture and implemented code? Yes, it's called structure, discipline, and iterative improvement. Keep the documentation alongside the code. Think in BSD terms: the OS is delivered as a whole; if I modify /bin/ls to support a new flag, then I update the ls.1 man page accordingly, preferably in the same commit/PR. The man pages are a good reference if you already have familiarity with the employed concepts, so it's good to have an intro/overview document that walks you through those basics. This core design rarely sees radical changes, it tends to evolve - so adapt the overview as you make strategic decisions. The best benchmark is always a new hire. Find out what is it that they didn't understand, and task them with improving the document.
- worik 1y ago
  > Has anyone found effective tools for... Managing management? Code comments and documentation make no money, only features make money. Bitter experience...
  - rollcat 1y ago
    Try working as a manager. Software development is just one piece of the bigger picture that your manager is concerned with, same way as adding features is just one among your many responsibilities. Managers understand risk. Communicate the risk of disregarding bugfixes, documentation, technical debt, even if it takes a lot of handholding. Expect no less from your manger: if they can communicate client expectations, budget constraints, and most importantly: long-term strategy, together you may be able to devise a better plan to address your own concerns. In other words, empathy can go both ways. And yeah, there are bad managers, just like there are bad coders. Sometimes it's an interpersonal problem. It's called life.

darksaints 1y ago

It seems like the XNU kernel is architecturally super close to the Mach kernel, and XNU drivers architecturally work like Mach drivers, but just that they are compiled into the kernel instead of running in userspace as a separate process. And it seems like the only reason for doing so is performance. That makes me wonder: how hard would it be to run the XNU kernel in something like a “Mach mode”, where you take the same kernel and drivers but run them separately as the Mach microkernel was intended? I feel like from a security standpoint, a lot of situations would gladly call for giving up a little bit of performance for the process isolation security benefits that come from running a microkernel. Is anybody here familiar enough with XNU to opine on this?

dcrazy 1y ago
Many drivers are gradually moving back into userspace via DriverKit: https://developer.apple.com/documentation/driverkit https://developer.apple.com/documentation/driverkit

llincerd 1y ago

Darwin is interesting because of the pace of radical changes to its core components. From dropping syscall backwards compatibility to mandatory code signing to dyld_shared_cache eliminating individual system library files to speed up dynamic executable loading. It's a very results-oriented design approach with no nostalgia and no sacred cows. I think only a big hardware vendor like Apple could pull it off.

conradev 1y ago
Totally. The march continues with userspace drivers and exclaves[1]. I think it's fair to say that security is a big driver for their kernel evolution. [1] https://www.theregister.com/2025/03/08/kernel_sanders_apple_rearranges_xnu/ https://www.theregister.com/2025/03/08/kernel_sanders_apple_...

mannyv 1y ago

I suppose with unified memory there's no real difference between the kernel and userspace; it's just different security zones. The MMU era used separate memory spaces to enforce security, but it's probably safer in the log run to actually have secure areas instead of 'accidentslly secure areas" that aren't that secure.

dcrazy 1y ago
I think you’re misunderstanding “unified memory”. That term refers to whether the GPU has its own onboard memory chips which must be populated by a DMA transfer. It doesn’t refer to whether the system has an MMU.

adolph 1y ago

Can someone speak to the below statement from the article? I thought Objective-C did not have a runtime like memory managed languages like C#. > avoid the runtime overhead of Objective-C in the kernel From Apple docs[0]: You typically don’t need to use the Objective-C runtime library directly when programming in Objective-C. This API is useful primarily for developing bridge layers between Objective-C and other languages, or for low-level debugging. 0. https://developer.apple.com/documentation/objectivec/objective-c-runtime https://developer.apple.com/documentation/objectivec/objecti...

twoodfin 1y ago
Objective-C does have a runtime that maintains all the state necessary to implement the APIs in the documentation you linked. For example, how to map class objects to string representations of their names.
- dcrazy 1y ago
  Yep, ObjC programs call into the runtime every time they call a method.

wuming2 1y ago

Where is Scott Forstall mark in all of this evolution I wonder. He was responsible for adapting macOS, hence XNU, to iPhone. The most successful Apple product of all times. And where is he now?

philjohn 1y ago
Well, he was one of the producers[1] of the musical Hadestown, which won 8 Tony awards. [1] https://thebroadwayproducers.com/scott-forstall-2/ https://thebroadwayproducers.com/scott-forstall-2/

astrange 1y ago

> This is likely the origin of boosts and throttles that iOS uses to ensure the foreground app gets more CPU than background apps. The purpose of these is for daemons to inherit the priority of their client apps when doing work for them. I don't remember what thread groups/workloads are for.