Hacker News Reader

Comment by jsheard | Hacker News Reader

Does anyone know if M3 support is likely to lead to M4 or M5 support in relatively short order? AIUI M3 took a long time because it was a substantial departure from M1/M2, especially in the GPU architecture, but I don't know if M4 or M5 made similar leaps.

View on HN

The main reason M3 took a long time isn't related to m3 itself, but rather that the asahi project took on a ton of tech debt to get M1/M2 working. M3 wasn't too difficult, but before taking on the additional tech debt, the Asahi team focused on getting all of their changes upstreamed to the linux kernel.

The main developer was also the target of a harassment campaign from a place that has pushed other targets to straight up suicide. That took almost all of their energy for the last year and they ended up quitting.

   > The main developer was also the target of a harassment campaign from a place that has pushed other targets to straight up suicide.

Is this the Torvalds/Hector dispute that comes on the Google AI summary, or was this a three-letter agency type of harassment faced by Aaron Swartz?

Neither actually... It was an anti trans/kiwi farms brigade...

The Torvalds dispute probably came about in part because of defensive behavior triggered this brigade but was really unrelated.

Anti-trans hate.

Trans hate.

GP definitely meant the same thing, i.e. 'hate [that is] anti-transsexualism' to your 'hate [against] transsexualism'.

FYI, transsexual is an outdated term, with transgender being generally preferred instead :)

AFAIK they also were focusing on upstream the changes into the kernel [0], because the amount of downstream patches they were maintaining were making the work harder and harder.

[0] https://asahilinux.org/2025/10/progress-report-6-17/

Prognosis is then that work for m4/m5 should be relatively straight line now that refactoring is done?

M4 is apparently even harder because of some new hardware-level page table protections.

Source from Asahi contributor: https://social.treehouse.systems/@sven/114278224116678776

Memory Integrity Enforcement, perhaps?

https://security.apple.com/blog/memory-integrity-enforcement...

It's "Secure Page Table Monitor". https://support.apple.com/en-il/guide/security/sec8b776536b/.... The kernel requires it so they need to emulate SPTM.

This is not exactly correct. They wouldn’t need to emulate SPTM, since SPTM is already running. And to be very correct, SPTM is a “process” running in a separate privilege level to the regular privilege levels found on arm processors. The reason it’s a pain is because pre M4 the bootloader gave you complete control over the CPU, including the Apple-exclusive extensions like GLx, the special privilege levels e.g. SPTM is running at. Since M4 the bootloader handles that, so asahi team has to either cope with being dropped after GL is already initialized and locked down, or running in a mode with all of Apple extensions disabled. So it’s not a problem for running Linux, but it’s a problem for running macOS with a thin abstraction layer to intercept talking with devices like the GPU, which made reverse engineering for them significantly easier.

Afaik this isn’t quite correct either. From what I could gather from the CCC talk and forum posts:

The Apple specific instructions to talk to the SPTM are only usable in the GL2 privilege level, not EL2 where you end up after booting non-Apple code.

The problem is the macOS kernel uses these custom instructions to manage its own page table mappings, and when being virtualized in EL2 it just crashes since these instructions are now invalid.

The solution is indeed to emulate the SPTM interface and instructions just enough for macOS to not crash, that way it can be virtualized for reverse engineering. The emulated SPTM could just pass through the mappings, ignoring all of the security checks the real one would normally do.

I was able to find quite a bit of existing SPTM analysis online (I believe from iOS security research) so this issue isn’t insurmountable by any means.

Knowing how it works does not mean it can be emulated perfectly.

From our knowing how it works [0] it’s just a mechanism for the kernel to give up some privileges and add extra security checks when modifying page tables. Sounds easy to emulate to me: just don’t do the checks and modify the page tables directly. Do you have some reason to believe it can’t be emulated?

If for some reason it’s difficult, the relevant kernel code could also be hooked or patched.

[0] https://arxiv.org/abs/2510.09272

Thanks!

The M5 reportedly has a newer generation GPU compared to the M3/M4. For one thing, the GPU-side Neural Accelerators are obviously new to the M5 series. Other stuff is harder to know for sure until it gets looked into from a technical POV.

It’s not like neural accelerators on non-Apple consumer hardware get much use on Linux, either, so that does not sound like much of a dealbreaker.

The matrix/tensor math units added to GPUs do see widespread use, both for running LLMs and for the ML-based upscaling used by most video games these days (eg. NVIDIA DLSS). The NPUs that are separate from the GPU and designed more with efficiency in mind rather than raw performance are a different thing, and that's what's still looking for a killer app in spite of all the marketing effort.

Reply on news.ycombinator.com