Tutorial How to build XNU from source

[alyxferrari]

This was posted because apparently someone's trying to figure out the IOPCIFamily issues on MSI 500 series boards and AM5 socket boards and they're having trouble with building XNU.

Here's what I wrote in the Discord server:

Grab the version of Xcode with the correct SDK for the kernel you're building.
Run xcode-select on it.
Verify that xcrun -sdk macosx -show-sdk-path returns the correct path.
$ xcode-select --install to install the Xcode Command Line Tools for that version of Xcode.

Go to https://opensource.apple.com/releases/ and pick a macOS version, download all of the following packages from that version of macOS specifically.
(You can also clone the packages from apple-oss-distributions and checkout the branch for the release you want.)
But anyway:
Download dtrace, AvailabilityVersions, libdispatch, and xnu.

cd to dtrace
$ xcodebuild install -sdk macosx -target ctfconvert -target ctfdump -target ctfmerge ARCHS=x86_64 VALID_ARCHS=x86_64 DSTROOT=$PWD/dst
$ export TOOLCHAIN="cd $(xcrun -sdk macosx -show-sdk-platform-path)/../../Toolchains/XcodeDefault.xctoolchain && pwd"
# ditto "$PWD/dst/$TOOLCHAIN" "$TOOLCHAIN"

cd to AvailabilityVersions
$ make install
# ditto "$PWD/dst/usr/local/libexec" "$(xcrun -sdk macosx -show-sdk-path)/usr/local/libexec"

cd to xnu
It was at this point that I had my first issue:
scan-build apparently didn't build+install correctly? So I had to install LLVM (which includes it) and then add the LLVM /bin/ folder to my path variable.
The path you want is /usr/local/opt/llvm/bin. This will add LLVM Clang to your path, but XNU's build system automatically targets Apple Clang anyway, so it's not an issue.
$ brew install llvm
# ln -s /usr/local/bin/python3 /usr/local/bin/python
$ make SDKROOT=macosx ARCH_CONFIGS=X86_64 installhdrs
# ditto "$PWD/BUILD/dst" "$(xcrun -sdk macosx -show-sdk-path)"

cd to libdispatch
$ xcodebuild install -sdk macosx ARCHS=x86_64 VALID_ARCHS=x86_64 -target libfirehose_kernel PRODUCT_NAME=firehose_kernel DSTROOT=$PWD/dst
# ditto "$PWD/dst/usr/local" "$(xcrun -sdk macosx -show-sdk-path)/usr/local"

cd back to xnu
A wild stupid problem appears! Apparently -Werror is in the clang build options for XNU, but XNU is absolutely riddled with warnings (as you'd expect), so it just errors out.
You may think "why don't you just find -Werror and remove it?", and that's a great question! The answer is I couldn't find it (sobbing)
So i just kept compiling it and compiling it and adding -Wno-error=whatever to my clang flags every time an error came up that was actually a warning.
Here is the result of that lmfao:
$ make SDKROOT=macosx ARCH_CONFIGS=X86_64 KERNEL_CONFIGS=RELEASE CFLAGS_RELEASEX86_64="-Wno-error=unused-but-set-variable -Wno-error=four-char-constants -Wno-error=suggest-destructor-override -Wno-error=suggest-override -Wno-error=null-pointer-subtraction -Wno-error=void-pointer-to-int-cast -Wno-error=tautological-value-range-compare -Wno-error=unused-but-set-parameter -Wno-error=shorten-64-to-32 -Wno-error=undef-prefix -Wno-error=implicit-int-conversion -Wno-error=pointer-to-int-cast" CXXFLAGS_RELEASEX86_64="-Wno-error=unused-but-set-variable -Wno-error=four-char-constants -Wno-error=suggest-destructor-override -Wno-error=suggest-override -Wno-error=null-pointer-subtraction -Wno-error=void-pointer-to-int-cast -Wno-error=tautological-value-range-compare -Wno-error=unused-but-set-parameter -Wno-error=shorten-64-to-32 -Wno-error=undef-prefix -Wno-error=implicit-int-conversion -Wno-error=pointer-to-int-cast"

To remove the symlink you made earlier:
# rm /usr/local/bin/python

If you want to use a different build configuration than RELEASE, youll need to change KERNEL_CONFIGS, CFLAGS_RELEASEX86_64, and CXXFLAGS_RELEASEX86_64 to reflect that. In the case of the last two, you'll just need to change the names of the variables, not the actual value.

Hope this helps.

 

[CaseySJ]

Thank you! Incidentally, is this your blog post?

Building XNU for macOS 11.2 (Intel + Apple Silicon)

Compile open source XNU for Big Sur 11.2: arm64e + x86_64

kernelshaman.blogspot.com

 

[alyxferrari]

It isn't, I was trying to compile IOPCIFamily like 2 weeks ago, same as you, and went down a rabbit hole with this crap. I ended up using multiple sources (including that one) and had to troubleshoot a bit, this is what ended up working

 

[CaseySJ]

So you succeeded in building IOPCIFamily? That gives me hope!

 

[alyxferrari]

I didn't actually. That being said, I never ended up trying. I wish you good luck!

 

[alyxferrari]

@CaseySJ I got some bad news. An Apple employee replied to my forum post about this a week or so ago. I kind of forgot that I posted it. They're saying that the product types used by IOPCIFamily are only part of Apple's internal macOS SDK. https://developer.apple.com/forums/thread/718755

 

[CaseySJ]

@CaseySJ I got some bad news. An Apple employee replied to my forum post about this a week or so ago. I kind of forgot that I posted it. They're saying that the product types used by IOPCIFamily are only part of Apple's internal macOS SDK. https://developer.apple.com/forums/thread/718755

I saw that post a day or two ago. I am able to edit the Xcode project file and change the ProductType. But not sure if this will fix/bypass the "shallow" check.

 

[CaseySJ]

Just built the macOS Ventura 13.0 kernel successfully thanks to your guide!

I've been struggling with this for the past 3 days, so I'm just elated that the darn thing actually compiled and linked!

Let me provide a couple of build notes in the next post.

 

[alyxferrari]

That's great! Glad it helped

 

[CaseySJ]

Some Build Notes:​

First of all, thanks very much to @alyxferrari for posting the XNU build guide above. I am just stoked at the moment, having built the Ventura 13.0 kernel on my Ryzen 7 7700X (AM5). Some notes:

• When building the three components of dtrace (ctfmerge, ctfdump, ctfconvert), I ran into the following errors:

error: An empty identity is not valid when signing a binary for the product type 'Command-line Tool'. (in target 'ctfmerge' from project 'dtrace')
error: An empty identity is not valid when signing a binary for the product type 'Command-line Tool'. (in target 'ctfdump' from project 'dtrace')
error: An empty identity is not valid when signing a binary for the product type 'Command-line Tool'. (in target 'ctfconvert' from project 'dtrace')

• These were fixed by opening the Xcode project file in Xcode itself and changing the Code Signing Identity as shown.

• Once the build succeeds, we need to copy output files to the SDK platform path. The commands below did not work with Ventura, but the fix was simple:

// These didn't work with Ventura build
export TOOLCHAIN="cd $(xcrun -sdk macosx -show-sdk-platform-path)/../../Toolchains/XcodeDefault.xctoolchain && pwd"
sudo ditto "$PWD/dst/$TOOLCHAIN" "$TOOLCHAIN"

• In Ventura, the following can be done from the XNU source code folder to copy dtrace build components to platform Toolchains folder:

sudo ditto ./dst/usr/local $(xcrun -sdk macosx -show-sdk-platform-path)/../../Toolchains/XcodeDefault.xctoolchain/usr/

• There were no issues building AvailabilityVersions
• For the final step of building XNU, there was a simple problem that was equally simple to fix. The Xcode project calls python instead of python3. In my case there was no python, so the fix was simple:

cd /usr/local/bin
sudo ln -s python3 python

• This creates a symbolic link named python that points to python3.
• And after this, the XNU build flew by and finished successfully! There's the kernel:

casey@Caseys-Mac-Pro RELEASE_X86_64 %  ls -l
total 283792
-rw-r--r--   1 casey  staff    115918 Nov  5 09:39 SupportedKPIs-all-archs.txt
-rw-r--r--   1 casey  staff     13633 Nov  5 09:39 SupportedKPIs-x86_64.txt
-rw-r--r--   1 casey  staff      4463 Nov  5 09:38 all-alias.exp
-rw-r--r--   1 casey  staff    192752 Nov  5 09:38 all-kpi.exp
drwxr-xr-x  23 casey  staff       736 Nov  5 09:38 bsd
drwxr-xr-x  22 casey  staff       704 Nov  5 09:43 config
drwxr-xr-x   6 casey  staff       192 Nov  5 09:38 iokit
-rwxr-xr-x   1 casey  staff  19777840 Nov  5 09:39 kernel
-rw-r--r--   1 casey  staff  41077452 Nov  5 09:39 kernel.ctf
-rwxr-xr-x   1 casey  staff    545761 Nov  5 09:39 kernel.ctfdata
drwxr-xr-x   3 casey  staff        96 Nov  5 09:39 kernel.dSYM
-rwxr-xr-x   1 casey  staff  25379760 Nov  5 09:39 kernel.unstripped
-rw-r--r--   1 casey  staff       108 Nov  5 09:38 lastkernelconstructor.d
-rwxr-xr-x   1 casey  staff      2112 Nov  5 09:38 lastkernelconstructor.o
-rw-r--r--   1 casey  staff     16724 Nov  5 09:38 lastkerneldataconst.d
-rw-r--r--   1 casey  staff      7264 Nov  5 09:38 lastkerneldataconst.o
drwxr-xr-x   7 casey  staff       224 Nov  5 09:38 libkern
drwxr-xr-x   4 casey  staff       128 Nov  5 09:38 libsa
-rw-r--r--   1 casey  staff    101134 Nov  5 09:38 link.filelist
-rw-r--r--   1 casey  staff  57709696 Nov  5 09:39 lto.o
-rw-r--r--   1 casey  staff        74 Nov  5 09:38 nonlto.d
-rw-r--r--   1 casey  staff      1704 Nov  5 09:38 nonlto.o
drwxr-xr-x  28 casey  staff       896 Nov  5 09:38 osfmk
drwxr-xr-x   5 casey  staff       160 Nov  5 09:38 pexpert
drwxr-xr-x   6 casey  staff       192 Nov  5 09:38 san
drwxr-xr-x   4 casey  staff       128 Nov  5 09:38 security
-rw-r--r--   1 casey  staff    294524 Nov  5 09:38 symbolsets.plist
drwxr-xr-x   3 casey  staff        96 Nov  5 09:39 tools
-rw-r--r--@  1 casey  staff      2479 Nov  5 09:38 version.c
-rw-r--r--   1 casey  staff       299 Nov  5 09:38 version.d
-rw-r--r--   1 casey  staff      4240 Nov  5 09:38 version.o

 

[alyxferrari]

Oh, right! The Python issue happened to me too, I fixed it in the same way. I'll add it to the post. Kind of interesting that you had to edit dtrace and I didn't, though I was compiling the version bundled with macOS 11.6 (since I intended to compile IOPCIFamily from 11.6), so something probably just changed.

 

[CaseySJ]

@CaseySJ I got some bad news. An Apple employee replied to my forum post about this a week or so ago. I kind of forgot that I posted it. They're saying that the product types used by IOPCIFamily are only part of Apple's internal macOS SDK. https://developer.apple.com/forums/thread/718755

Well, I'll be darned...look at this:

/Users/casey/Downloads/Ventura/IOPCIFamily-IOPCIFamily-583.40.1/dst/System/Library/Extensions/IOPCIFamily.kext/Contents/MacOS
casey@Caseys-Mac-Pro MacOS % ls -l
total 3768
-rwxr-xr-x  1 casey  staff   395848 Nov  5 10:40 IOPCIFamily
-rwxr-xr-x  1 casey  staff   402680 Nov  5 10:40 IOPCIFamily_development
-rwxr-xr-x  1 casey  staff  1124528 Nov  5 10:40 IOPCIFamily_kasan
casey@Caseys-Mac-Pro MacOS %

IOPCIFamily for macOS 13.0 compiles successfully. I did have to make the following change in 3 places:

And I used this command line to invoke the build from the base folder of IOPCIFamily source tree:

xcodebuild install -sdk macosx ARCHS=x86_64 VALID_ARCHS=x86_64 -target IOPCIFamily DSTROOT=$PWD/dst

 

[alyxferrari]

That's awesome! Congrats mate! Did you have to do anything to link your IOPCIFamily environment to the XNU environment at all?

 

[CaseySJ]

That's awesome! Congrats mate! Did you have to do anything to link your IOPCIFamily environment to the XNU environment at all?

No, I just ran the xcodebuild command exactly as shown, and that was that!

It spit out some errors about being unable to change file ownerships, but those can be ignored and done manually. Just requires sudo.

 

[alyxferrari]

I wonder if just installing the XNU headers would have done it

 

[alyxferrari]

I guess the next step is to replace IOPCIFamily on a 13.0 installation with the open source build and see if it still boots.

 

[CaseySJ]

I guess the next step is to replace IOPCIFamily on a 13.0 installation with the open source build and see if it still boots.

Yes, exactly. I have a feeling OpenCore cannot replace this, but I'll try shortly. Have to step out for an appointment.

 

[alyxferrari]

Yeah, you'd probably have to disable SIP and replace it in /S/L/E

 

[CaseySJ]

Yeah, you'd probably disable SIP and replace it in /S/L/E

Yes, I've done this before by importing IOPCIFamily and AppleACPIPlatform from Big Sur and injecting them into Monterey via a new system snapshot. But this is a bit inconvenient for most people. If we can find an easier way, that would of course be ideal.

But I'll test both methods today:

1. Use OpenCore to replace IOPCIFamily
2. Replace IOPCIFamily via new snapshot

 

[Shaneee]

OpenCore should be able to replace the kext if the patched version is given a higher version number. I remember back in the Chameleon/Enoch boot loader days you'd changed your modified kext to v99.99 and inject it via Extra/Extensions to overwrite the original in the caches.