Apple Internals: Swift in the Kernel

# Apple Internals: Swift in the Kernel Source: [https://blog.calif.io/p/apple-internals-swift-in-the-kernel](https://blog.calif.io/p/apple-internals-swift-in-the-kernel) After WWDC, I saw[Devon Maloney posted a slide](https://x.com/plailect/status/2064138356259213475)saying Apple has “started writing parts of the core operating system kernel in Swift” for the 27 releases\. First steps toward a memory\-safe kernel\. What does this even mean?\! Naturally I dropped what I was doing and went grepping through the iOS 27 kernelcache\. Alas, nothing came of it\. All is not lost though: I found the Embedded Swift runtime in macOS 27, sitting in`com\.apple\.kec\.pthread`of all places\. Then I went poking around the root filesystem and it turns out Apple gave the whole effort a name: KernelKit\. Let's dissect it\. [](https://substackcdn.com/image/fetch/$s_!9HB8!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8bb311ae-2b1f-4900-b2b6-06a14ecd95cc_840x660.png) *Where this is going: the C/C\+\+ core \(Mach, BSD, IOKit\) is untouched\. Swift shows up only as a small Embedded runtime inside specific KernelKit kexts at the extension layer\.* On the macOS 27 root volume \(`26A5353q`\), right next to`/System/DriverKit`, are two kexts: The`Info\.plist`for the pthread one is where it gets fun: And`version\.plist`: So there's an internal SDK called`kernelkit\.macosx27\.0\.internal`, and`libpthread\_kernelkit`is a separate Xcode target building from the same libpthread sources as the regular kext\.`Libm`gets the same treatment:`ProjectName: Libm\_kernelkit`\. If this is giving you[DriverKit](https://developer.apple.com/documentation/driverkit)déjà vu, you are on to something: its own directory under`/System`, its own SDK, its own Mach\-O platform constant, the same playbook seven years later\. The`LC\_BUILD\_VERSION`for these binaries says: The Mach\-O platform enum currently goes up to 24 \(`visionOSExclaveKit`\)\. Nothing in public headers, LLVM, or`loader\.h`knows what 25 is yet;`ipsw`just printed`Platform\(25\)`until I went and added the constants\. Then I checked the iOS 27 kernelcache's pthread kext, expecting the boring old absence of`LC\_BUILD\_VERSION`that iOS 26 had: That's notable for two reasons\.`LC\_BUILD\_VERSION`is the stamp a Mach\-O carries to record which OS it was built for, and Apple tracks each one by a number rather than a name\. Last year's iOS 26 build of this kext had no such stamp at all, so its mere presence here is new\. And the number is**26**, not the**25**macOS reported a moment ago\. Apple could have filed every OS's kernel\-Swift code under one shared platform, but instead each OS gets its own: macOS is 25, iOS is 26, with the rest in the table below\. To get the actual names I pulled the table out of the Xcode 27 beta linker\.`ld`keeps a static array of 96\-byte platform descriptors \(from`Platform\.cpp`\); the`uint32`ID sits at offset`\+0x20`in each\. Calibrated against the known entries 23/24 \(`visionOS\-exclaveCore`/`Kit`\), the six new ones are: The table ends at 30\. All six are new in the 27 train; iOS 26\.6's pthread kext \(libpthread\-539\) has no`LC\_BUILD\_VERSION`at all\. 25 and 26 are the only ones I've seen in shipping binaries so far\. `TargetConditionals\.h`has no`TARGET\_OS\_KERNELKIT`, and there's no`KernelKit\.platform`under`Contents/Developer/Platforms/`\. But cstrings from the toolchain binaries provide some more clues: - `ld`: - `tapi`and`swift\-frontend`: Six per\-OS variants\. bridgeOS gets one, because apparently the Touch Bar needs in\-kernel Swift before iOS does\. There's a`TARGET\_OS\_KERNELKIT`preprocessor conditional\. The linker hard\-codes`/System/KernelKit/usr/lib/swift`as a search path, which tells you where the in\-kernel Swift stdlib is going to live once it grows past what's statically baked into pthread today\. And the ld error string`kernelKit can only be used with \-r, \-kext and \-static`confirms there's no dylib or executable output, just kext bundles and object files\. The linker, the TBD stub tool, and the Swift compiler can all already target this thing\. Apple just hasn't published the headers or the SDK yet\. The`/System/KernelKit/`pthread binary is the one that ends up in the kernelcache\. I know because the UUIDs match: Same libpthread\-553 source, two builds\. The "normal" macOS\-platform build, the one shipped in`/System/Library/Extensions`and the KDK, has no Swift\. The KernelKit\-platform build lives in`/System/KernelKit`, gets prelinked into the kernelcache, and carries the Embedded Swift runtime statically linked in\. Here's what's actually in there: The`\_swift\_embedded\_\*`family matches[`stdlib/public/core/EmbeddedRuntime\.swift`](https://github.com/swiftlang/swift/blob/main/stdlib/public/core/EmbeddedRuntime.swift)in the open Swift repo\. The`$e`mangling prefix is the[documented](https://github.com/swiftlang/swift/blob/main/docs/ABI/Mangling.rst)Embedded Swift prefix \(regular Swift uses`$s`; this was switched on in[\#77923](https://github.com/swiftlang/swift/pull/77923)\), and`\_$es16\_emptyBoxStorageSi\_Sitvp`demangles to`Swift\.\_emptyBoxStorage : \(Swift\.Int, Swift\.Int\)`\. There are no`\_\_swift5\_\*`reflection sections, which is correct for Embedded Swift; generics are monomorphized and there's no runtime metadata\. The whole runtime is about 2\.4 KB of`\_\_TEXT\_EXEC\.\_\_text`\. I opened it in IDA to make sure these weren't 37`ret`instructions wearing a trench coat\.`swift\_release`is a real atomic refcount decrement with a`brk \#1`underflow trap and a call to`\_swift\_embedded\_invoke\_heap\_object\_destroy`at zero\.`swift\_once`is a CAS one\-shot with a spinwait\.`swift\_dynamicCast`is 500 bytes of metadata\-chain walking and existential handling\. The data at`\_emptyBoxStorage`is`\(0, 0xFFFFFFFFFFFFFFFF\)`, the immortal empty\-box singleton, which confirms this is the genuine runtime rather than 37 stubs in a trench coat\. `com\.apple\.kec\.Libm`has been in macOS kernelcaches for a while \(it was there in 26\.6, source ver 3312\)\. What's new is that it got rebuilt under the KernelKit SDK \(`Libm\_kernelkit`, platform 25, source ver 3326\) and moved into`/System/KernelKit`\. It's 65 symbols of math:`\_cbrt`,`\_\_sincos\_stret`,`\_\_ceilf16`, the float16 intrinsics, that sort of thing\. No Swift symbols of its own; it's just been adopted into the KernelKit family, presumably so Swift's`Double`/`Float`operations have something to link against\. I checked xrefs in IDA for the public Swift entry points:`swift\_retain`,`swift\_release`,`swift\_once`,`swift\_dynamicCast`,`swift\_allocEmptyBox`\. The only internal caller is`swift\_dynamicCast`calling`swift\_release`to clean up after itself\. The decade\-old pthread C code \(`\_psynch\_mutexwait`,`\_bsdthread\_create`\) never touches Swift\. Then I scanned all 370 macOS kernelcache fileset entries for`swift\_\*`references anywhere else, i\.e\. some other kext that links against this runtime: Just one hit, the kext that defines them: 23 of the 37 symbols are global exports, and not a single other component in the kernelcache imports them\. The runtime is linked, loaded at boot, and idle\. iOS 27 is one step further back: pthread and Libm are KernelKit\-platform binaries \(platform 26\) but the Swift runtime isn't linked in at all, the same libpthread\-553 source with just a different build config\. Currently, the Swift kernel runtime is on macOS only and unreferenced\. That reads to me like the rollout order is: ship the SDK and the runtime first, watch it not break anything for a beta cycle or two, then start landing actual Swift kernel components that link against`\_swift\_retain`and friends\. iOS gets the platform plumbing now and the runtime later\. XNU itself is still entirely C/C\+\+\. The KDK's`kernel\.release\.t6050\.dSYM`\(`t6050`is the M5 Pro SoC\) has 2,106 DWARF compile units, and`DW\_AT\_language`breaks down as 1,855`DW\_LANG\_C11`, 249`DW\_LANG\_C\_plus\_plus\_14`, 2`DW\_LANG\_Mips\_Assembler`, and zero`DW\_LANG\_Swift`\. Same on t6041 \(the M4 Max\) and the KASAN build\. The compiler emits one of those per source file, so this can't be hiding behind stripped symbols\. Whatever Swift is coming, it's coming as KernelKit components, not as a rewrite of Mach\. Also if anyone at Apple wants to leak`KernelKit\.macosx\.sdk`I will treat it with the respect it deserves\. PS: For faithful readers, yes, we will be blogging about Swift and exclaves soon\. Be patient\. #### Discussion about this post ### Ready for more?