Claude Design, the only Anthropic product I genuinely like. I spent a LOT of time on those, so I'm glad you enjoyed them! I'm about the least artistic person you ever met in your life (everything in my life is very functional and very unaesthetic) so I'm a rather big AI design tool enjoyer.
Right now I'm focusing specifically on the M4 Mac Mini and Neo, I just don't own any M4 Pro or Max hardware. My guess is that most of the drivers will just work on the other platforms, but we'll have to test.
> concealing that he is a former Apple engineer with direct contacts to the people involved in Apple Silicon development
This is false. I am a former Apple engineer. I did not conceal it (it's the top item of my resume and my LinkedIn and I made my PR from my public Github with my name attached, as opposed to a pseudonym which is expressly allowed by Asahi policy). I also had no exposure, at all, to any internal information or code about macOS, SPTM, or Apple Silicon during my time there.
I also don't have connections to people involved in Apple Silicon development (and I'd add that this does not mean someone cannot contribute, the question is were they exposed to tainted information, which is absolutely not true in my case). I have many friends who work for Apple (I'm a Stanford alum) but none in Apple Silicon directly.
I disagree with the phrasing of this entire thing, but this statement is demonstrably false.
Would you consider taking all of your learnings and translate them into a concrete specification and publish it on your website, so that we can all do our own clean-room from-spec-only implementation?
The friend I am referring to I met at Stanford around April of 2026 in a dorm event. We've spoken in person exactly once (I use "friend" loosely to describe anyone I've spoken to who I'm not on bad terms with) and at no point did we discuss anything detailed about Apple Silicon. For further context, I left Apple in June of 2025.
Spend enough time in tech and you'll know lots of people who know both technical and business secrets and are under various levels of NDAs. The message you link to explicitly mentions only public info was exchanged. Just talking to someone is not an indication of infringement in any way.
I think this comment is missing the forest for the trees. Obviously, ephemeral interaction is going to happen.
The author’s blogpost is sloppy and has some signs of being AI written. This kind of bleeds into the main point I’m going to make.
Asahi Linux folks are clearly more conservative and erring on the side of caution, so, this means that the glibness with which the author is treating any of this is probably sufficient cause to refuse his entries. It is unclear if LLMs should be considered a toxic waste dump in terms of trying to maintain a clean room. We have not established a standard. It is clear the author doesn’t think this is a big deal, so that’s one conflict. The other conflict is that it is not clear what their exact interactions with Apple Silicon folks is and their glibness of it doesn’t clarify anything.
If you take a group that is trying to be very careful about the potential legal landmines a still nascent technology has and you get someone that espouses a general glibness about those concerns wanting to merge code…why on earth would you expect that group to accept them as a contributor?
This is not to say this isn’t really cool and a neat use of LLMs, but it is totally understandable why Asahi Linux won’t accept the fruits of this kind of development. If it turns out that Apple can identify its non-OSS code in this, it’ll be a mess.
> Asahi Linux folks are clearly more conservative and erring on the side of caution
I mean they are working around and on hardware controlled by a nearly 5 trillion market cap behemoth who has resources on the level of some nation states.
I'd be erring on the side of caution as well if they could hire that many lawyers.
> <StanfordAppliedCyber[m]> one of my friends is a very senior engineer who lead a lot of the sptm work and controls a lot of boot, may talk to him about it (obviously he hasn't told me anything that isn't public)
You are accusing someone by twisting their own words about their own self disclosed identity against them from a throwaway account created 5 hours ago.
And they say irony is dead.
I say this from an anonymous account but at least it isn't a throwaway. And at least I have the good taste to feel a little shame for my hypocrisy.
CA v. Altai (where the abstraction-filteration-comparison principle comes from) and SAS v. World provide pretty strong positive evidence that clean room is a valuable technique in both the US and Europe.
I do agree with you that the term is misused (it’s almost completely irrelevant here, anyway) and over-applied, but “not having ever been in a position to see or access the source code” is proven, especially in SAS v World, to be a pretty strong defense that’s worth pursuing in some re-implementation scenarios.
>No statute defines "clean room RE" and there's basically no relevant litigation establishing case law.
You seem confused here? "Clean Room RE" is simply a descriptive result of copyright law in the US, and is well established. In the US there is no "sweat of the brow doctrine", pure facts simply cannot be copyrighted at all, nor underlying methods/ideas (that's patents). And as a direct result of the latter, again unlike patents, if two people truly independently write the same thing, both get separate copyright.
"Clean room reverse engineering" is just applying that to make any legal fight much cheaper or discourage it from every being bothered with in the first place. You have an RE "dirty" team that goes through copyrighted software and makes a specification that is purely factual, ie, "function 1 takes (int16)X input and does equation ABC on it, function 2 takes (long)X & (long)Y inputs and does LMN" etc. A factual/math spec like that cannot be copyrighted, so it breaks any derivation chain. They then give that, and only that with no other communications, to the clean team. If someone with no other exposure to the software being RE'd uses that spec to write a new piece of software themselves, then by definition the result cannot have any copyright of the original. It's a brand new work based off a list of uncopyrightable facts & math/ideas (though worth noting it could still get tripped up by abomination that is software patents).
There are other ways to argue against copyright infringement successfully, but they're much more subjective, which legally speaking reads "expensive, uncertain". CRRE simply trades that for two clear binary questions: was the spec copyrightable, and did the people writing a new piece of software from that spec have any previous exposure to the original? If the answers to that are no, then all arguments about function names being similar or whatever are no longer relevant.
On the subject of LLMs, one curious twist is that proprietary software might have less effective protection then open source depending on how it all goes. A coding LLM almost certain trained on all open source software available on the web. So there's at least some argument it's tainted. But proprietary software is proprietary. If the LLM has never had any of the source code in its training input, then isn't it clean in terms of producing anything derivative of that? That'll be kinda interesting, and might leave some companies with a bit of a conundrum (or I guess pushing the patent side even harder, but that has a much more sane 20 year expiration date vs copyright).
Absence of evidence isn't evidence of absence. "Not getting sued" doesn't validate a legal theory - legal theories are validated in court where they become case law. Until then, they are plainly speculative.
This "clean room RE" fabrication is also not something so obviously compelling that nobody would ever attempt to challenge it - it's just that nobody has cared to put dollars behind it. IP provenance cases are enormously difficult to prove and are almost always settled ahead of trial. This concept is software engineer folklore more than anything.
Saying you won't believe it's effective at all until someone sues and loses isn't the most compelling argument. If nobody sues then yes that is some evidence of effectiveness. It's not an absence of evidence, you're misusing that line.
It's a defense. It's like having a moat around your castle. You don't need a moat to repel invaders since you also have a wall, and you might not get invaded anyway.
There's no law saying you have to do clean room RE. It's legal for me to look at a decompiled driver and write my own driver from scratch. It's not legal for me to just copy the decompilation, and a clean room environment is solid proof that it wasn't copied, but it's not the only way to not copy it, since I could also just not copy it.
But there are plenty of successful projects which would probably have been taken down if it wasn't for clean room RE. I mean just look at the clean room IBM BIOS clones from "IBM compatibles" in the early days of the personal computer.
The background level of software copyright legal actions is significant enough. If plane attacks happened that much then it would give us solid evidence of TSA effectiveness even if they never caught anyone directly.
Nintendo doesn't care. There's been proprietary Nintendo SDK code in libogc (open source library for making GameCube homebrew) for years. And more recently the various decompilation process have made recreations of linked code from the SDK that compile match byte for byte. In practice the legal risk of being sued into oblivion for this is not there. If anything there would be a DMCA takedown / cease and desist.
Right, but they are one of the biggest DMCA abusers. They killed many fan projects. They killed game renting in Japan as a concept. They killed Yuzu (a Switch emulator). And they could change their mind at any time.
> For the record Yuzu included code for circumventing Nintendo's DRM they had on game carts. It violated the DMCA.
It doesn't, this is what Nintendo claimed but it's false. The community learned their lessons from the Wii emulation era and you are supposed to bring your own keys, nothing is included in the emulator.
And yes, they also wrote this lie on their DMCA takedown against Suyu (which also doesn't have any keys), so they officially lied on a DMCA takedown.
There's no "circumvention mesure" in there, the emulator can only read unencrypted games by default. You won't find anything in the source code, if the game is encrypted, it cannot read it.
I disagree, this doesn't break anything, even the comments tell you so. This code does nothing by default.
Also I may mention that the support of external keys is there for you to get games for your own switch, pirates can just share decrypted games anyways.
Do you not see the references to decryption and decryption keys? This code is explicitly written to break the DRM of switch carts. If you mean by default you mean they don't provide a key, that doesn't matter in regards to it being considered corcumvention.
No that matters. As is, the emulator cannot be used to circumvent nor break any protection. Feel free to try it yourself, boot up the emulator, give it an encrypted game and see what it does.
Nintendo didn't want to get in court and also had to basically lie in a DMCA, I think that tells it all on their legal standpoint, they were afraid of creating a precedent.
Don't worry that if they were so sure to win, they would be in court already like they did with the R4 cartridge.
There's also been Wii games rereleased on PC with all debug symbols that cover the Wii parts that were still compiled in. You'd get mostly type names, enums, object layouts and function signatures that way.
there isn't ?? I sorta thought we figured all this out decades ago when SMB and DeCSS were being reversed? I think dosemu or something as well ?
I seem to recall DeCSS being the 'hot button' as it was RE'd in a 'non clean' way, the code released, and then a 'clean room' RE could be made from the 'public' info ??
edit: actually, at the time I think there was German law allowing RE for 'interoperablity' or some such. But that was a long time ago so my memory might be off.
> No statute defines "clean room RE" and there's basically no relevant litigation establishing case law.
It doesn't really make sense for it to be in a statute or in case law.
When you are a copyright infringement defendant the plaintiff has the burden of proving two things: (1) that they have valid and enforceable copyright rights, and (2) that you infringed those rights.
Direct proof of the later is rare, so they usually prove infringement by showing you had access to the work and that your alleged infringing work is substantially similar.
There are some defenses in the statute, such as fair use. With these defenses you are basically saying "Even if they prove everything that normally would prove they case, there is this exception that says in these circumstances I'm allowed to do that". (That's called an affirmative defense).
There are also affirmative defenses that were developed in case law. First sale doctrine was originally a case law developed affirmative defense, but was later incorporated in the statute. Copyright misuse is another case law affirmative defense. That one has not been incorporated into statute.
There are also non-affirmative defenses, often called negative defenses or failure-of-proof defenses. With these your defense it "They can't prove I did this thing that is necessary for them to win".
Clean room implementations are not technically a defense. They are a development methodology designed to provide rebuttal evidence to support a future failure-of-proof defense if you are accused of infringement.
How would you even put that in a statute? As far as case law goes all the case law you'd expect to see is around the particular evidence offered to show the implementers really did not have access to copyrighted elements of plaintiff's work, like record keeping and proof of authenticity and things like that.
An analogy would be like not having alcohol at an event you are hosting that is open to families because you want to make sure you don't violate laws against serving alcohol to minors. You aren't going to find a statute that says "Not having served alcohol to children is a defense to a charge violating the not serving alcohol to children statute". It is implicit in the not serving alcohol to children statute.
Any case law you find on this will not be about whether not serving alcohol to children is a valid way to avoid violating the not serving alcohol to children law. It will be about whether or not some kid that had alcohol got it from you or snuck it in from outside or about whether you took care to make sure your caterer adhered to you no alcohol policy or things like that.
"We don't want to take on the risk of working with a former Apple employee, who could potentially leak trade secrets and expose us to unwanted liability" is a very different statement than asserting that they were banned for deception. The post you're replying to is responding to accusations against their character and behaviour. Clearing those up is an entirely different matter than saying anything about whether former employees should be allowed to contribute to the project.
I'm sure Omarchy will appreciate the effort, even if you're snubbed by Asahi -- being able to run Linux flawlessly on Apple Silicon is going to be awesome.
I wouldn't expect "flawless" support for those chips in the next decade, even with AI. The earliest-supported Asahi chips still have missing power management and dark silicon.
The only way to get flawless Linux support is to buy hardware from an OEM that supports Linux well.
If using the OpenAI models to develop this taints you with Apple insider knowledge, then so is developing any macOS, iOS, Android or Windows apps around that are using any LLM.
You can't claim that some work is necessarily tainted by existing, you also have to prove which knowledge was retrieved, used and that there was no other reasonable way to know it. But unless it is actually tried in a court in all major jurisdictions, it's just speculation from all parties (including line).
One person could also claim that someone someday might leak information to them, and even though they'll ignore it, since they'll be exposed, they are tainted and can't contribute anymore. It'd be absurd.
A project is free to chose who can contribute, but they can't necessarily gatekeep others from doing their own project with different rules.
Yeah I see developers constantly saying they RE stuff using LLM in a clean room way and it’s definitely an opinion, not a fact. Just look at the most recent post here: https://x.com/ewninjaofficial
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.
Thanks for the post and answering here, but for someone to follow in your steps there really need to be more information: how did you handle physical hardware? Did it got stuck / frozen / whatever? How did you managed reset / etc? What is your actual step-by-step process other then just telling codex / claude code "do X"? What else had to be solved along the way?
I just think one good part of Marcan's work is that they streamed a lot of their workflow with all kind of problems occured along the way and you could see how to solve them.
And please so not let anti-llm crowd discourage you. People like me who want to use good hardware and already choose to pay for Apple one just need drivers that work good and feature complete - code purity and "quality" is secondary.
tl;dr you reboot the device with `macvdmtool`, you install m1n1 as the boot object, you talk to the m1n1 proxy over a python shell. I'm documenting the process as I go also (see: the blog posts, also my github repos) both so others can do it and as record of the clean room nature, but this really is just GPT go brrrrr
I'll add an addendum to the blog post at some point with a more detailed method because there is demand, but the tl;dr is:
- boot macos under hypervisor (detailed guide in my part 1) into single user mode
- write your own metal program and run it as early in boot as you can
- trace all relevant graphics regions
- once you see the first kick, intercept that kick, then capture the full uat state
- reboot the device, then copy that whole uat state back into the machine, every bit exactly where it was
- perform the kick, verify the output page changes as expected
- have the LLM build all the objects itself in python
- repeat with different metal programs until we have all the behavior you want
- for a list of all behaviors you want, just look at the m1/m2 kernel driver and make sure everything they do has an analogue in your codebase
- if there's every any problems, there's a very simple debugging loop: 1. MAKE SURE YOU HAVE A REPLAYABLE CAPTURE. if you don't then priority #1 is to get that capture. once you have that capture, it's only a matter of time until it works
- 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.
Great job for bringing up new apple's silicon chip , m4 a18 to linux . I hope the project keep alive and maintained , and if you can't mainline it , remmber many other project do out-of-tree version well maintained [1] [2] [3] [4] [5] [6] [7] .
> As another example, WINE does not ban all former Microsoft employees, they just ban anyone who has ever looked at the Windows source code.
It's an interesting example given that Wine considers deriving code from traces of original components (like hypervisor traces) tainted and also bans LLM contributions for legal considerations: https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
Traditional hardware RE centers around heroics by a small number of very smart people, see: marcan, Alyssa Rosenzweig, Asahi Lina, etc. What they did is insanely impressive, and given how hard it was with LLMs I'm sure I would not personally be able to do this work without LLMs. That said, I'm looking forward to a world where the staring at hexdumps and traces can be delegated to LLMs and talented humans can spend their time building as opposed to head banging.
Asking out of genuine curiosity... Do you think the Asahi maintainers could use your work to speed up future GPU driver development? M4, M5, M6 and so on... I am assuming they wouldn't just accept your work outright, but instead could they use it to substantially speed up their development process by mapping out a lot of the GPU after which they can focus on optimization and other aspect of drivers? Do you think they will?
I don't use Asahi now but that's largely because my current Apple M series hardware is still supported. I see a day where an older unsupported Mac is running in a rack in my basement or being used by my kids as a general purpose computer.
reply