If Apple open sourced its drivers this issue wouldn't exist. AI at last gives the "community" a chance to use the hardware they bought the way they want. It's unreasonable to expect anybody to code this kind of stuff "by hand" when automated tools exist.

I find it extremely ironic that big corp openly steals IP en masse to build their models but hackers are still concerned about using same models for their reverse engineering work.

I think at this point the hacking community needs to grow some balls.

I certainly dont care about hiding LLM contributions and all crazy anti-LLM policies, but I really hope author can share process completely so this can be reproduced by someone not working for Apple.

Even if this is the case, this is still a valuable contribution to learn upon.

Now that this work is done and out in the open what in theory would prevent the next generation of LLMs from ingesting it and eventually a non-Apple employee creating yet another driver “from scratch” but with the knowledge of how the hardware works acquired from an LLM or with the help of one?

Basically, aren’t we facing a situation where LLM-assisted knowledge laundering is becoming a thing?

Linking to another HN comment: https://news.ycombinator.com/item?id=49719480

There were and are many important pieces of Linux kernel that live out of tree; ZFS is a big example.

The problem with this driver is not licensing or code quality; I assume it's under a threat of receiving C&D letter, or maybe also a legal suit for breaking some NDA.

Very sad. I really want to get Linux on newer Apple chips working flawlessly but I can understand the legal minefield about this particular work.

I’m sure it’s really easy when you can get help from the people who made the chip or write the Apple drivers.

Might be one of the only use cases where LLMs are necessary to succeed. Can't imagine the pain of reverse engineering a technology of this scale and "secrecy".

The problem I’m finding, at least with today’s models, is that it produces disposable software. It’s not good at making well-architected, durable software. Stuff that could be maintained and bug-fixed.

I mean you can get good stuff out of it if you know what you are doing and guide it, but if you just say “here’s a regression suite. Write an implementation that passes” you will get something that works for a while but ages quickly and will need to be thrown away.

:) I think we have a surprise in store here. Asahi don't have a monopoly over Linux for Apple Silicon, and upstream Linux absolutely does *NOT* ban LLMs.

Asahi's long term goal is to get everything possible merged into the (actually) upstream projects anyways so any distro can just work. It'd be nice to see that continue rather than have forks on forks for the sake of singular differences (and it looks like proper upstreaming is what they are going after per the Remaining Work section).

I imagine either they or others can take their discoveries and write a real driver now, though. The hard part was always the reversing the black box system.

I still can't quite believe it either!

Great observation, two things:

- During my time at Apple I never saw any of the macOS source code, at all, even for userspace components. I had not even heard of things like SPTM.

- I have not worked there since June 2025

I don't believe that there's any risk due to my former Apple employment. As another example, WINE does not ban all former Microsoft employees, they just ban anyone who has ever looked at the Windows source code. If I felt there was even a chance that my employment at Apple may have exposed me to relevant internal secrets, I would refrain from contributing to community projects.

For the kernel driver it's literally just: run the hypervisor, wait for the kick, save the UAT state, replay the whole thing, make sure the output pages change, then just follow the pointer to initdata until you've built the whole tree from scratch. LLM handles the rest.

TL;DR:

1. We want to guarantee our work is not a "derivative work" of anything Apple wrote.

2. If we look at any Apple binaries, there's no way prove that our code didn't borrow from Apple.

3. Since we didn't look at any Apple binaries, then there's no way our work can be a derivative work-- we didn't even look at their stuff.

The previous “Part 1” post is very candid about the approach, and the titles of both posts mention prompting.

Claude models were blocked from logging into my own VM with my own credentials I gave it using ssh that I also gave it by its guard rails. I wouldn't doubt other models are nerfed but...you should provide some context around your comment

Can't disagree more, but my experiences are my own.

proof?