Asahi Linux, the effort to port Linux to Apple’s new M1 SoC, has posted its second progress report.
It’s been a long time since the last update! In all honesty, the first Progress Report set the bar a little bit too high, and I found it difficult to sit down and put together monthly reports that would do it justice. So, going forward, we’re going to be providing shorter-form updates while striving to keep a monthly schedule.
That said, a lot has happened in the past few months, so strap in for a bigger update this time!
Quite a lot of detail in here, and lots of insights into the reverse engineering processes the developers are implementing.
A question sticks out to me: will apple actually allow customers to run linux? I mean so far linux development is happening exactly as predicted, with linux developers reverse engineering the hardware to create a working linux port. But in principal apple could release an update that blocks linux and it makes me wonder what the risk level is of that happening. Any word on whether apple is ok with this?
This is how I would reverse engineer black box drivers as well. Using a VM/emulator cuts down on expensive hardware based debugging/ICE, which is probably not even available for M1 CPUs anyways.
This seems like a huge challenge, not necessarily because it cannot be reverse engineered, but because…
The coprocessors are running apple firmware that does not use a stable API. This implies the reverse engineering will never get done so long as apple keeps updating the firmware. This seems like a pretty big burden for a small project. Let’s hope apple doesn’t add crypto between components.
All and all a very interesting project, keep us informed!
“This firmware is per-OS, not per-system, and thus Linux can use a different firmware bundle from any sibling macOS installations.”
I can see no pretty big burden …
kragil,
I am unclear on what exactly you mean. Are you interpreting the quote to mean that every OS boot up the firmware version of it’s choosing? Because that’s not the way I read it, especially following this statement: “Linux has to support all firmware versions going back to the initial supported one, in order to allow people to upgrade their kernel without upgrading their firmware in tandem.” And another statement from the report seems to imply that linux won’t have any control over the firmware either: “In case you’re wondering, no, we can’t write our own firmware, as it is loaded by iBoot before it hands control over to the OS, and it is signed by Apple. ”
These statements lead me to believe that linux has to support the version of firmware that happens to be used with MacOS. As I read it, the statement you quoted means that the firmware isn’t system specific, but macos specific instead. To me it sounds like linux will only work on all systems running a supported macos version. In other words, the work isn’t going to have to be repeated for different hardware models, which is good, but still requires them to support unstable coprocessor programming interfaces with macos updates.
This isn’t exactly true. With regard to US law the oft cited IBM BIOS case and Compaq’s double-blind “clean room” reverse engineering strategy is peculiar to that case and nothing else. It’s no different from the myth that you couldn’t see higher framerates than 50Hz or you would asphyxiate if you were on a train travelling faster than a horse. A lot of people claim the exact opposite and have the view that if they see it they can grab it under “fair use”. That’s not true either. Case law is very specific about the legal checks which must be in place and if you don’t pass those it’s not fair use. These checks must be done beforehand too. Doing them afterwards doesn’t count as a number of people have discovered when it gets to court.
I don’t personally find call intercepts to be that useful but understanding them and how they are used in the bigger picture can give you an understanding to a point.
But really with both issues you cannot dodge doing your own original work or developing your own expertise.
America is no different from China or anywhere else. The country has a record of ripping people off and exploitation and kicking the ladder away. Myself I feel this technical measure is no different to creating software dependencies on the cloud which a number of games companies have used whether it is remote code or downloadable extras. The impetus to control is also no different from the earlier scan before you upload to the cloud scheme discussed here last week.
Pretty much all of the above is only relevant to the American jurisdiction and not just the technical details but competition regulation and other law in practice which is actually a different thing. It also shows the dangers of having a dependency on anything American as the Chinese have discovered.
That’s valid. Most software is supported to a baseline for one reason or another.
I posted a long comment with lots of links including one to a Youtube which gave a hardware engineers view of the Jupiter Ace hardware. This is currently stalled in “moderation” and until Thom pulls his finger out likely to remain so.
Unless there is a clear legal reason any of these secure boot mechanisms are iffy. You don’t own your own hardware and are subject to “corporate made law” and your hardware being slung on the scrapheap to meet a sales target. It’s not about security it is about preserving economic and market dominance. Not surprising, I suppose, from the country which is known for “company towns”