> It runs in a privileged environment separate from the kernel and blits the light directly onto the screen hardware.

That explains how it can still be safe from even kernel-level exploits. Neat approach, and it works for the microphone light too.

I guess this means the listener for Hey Siri requests has to be inside of the exclave/conclave to avoid triggering the mic indicator light 24/7 or leaking microphone data? I assume this means the code has to be able to be updated through various macOS/iOS updates and is not immutable, so I do wonder how the code signature verification for that works (since I assume the code signing checks would have to be done at a hardware/bootloader level above the kernel)

I also assume this means you can't put the mouse cursor over the camera indicator as well since that can be controlled by the kernel/host (if someone here has a Macbook Neo pls confirm).

My understanding is that certain processes which are cut and dry and important are beginning to be handled by separate onchip circuits. For example, the MMU page tables and TLB are no longer directly accessible from the chip; you have to message them like an abstract data structure, even inside the kernel. So in theory there is no exploit.

Now Apple keeps moving more and more into what is essentially not software anymore. Parts of the renderer are abstracted. Perhaps there are validation routines for some kind of custom microcode that Apple is totally sure can not be compromised, the way we imagine a binary tree cannot be compromised as long as you use the approved methods of the class.

For this they get security, and probably can design optimized purpose-built silicon that travels from process to process.

I’m not saying exclaves are insecure, but how much of it is just a separate firmware based on undocumented procedures? If someone finds the secret key, can they overwrite the microcode, or is it really and truly permanent?

This is like trying to read text on the side of a match stick.