Building XNU for macOS 11.2 (Intel and Apple Silicon) | Hacker News Reader

Building XNU for macOS 11.2 (Intel and Apple Silicon)

kernelshaman.blogspot.com

67 pointsmrpippy30 comments

Apparently there a decent chunk of the Apple Silicon files come in the form of binary files which seem to fall under the APSL. From the sounds of it, the binaries may be quite useful for reverse engineering and putting to use in the Linux port.

From Marcan (who is porting Linux to the M1)

> Wait no, hold on, WTF. They do supoprt M1. Just not in source code. They freaking bundled some .a files with uncensored binaries of the parts of xnu that need to support M1.

More details here:

https://twitter.com/marcan42/status/1355907973776723971

While the binaries aren't quite as nice as source, its a good basis for reverse engineering some of the M1 specific code needed.

The 11.1 source included the blobs as .a files, ostensibly APSL licensed. The 11.2 source moved those to the KDK (this is what the article is talking about), so they are no longer APSL, and further censored the source in the actual XNU open source release.

It is quite evident at this stage that this is somehow related to ARM. They must not like Apple adding nonstandard extensions to the ISA, and they want them to hide them all.

The good news is we don't have to care, and the (accidentally or not) "APSL" blob release gives everyone license to reverse engineer them, since it's not under an EULA.

Love to know how/ why this got pushed out. If it's a rogue engineer, a mistake, or what exactly.

Regardless, you can't put the cat back in the bag.

Sounds like Apple wants to promote or enable development on its new platform (even of 3rd party kernels), but can’t just distribute source due to some ARM licensing agreements or other legal/contractual restrictions. This is probably a middle ground through legal.

IANAL, but I think they could retroactively claim the code in the archive was not legally their right to push under that license. That is the same principle that stops me from going further, say, and copying their APSL code into a GPL program, and then claiming the whole XNU source is now completely free and no-take-backs. So it depends on whether they owned the copyright to the original source, and also that the published bundle was authorized by Apple to provide that content. Absent timely clarification from any party, however, I think we can assume it is out in the open.

They aren't/ can't use the code in any case.

They can use it to see how it was done and create an alternate implementation without using any of the original code/ binaries. Worse case, they can build a model of what is done and describe that to a third party who has never had access to the code in question. Essentially forming an information firewall.

The code is theirs. All evidence points to this being about contractual obligations with ARM, but those would not be about copyright.

All the Darwin 0.1 and 0.3 stuff has effectively been wiped.. I only got lucky with people hoarding CD’s but there is no 0.2 stuff.

The amount of stuff released was shrinking by the release so did they cancel the 1.0 and 1.1 license or do they just pretend it didn’t happen? This is a 4.4BSD so there was the shadow of the AT&T vs CSRG/BSDi

I’ve received no CDL...

What makes you think that Apple needs to care what ARM thinks? All signs point to Apple having fairly strong influence on what is allowed by licensees, and obfuscating and hiding their proprietary security features is something that Apple does literally all the time…

There are some TSO-related preprocessor macros that are still there.

He is still working on porting Linux? I’m pretty sure it already has been done. https://twitter.com/cmwdotme/status/1355660127433535490?s=21

They have linux booting on bare metal.

Still to be done:

  - GPU drivers
  - Wifi/ network drivers
  - Power management
  - Getting the GUI online
  - Audio
  - Bluetooth
  - Webcam

Extra credit:

  - Fingerprint scanner (This may never be possible due to Secure Enclave)
  - Neural Engine support
  - ??? other M1 extensions

It says WiFi/Ethernet is done. It also looks like Power management is done? Getting GUI online? The pictures show a full desktop working.

They have a desktop running on simplefb. That is not a usable desktop (no matter what they say), with zero acceleration and all completely software rendered. There is literally no graphics or display driver. The bootloader gives you a chunk of RAM that is the screen and you write stuff to it. No multidisplay, no resolution switching, no hotplugging, no acceleration. It's like running x86 linux on efifb with no radeon/intel/nvidia drivers at all. Think vesafb for those old enough to remember those days, but even dumber - at least on that one you could pick a resolution.

Our kernel has simplefb support too, literally all you need to do is write 5 lines of devicetree properties to get that to work - zero patches needed to the upstream simplefb driver. Here is the code in our bootloader that takes the Apple framebuffer information and stuffs it in the DT for Linux to use it:

https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59

That's literally all you need to get "graphics".

I was actually planning on doing exactly the demo that they did since December, with a simplefb "full Ubuntu desktop" and everything else running off of USB, for the clickbait, because it's flashy even though it's a minimal amount of work, but with a clear disclaimer that it's a tech demo and there is a lot of work left to do. It certainly brings in the news. However, it is not a "fully usable Linux desktop".

FWIW: WiFi is Broadcom FullMAC (existing Linux driver) with some patches. Ethernet is a Broadcom chip over PCIe (once you have PCIe up, the driver is there). USB is DWC3 (existing Linux driver) with just an Apple PHY adaptation layer. Storage is NVMe with Apple hacks and a horrible (definitely not upstreamable) hack Corellium wrote to fake a PCIe bus because the Linux NVMe driver assumes PCIe. Please don't assume they are cranking out bespoke drivers every other day; most of their work is simple drivers and patches to existing ones. There is certainly work involved in figuring out all these Apple oddities, but these aren't new drivers.

I fully intend to support the SEP in our kernel once we get that far, with Touch ID for Linux log-in/unlock and also things like storing and using SSH keys within the SEP (think built-in YubiKey). Lots of reversing to be done, but all of this is in scope for our project. Drop by our IRC if you'd like to help out :)

> but these aren't new drivers.

The GPU is probably going to be the monster here, unless you have found that it bears similarly to something else?

And Bluetooth. Bluetooth is always a joke.

Indeed, the GPU is likely going to be more work than everything else combined. We already have Alyssa Rosenzweig from panfrost working on that, and some other mesa folks. I'll be doing kernel work; I have some experience with Radeon GPU kernel-side drivers to lean on.

Alyssa already got her first triangle rendered the other day (from macOS, but without using any macOS Metal frameworks):

https://rosenzweig.io/blog/asahi-gpu-part-2.html

Kernel work is blocked on the lower levels of the kernel being solid first, but I'll be jumping on that as soon as I can.

Bluetooth is just Broadcom again. I think it's the usual UART HCI stuff? I saw a Corellium patch fly by to their UART driver related to that I think, adding hardware flow control support? That driver is a waste of time; I don't know why but Corellium are writing bespoke drivers for some (simple) hardware that already has near-compatible Linux drivers (PASemi I2C is another one). I already added M1 support to the Samsung UART driver in Linux in ~200 lines of patch, and that has more features that Corellium's bespoke >600 line driver. It seems in general they're happy to waste time on code and approaches that will never make it to upstream Linux without a complete rewrite/rethink... which speaks about their approach to this.

Ok, on the I2C driver because you are saying that:

A separate I2C driver was done because the PA Semi one is polled, not interrupt-driven.

Polling to wait on a slow bus such as I2C is brutal. And we don't know if the original PA Semi hardware even supports being interrupt-driven (in the same way?).

As such the drivers don't even have much in common here.

This is exactly why you talk to the author of the existing driver, and/or the maintainer if someone else, to figure out what to do and how to avoid code duplication.

That's what they aren't doing. Talking to anyone.

Sounds like support is further along than I thought!

I'm pretty sure the graphics support is frame buffer only at this point though.

The goal of the Asahi Linux project is to develop clean, maintainable, upstreamed, first-class support for Apple Silicon on Linux, that works as well or better than Linux on x86. From the beginning I said we weren't going for a tech demo, but for the long-term product.

We are also documenting the hardware here: https://github.com/AsahiLinux/docs/wiki

I don't know what Corellium's goal is, since it isn't clear what they get out of this as a company other than PR, nor have they interacted with the open source community in any way whatsoever to date (I publicly invited them to our IRC channels and they've yet to show up), nor attempted to upstream any of their work (a third party has and that didn't go so well for the first version). They seem to be going for the tech demos and PR angle, judging by their actions and codebase so far :)

E.g I spent most of Saturday debugging the source of L2 memory subsystem bus error exceptions in our bootloader, m1n1. Corellium's codebase and preloader just turns off reporting those errors entirely, all the way into Linux. There are very, very different approaches going on here.

FWIW, Corellium had been developing their kernel in secret for A14 devices (that's the extremely similar iPhone version of the M1) for months now, plus had previous versions for older Apple SoCs, so it's not like they did this in two weeks; rather that they are currently piecewise releasing and adapting code they've had for a while and developed on jailbroken devices, while we/Asahi Linux started from scratch mid-January when Apple finally published the tools to run your own kernels on M1 Macs.

I'm happy to pull any drivers they develop and release that are clean and upstreamable, but we're working step by step and I'm not in a race with them; we're in this for the long run and I want to make sure anything we work on is the right way of doing things.

We're also working on GPU acceleration, which is a hard requirement for a usable desktop, and which as far as I know Corellium have nothing on. Alyssa is working on the userspace side already; I'll jump on the kernel side as soon as the necessary kernel dependencies are in.

I'm currently writing a quick start guide to help other kernel devs with interest get started with development, and in the coming weeks I will be taking some time to develop an open hardware design for a serial debug cable for these machines, and building some prototypes to send to other kernel devs to help bootstrap community members who want to help. Today I'm also working on using one M1 machine as a serial terminal for another, with a standard type C cable (it should be possible AIUI, but I need to reverse engineer some details to get the right commands sent to the Type C controller) - not the cheapest solution but certainly the lowest effort one right now, if you have the money for two M1 boxes.

I'm always wondering if there's a legit straight up M1 simulator (including gpu) that runs on x86 inside the bowels of Apple somewhere.

Like a 1/3 speed M1 simulator that runs on a 28 core x86 Mac Pro.

In all the ways of bringing up software/OS's on a platform, there's always someone in the core team who goes for the "write a simulator, and use that to bootstrap the software for the hardware" path.

Well, Apple has been shipping ARM devices running XNU for the past fourteen years so there’s probably little value in a simulator when they can use real hardware.

Apple uses simulators for bringup, there are references to a “fastsim” (probably an FPGA?) sprinkled in the open source releases, with special debug instructions encoded as hints (for tracing presumably).

This is pretty exciting! I've been wanting to mess around with Darwin without having to own a Mac; FreeBSD features on a microkernel sounds potentially really nice. Trying to bootstrap up from the last available ISOs is terrible though; they're from over a decade ago, for i686...

It's not really being used as a microkernel though

My understanding (as someone who doesn't run nor code for Darwin, yet at least) is that it's totally possible to use the microkernely features in userspace right up until you need to do a syscall, and even then you can have a task that translates port messages to traditional syscalls.

I guess I care less about a microkernel's advantages for kernel development, than it having non-broken IPC :P

> it's totally possible to use the microkernely features in userspace right up until you need to do a syscall

XNU has two sets of syscalls – Mach syscalls (negative syscall numbers) and BSD syscalls (positive syscall numbers). The Mach ones expose the classic Mach "microkernely" API, and the BSD ones provide the traditional POSIX API

The term "syscall" is a bit ambiguous – sometimes it is said that the BSD side has syscalls but the Mach side has traps, other times it is said that BSD syscalls and Mach traps are the two different types of XNU syscalls.

Definitely the BSD syscalls include a bunch invented by Apple themselves (not inherited from *BSD), and I think the same is the case for the Mach traps as well

It’s always been “possible “ but it’s always been a massive pain in the butt as there is a lot of inside track stuff, and the public source always has a habit of depending on itself.

It was a massive chore to get Darwin 0.1 to build for x86 but it’s possible. And there is 2 things only available as a binary blob, the intel PCMCIA code was never released nor the EISA/PCI adaption layer.

I have some qemu images here:

https://sourceforge.net/projects/aapl-darwin/

In the early 2000s some people tried to build distros around it. Here it is running Gnome in 2004: https://commons.m.wikimedia.org/wiki/File:GNOME_2_running_on...

In those days there was a bit more optimism about such things but it was sort of like "why not just use Linux"? I think, iirc from reading tech news back then, there were also complaints about the quality and quantity of what Apple was releasing in source form.

Xmxinx

| Xmxinx means XNU is not Xinu

| Xmxinx means Xinu is not XNU

https://en.m.wikipedia.org/wiki/Xinu

Reply on news.ycombinator.com