Apple rearranged its XNU kernel with exclaves | Hacker News Reader

Apple rearranged its XNU kernel with exclaves

theregister.com

111 pointsfork-bomber17 comments

Isolating things is easy; engineering them to still work is the hard part. If the engineering was easy then every OS would isolate every operation and memory space, and Apple would have isolated these things long ago. But that's not possible because of the performance hit and because of the practicality of using 'perfect security' (it becomes secure even from developers and users).

How does Apple choose what to isolate, and how do they make the isolated parts functional with the rest of the system and for developers? And what changed to make it possible now?

The other submission should answer your questions: https://news.ycombinator.com/item?id=43314657

Like with SELinux where it is such a pain to get anything working everyone just turns it off.

People turn it off these days because their fear of the level of pain is disproportionate to the effort to get it working. The reference policy covers 99% of most peoples needs.

That may be true but if you've been burnt enough over several years that it seemed to cover 1% of people's needs you just put it on the trash pile.

Those people were throwing out the stove instead of learning how to adjust the temperature.

May 2024, https://mastodon.social/@_inside/112440596781136013

> It looks like iPadOS running on M4 has a “Secure Exclave” running an “ExclaveOS”.. Where’s the updated Apple platform security PDF? ... There's a Wordle-like game hidden in ExclaveOS. "Securdle"

Original article: https://randomaugustine.medium.com/on-apple-exclaves-d683a2c...

So it's kind of like Android using pKVM to run VMs that the host can't access?

I think the concept is similar, a hypervisor-based trusted execution environment which is isolated from both other VMs and the parallel guest/"main" kernel. The Apple environment seems more like a Secure World / TEE, with a single supervisor running multiple trusted applications, versus Google's implementation, which revolves around fully isolated VMs running their own time slicing (in many cases, even running Microdroid). Although, of course a lot of this comes down to semantics about what you call the "hypervisor."

I'm not sure what Google actually use pKVMs for, though - certainly stuff that Apple handle through Exclaves like the camera icon is still just in "privileged" userland in Android (the camera icon, specifically, is PrivacyDotViewController in SystemUI).

Google has some documentation about their virtualisation setup: https://source.android.com/docs/core/virtualization

From what I've read, I interpret it as pKVMs being intended to work like ARM's TrustZone, except without the dependency for paying bank to ARM and early-boot initialisation shenanigans. The way AVF exposes large parts of the Android API will allow future Android versions to be rewritten into many small modules all running in a QubesOS-like hypervisor setup without rewriting them from the ground up. I don't think that's implemented at the moment, though, or if this is only intended for a few specific Android components.

> not sure what Google actually use pKVMs for

Android 16 and last week's Pixel Android 15 update (behind developer options) includes pKVM Debian Linux Terminal "app", https://www.zdnet.com/article/your-android-phone-will-run-de...

Pixel 8+ can drive external displays via USB-c DisplayPort, so it should eventually be possible to use pKVM + Pixel 8+ with a keyboard-video-mouse dock as a desktop.

Funnily enough, Samsung already had this for a while on their phones (with Ubuntu rather than Debian), but they have since stopped experimenting with that.

I think the desktop docking system will probably be something like a ChromeOS VM rather than normal Linux. Using dev mode so that Termux is no longer needed for running Linux tools would be nice, though.

Seems like it but it doesn't seem to require redundant kernels/os images. pkvm is pretty heavy in terms of memory usage in the context of a phone.

I think so, but with explicit hardware support?

Reading this, a bit off-topic and odd software-building-related question came to my mind: Between building and maintaining macOS + iOS vs. building and maintaining Chromium > Chrome, which do you think is more complex, requires more developer hours, and demands more advanced developer skills?

It depends how you count the boundaries of those projects. Does the "effort to develop" Chrome include all the work that went into WebKit (which Chrome was originally based on)? Does iOS include the bundled apps that ship with it? Does macOS include the drivers written for hardware support?

I'm certain that if you go beyond the core kernel and add in device drivers, UI layers, and user space bundled apps, macOS+iOS are far more complicated than Chrome. After all, Safari is bundled with the OS and that itself is comparable in complexity.

But if you were to strip Apple's operating systems down to the core XNU kernel, then I think Chrome is likely more complex. There are plenty of usable kernels out there, but very few usable browser engines that can handle the modern web.

Reply on news.ycombinator.com