25 ms·

Asahi Linux for Apple M1 progress report, August 2021

596 points by fanf2 5y ago

zamadatix 5y ago
Absolutely amazing progress, I might even give it an install once the USB drivers mentioned at the end are working. https://www.patreon.com/marcan/ https://www.patreon.com/marcan/ https://github.com/sponsors/marcan https://github.com/sponsors/marcan
- rowanG077 5y ago
  IF you can choose please use the github sponsors instead of patreon :). It's better percentage wise then patreon.
SirensOfTitan 5y ago
This kind of brilliant work makes me feel very very tiny as an engineer. I struggle after work to find time to learn basic Rust. I’m totally in awe of folks who can do this kind of stuff. It’s just so impressive, and maybe one day I can benefit from all this awesome work.
- gigatexal 5y ago
  Same. People who can easily straddle the lowest level bits of a machine and also write performant and good c code and then to do all of that and reverse engineer things, amazing.
- hivacruz 5y ago
  I feel you. Sometimes I browse projects on GitHub and I'm astonished by what people can do and I can't. Example, OpenCore[0], a famous bootloader in the Hackintosh scene. How can people even start to code this.. Awewome work, awesome people. [0]: https://github.com/acidanthera/OpenCorePkg https://github.com/acidanthera/OpenCorePkg
  - sho_hn 5y ago
    Preface: I can't do this (specifically). But I have done many types of software development across two decades. My journey began with LAMP-style web work, took me to C++ and the desktop (apps, GUI toolkits, browser engines), then to embedded - from smart TVs to smart speakers, to network protocols for drone systems and beefy car infotainment ECUs and lower-level microcontroller/borderline electronics work. My conclusion: You can get into just about anything, and for the most part the difficulty level is fairly uniform. But there's simply a vast sea of domain-specific spec knowledge out there. It doesn't mean that it's too hard for you or you can't learn it. Anything that is done at scale will fundamentally be approachable by most developers. Just be prepared you'll need to put in the time to acquire a familiarity with the local standards/specs and ways of doing things. Knowledge turns seemingly hard things into easy things, and if it's been done before chances are it's documented somewhere. The truly hard stuff is innovating/doing things that haven't been done before. Novel development happens rarely.
    - cmurf 5y ago
      >acquire a familiarity with the local standards/specs And with the bugs. Especially with bootloaders because you're in a preboot environment.
    - bartvk 5y ago
      Yeah, this is my conclusion too. I moved from the Oracle platform to embedded, scientific stuff like reading out custom electronics for IR cameras. And now I'm into iOS apps. It's more a question of what part of the stack feels interesting and doable to you, at a certain period in your professional life.
      - deleted 5y ago
        [deleted]
  - secondaryacct 5y ago
    I ve done a bittorrent client, a 3D rendering engine on the PS3 and a printer driver for fun and while clearly not at the levels of a bootloader, I can have a few cookie points in interview for originality. What I learned starting these daunting task (especially the ps3 which was closed specs), is that it s still done by humans and following familiar patterns. Most of the time you bang your head against unclear doc or go through successive layers of abstraction (to do a ps3 rendering engine, better know your basic openGL on PC, which is only possible if you know matrix and vector geometry) but EVERYTHING is possible to reach at a workable level (expert level I feel comes with money incentive, team mates and repetition). I spent 2 years on japanese, 3 hours a day, and could integrate the meaning of Haikus at the end. I think the only true talent you must have is insane stubborness. To go through, a doc at a time. Usually after the first insane challenge (for me: learning english at a near native level, reading literature or discussing politics) of your life, you understand it s all pretty much time investment.
- ostenning 5y ago
  Re: finding time. I think this is true for all of life, as we get older our risk and reward profiles change. As we are encumbered by more responsibility, family, mortgage, etc, we stop taking the same risks and start playing life more “safely” or “securely”. Of course it doesn't have to be that way and I personally advocate for a debt free lifestyle for this reason. Too many times have we heard the story of the midlife crisis: the false deity of security and comfort that robs the well paid executive the majority of his or her life. Its a sad story. So my advice is to people is to work less for others and work more for your own projects and passions, life is simply too short to give your years to someone else, even if it pays well.
  - machiaweliczny 5y ago
    I generally agree with you but total debt free life is suckery IMO when you are paid 90% by others people debt. It's better to take debt and profit from it (so invest and not consume, at least in current econ climate).
- ip26 5y ago
  Building useful and nonporous layers of abstractions and being able to quickly shift between them seems to be a key skill. When each layer leverages another, you can rapidly build something impressive. This in turn implies apart from technical skill, charting a good course from layer to layer can make a big difference, vs meandering without quite knowing where you are going.
rvz 5y ago
Great work, but as for the installer, use at your own risk or on another spare machine. Unless you want to risk losing your files or your entire machine. Maybe it would void your warranty if you do this. Who knows.
- marcan_42 5y ago
  Installing a custom kernel is an official feature on these machines and won't void your warranty. I've never had the installer do anything crazy, nor does it support any resize/deletion operations yet, so it's pretty unlikely that it'll wipe your data (it's much more likely to just fail to complete the installation properly). More likely is that if you boot Linux, a driver bug will cause data corruption. We've had some reports of filesystem issues, though as I said the kernel tree situation is haphazard right now, so we'll see if they still happen once we put together a tree with properly vetted patches :)
  - zozbot234 5y ago
    The common feature with these embedded ARM chipsets is that a faulty kernel can very much hardbrick your machine. There's nothing like the amount of failsafes you get with ordinary PC-compatible hardware. I wouldn't want to rely on any promise that "installing a custom kernel won't void your warranty" - in practice, it very much will if you don't know what you're doing.
    - my123 5y ago
      Same for x86 machines really, the number of UEFI firmwares that hard-bricked the machine if you dared deleting all NVRAM variables... (and many more other issues)
      - floatboth 5y ago
        That number is not that big, IIRC just a few specific laptops. I haven't heard of any desktop mainboards with that issue.
rowanG077 5y ago
Wow that's some progress. This looks pretty close to useable it seems. Is there some kind of expected timeline? Like in 6 months. Kb, wifi etc work. In 1 year we expect the GPU to work?
- marcan_42 5y ago
  Unofficially, I still have it as a bit of a personal goal to get the GPU going by the end of the year. We already have the userspace side passing >90% of the GLES2 tests on macOS, it's just the kernel side that's missing, so it's not as far as it might seem.
  - rowanG077 5y ago
    That would truly be amazing! I don't really expect anything official, I mean software is hard to estimate as it is. Let alone when you are reverse engineering where you never know what kind of insanity you will find. So for GPU we would need 3 pieces? Alyssa's work on reverse engineering the protocol and writing a driver to submit the correct commands to the GPU. A working DCP driver to handle actually displaying rendered frames. And finally a driver to be able to submit the commands to the GPU. And work on the last of those has not started yet, right? It's hard to piece together how everything fits for me.
    - marcan_42 5y ago
      There's a whole different coprocessor tied to the GPU for the rendering (AGX), though the generic RTKit/mailbox stuff is the same as it is for DCP. That will largely involve command submission, memory management, and (a relatively big unknown) GPU preemption. In principle, the GPU kernel side should be quite a bit simpler than DCP, since display management is quite a bit hairier than (relatively) simpler GPU operations; most of the complexity of the GPU is in the userspace side. But we won't know until we get there.
  - jtl999 5y ago
    How exactly do you test your own GPU "rendering" under macOS?
boris 5y ago
Thanks for working on this! It would be great if making Asahi generally usable was not blocked by the GPU driver. Currently Apple M1 is the only generally-available ARM hardware that can be used for testing other software for compatibility with ARM. So an installable version without desktop support would be very appreciated.
- opencl 5y ago
  What makes all of the other ARM hardware available unsuitable?
  - my123 5y ago
    Especially for example that a Jetson AGX Xavier with 32GB of RAM is available at the same price point as an M1 Mac mini. For $50 more, you can get: https://www.solid-run.com/arm-servers-networking-platforms/honeycomb-workstation/ https://www.solid-run.com/arm-servers-networking-platforms/h... on which you just add your own DRAM sticks too.
    - rjzzleep 5y ago
      If everything wasn't so built around CUDA the M1 GPU actually gives you twice the performance
      - bionade24 5y ago
        Source?
        rjzzleep 5y ago
        Look at any online benchmark? It runs at a similar clock and has twice the tensor cores, the AGX is a 2 year old 12nm chip. Why would anyone be surprised if the M1 was faster?
        my123 5y ago
stefan_ 5y ago
That RPC interface looks very nice for reverse engineering, but what kind of horror is this going to be in the kernel implementing KMS with JSON^2 and pretend-C++-functions?
- marcan_42 5y ago
  Oh yes. We're aware, we've had and continue to have debates about how to tackle the monster... :-) The C++ stuff isn't that bad, in the end you can just pretend it's messages with fixed layout structures. But yes, the serialized dict-of-arrays-of-dicts type stuff can be approached in a few ways, none of which are particularly beautiful.
  - rjzzleep 5y ago
    Any idea why they did that as opposed to something like RPMsg?
    - marcan_42 5y ago
      Apple have no reason to use existing standards when they can roll their own version tailored to their needs. It's for internal consumption, after all. This is very much a theme throughout their design.
      - rjzzleep 5y ago
        I'm aware of that, but that's not my question. Oftentimes there is a reason why they choose to ignore standards. They added a simple C++ (not full C++) layer on top of their driver code when they took FreeBSD drivers and integrated them into their OS. But there was a benefit to doing so, making the drivers arguably easier to compose. In this case the answer might be just that they were too time constrained to design something better. But I was just curious if the RPMsg framework has too many issues that would make it unsuitable.
        gok 5y ago
emodendroket 5y ago
I'm not an early adopter for this kind of thing, but it's great to see progress all the same.
intricatedetail 5y ago
We need lawmakers to force Apple and other companies to open documentation that could enable writing drivers etc. Give Apple anti privacy stance, I can see why they don't want a platform they can't control on their hardware. This should be illegal.
porsupah 5y ago
Hugely nifty work! Makes me wish I had an M1 system even more so I could help out.
derefr 5y ago
Re: the installation procedure, why does Asahi Linux have to have its own separate APFS container, rather than being an APFS volume in the pre-existing APFS container (and so sharing the Recovery volume with the pre-existing macOS install, not requiring you to resize the pre-existing APFS container smaller, etc.)?
- marcan_42 5y ago
  I actually haven't tried doing multiple installs in the same container, but there's no reason why it wouldn't work as far as I know. It would be easy to change the installer to let you do that. Though there isn't much of a difference for Linux; you can't actually share the Recovery image (since it's per-OS, even within a single Recovery volume), and since you need to repartition to create standard Linux partitions anyway (since linux-apfs isn't quite at the point where you'd want to use it as your root filesystem as far as I know...) it doesn't make much of a difference if you create a 2.5G stub container too, and makes it much easier to blow away the entire Linux install without affecting macOS. Perhaps in the future, when linux-apfs is solid enough, it would be interesting to support this in the installer in order to have a fully space-sharing dual-boot macOS/linux system, without partitioning. Also, U-Boot would have to grow APFS support in order to have a truly all-APFS system :) (we plan to use U-Boot as a layer for UEFI services and such, so you don't have to burn kernels into the m1n1 image, which would suck for upgrades).
  - derefr 5y ago
    > and since you need to repartition to create standard Linux partitions anyway If it's possible to do this in APFS (not sure), the installer could do something similar for APFS to what WUBI does for NTFS: fallocate(2) a contiguous-disk-block single-extent file inside the APFS volume, write the rootfs into it, and then configure the bootloader entry's kernel params with the APFS container+volume and the path to the file within the container. In this setup, linux-apfs would then only need to work well enough to expose that file's single extent's raw-block-device offset during early boot; then the initramfs script could unmount the linux-apfs volume and mount the ext4 rootfs directly from the block device at that offset. Yes, it's almost the same as resizing the disk smaller — but it's at least a less-"permanent" change, in the sense that deleting the rootfs file from macOS would give the space back, without needing to know to re-grow your macOS APFS container.
syntaxing 5y ago
Pardon my ignorance but what does the m1n1 hypervisor mean? Does this mean that it’s a single core hypervisor vm?
- marcan_42 5y ago
  m1n1 is our bootloader that bridges the Apple world and the Linux world together; it is also a hardware reverse engineering platform (remote controlled from a host) and now also a hypervisor. The hypervisor feature is indeed single core, but that's just because I haven't bothered implementing SMP (would need a bunch of extra locking, but it's doable, just not really necessary for us).
sydthrowaway 5y ago
Interesting. What's the project leaders day job, if I don't mind asking?
- zamadatix 5y ago
  From https://marcan.st/about/ https://marcan.st/about/ "Hello! I’m Hector Martin and like to go by the nickname “marcan”. I currently live in Tokyo, Japan as an IT/security consultant by day and a hacker by night. For some definition of day and night, anyway." Hacker for hire basically. This project was started via crowdfunding enough monthly sponsors (overnight from his previous reputation and interest in this project) and is somewhat half day job and half night hacking out of personal interest as a result.
mraza007 5y ago
This is so cool and the Asahi linux team has done amazing work. I can’t wait to use Linux as daily driver on my M1
sys_64738 5y ago
This is genius at work. If I was 5% as smart as these guys I'd be doing well.
dilap 5y ago
Damn, this is so cool. I can tell I'm going to be sucked back into to trying linux yet again...
knodi 5y ago
Linux on M1 mini is looking like a dream machine more and more.
- black_puppydog 5y ago
  On one level yes. I just can't imagine (anymore) pumping money into an ecosystem that purposefully makes it so difficult to run free software. I admit that excludes more and more modern hardware, but apple is the most expensive and profitable.
  - vbezhenar 5y ago
    Mini is not expensive. At least in its base configuration. It's a pity you can't upgrade it with cheap RAM and disks anymore.
black_puppydog 5y ago
Since there are clearly a lot of people who have been following the asahi development in detail, I would like to hear your takes on this quote from their FAQ: > No, Apple still controls the boot process and, for example, the firmware that runs on the Secure Enclave Processor. However, no modern device is “fully open” - no usable computer exists today with completely open software and hardware (as much as some companies want to market themselves as such). I think they're aiming at purism here, but might have forgotten about the MNT Reform, even though it is currently specced at the lower end of "usable".
- ploxiln 5y ago
  There's also the Raptor Computing Talos line ... which is interesting, all open firmware and busses, but even more expensive and less practical unfortunately. https://www.raptorcs.com/TALOSII/ https://www.raptorcs.com/TALOSII/
  - marcan_42 5y ago
    Open firmware, but who says the silicon isn't backdoored? And why is open firmware more important for your freedom than open silicon? What about on-chip ROMs? :-) In the end, you're always drawing arbitrary lines in the sand. If you really want to go all the way to actually reach a tangible goal, I'm only aware of one project that actually offers trust guarantees backed by hard engineering arguments: Precursor https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor (TL;DR on the trick is that, by using an FPGA, you make it nearly impossible to backdoor, because it would take a huge amount of compute power to engineer a backdoor into the FPGA silicon that can analyze arbitrary randomized FPGA designs to backdoor them). For more practical computing, I find M1s have a very solid secureboot design. We can retain that security even after putting m1n1/Asahi on there; doing so requires physical presence assertion and admin credentials and locks you into a single m1n1 version without repeating the process, so we can use that to root our own chain of trust. Similarly we can continue to use Apple's SEP (in the same way one would use a TPM, HSM, or a YubiKey for that matter; sure, it's a proprietary black box, but it also can't hurt you except where you let it) just like macOS does, for things like encryption and storing SSH secrets. And all the coprocessors have IOMMUs, and the whole thing is very logically put together (unlike the giant mess that are Intel CPUs; e.g. we know they have a JTAG backdoor in production chips after authenticating with keys only they have, never mind things like ME) and designed such that the main OS does not have to trust all the auxiliary firmwares. I'd love to have a more open system competing in the same space, but I have no problem trusting Apple's machines much more than I do the x86 PCs I use these days anyway, and it's hard to find things that compete in the same performance/power space that are more open than either of those, unfortunately.
cassepipe 5y ago
Kind of unrelated but I would like to benefit from the knowledge of people hanging out here to ask if anybody is aware of how good and how usable is Linux on Intel MacBook? Is there a specific Intel MacBook that's known to be particularly well supported by Linux ? Been searching but I couldn't find much else than vague information and lists of Linux distributions I could install on a MacBook.
- horsawlarway 5y ago
  Depends on the age of the macbook. Older models have reasonable support, newer models are (at best) a pain in the ass. I generally hit the arch wikis with specific models for the best information. This github repos also does a good job laying out current support for the 2016 models. https://github.com/Dunedan/mbp-2016-linux https://github.com/Dunedan/mbp-2016-linux Frankly, I haven't tried on a newer model then that - I don't buy apple hardware anymore.
- fastssd 5y ago
  15 inch Macbook Pro's from 2015 are regarded as the best Macs for Linux and hackers in general. The ports are a big plus too.
- flatiron 5y ago
  I use Arch as a daily driver on my 2013 MacBook. Their wiki has all I needed to tweak to get it running perfect. Needs a few extra steps (had to pass some max specific kernel parameters to turn off thunder bolt for instance) but it’s leaps and bounds better than macOS.
- nicholasjarr 5y ago
  I have a 2017 MacBook Pro with Touchbar and have Manjaro installed in it. It works fine but it is not perfect. No reliable bluetooth, never got touchbar working (so no esc and function keys). Its is not my main OS (I use Windows for work), but for studying and trying new things I use it. I wouldn't risk installing it without leaving a MacOS partition.
jjcon 5y ago
Can anyone comment on the possibility of going in the opposite direction? I’m considering buying the frame.work laptop, daily driving pop!_os and then virtualizing OSX on it for the few OSX programs I use (this supports framework and not apple). It looks like it may be fairly easy and possible with a 10-20% performance hit? https://github.com/foxlet/macOS-Simple-KVM https://github.com/foxlet/macOS-Simple-KVM From what I can tell you can pass through a single GPU with a bit of work, even a iGPU? Is that correct?
- heavyset_go 5y ago
  This and VirtualBox work well for Mac emulation on Linux.
- flatiron 5y ago
  I’ve never passed a GPU to a mac guest but I have done Xcode work in a VM and it worked fine on Arch. If I had the cash I would too get a framework laptop!
- mixmastamyk 5y ago
  macOS doesn't work on non-apple hardware, including under VMs. Unless you've patched it somehow?
  - inside_out_life 5y ago
    Have you been living under a rock? Do you know what a hackintosh is? It's been going for so long that ccurrent bootloaders allow to run it completely unmodified, working updates etc. macOS also runs under some VMs, with some config tweaks
    - mixmastamyk 5y ago
      I'm familiar with that, why I mentioned "patched" in my above comment. It's still a tenuous position to be in, unless you enjoy diagnosing errors rather than working.
dm319 5y ago
I find Marcan's live streams on this fascinating/mesmerising, and I'm not a programmer.
- fastssd 5y ago
  Agreed. I have even learned some things casually watching his streams over the last month or so.
mlindner 5y ago
> For the initial kernel DCP support, we expect to require the firmware released with macOS 12 “Monterey” (which is currently in public beta); perhaps 12.0 or a newer point release, depending on the timing. We will add new supported firmware versions as we find it necessary to take advantage of bugfixes and to support new hardware. Please don't do this! Monterey is an OS I will never install given that it will include the Apple-provided spyware. This shouldn't be the earliest supported version! I suggest instead finalizing on a current/later release of Mac OS 11 as updates for it will slow down once Monterey is released. A lot of people won't be updating to Monterey.
- marcan_42 5y ago
  You need Monterey firmware only. You can just do a side install once (to update your system firmware, which needs to be at least as new as the newest OS bundle) into another volume, nuke it, then install Asahi with the Monterey firmware bundle option, and keep your main macOS install at whatever version you want.
- marcellus23 5y ago
  > A lot of people won't be updating to Monterey. I’m quite sure this won’t be true, HN threads full of uninformed complaints notwithstanding.
stiltzkin 5y ago
Hector Martin is a hacker machine.
mlindner 5y ago
It's unfortunate in a lot of ways that this is all getting written before Rust support is in the kernel. If that was the case then all these new drivers could get written in Rust instead. Oh well.
- aranchelk 5y ago
  As described, the crux of this work seems to be learning how to interface with Apple’s proprietary hardware. If Rust enthusiasts want to go back later and reimplement, they’ll have a working open source reference implementation.
- uartman 5y ago
  Asking people to use an experimental feature that will probably be ready in a couple years only to write stuff today is an extremely bizzare thing to do.
haberman 5y ago
> The silver lining of using this complicated DCP interface is that DCP does in fact run a huge amount of code – the DCP firmware is over 7MB! It implements complicated algorithms like DisplayPort link training, real-time memory bandwidth calculations, handling the DisplayPort to HDMI converter in the Mac mini, enumerating valid video modes and performing mode switching, and more. It would be a huge ordeal to reverse engineer all of this and implement it as a raw hardware driver, so it is quite likely that, in the end, we will save time by using this higher-level interface and leaving all the dirty work to the DCP. In particular, it is likely that newer Apple Silicon chips will use a shared DCP codebase and the same interface for any given macOS version, which gives us support for newer chips “for free”, with only comparatively minor DCP firmware ABI updates. How interesting: by moving some of the driver to firmware, Apple has effectively made it easier for OSs like Linux to have good support for the hardware, because the OS<->hardware protocol operates at a higher level of abstraction and may work across multiple chips. The trade-off is that the protocol is not stable and so Linux has to decide which versions it will support, and make sure the OS driver always matches the version of the hardware firmware: > As a further twist, the DCP interface is not stable and changes every macOS version! [...] Don’t fret: this doesn’t mean you won’t be able to upgrade macOS. This firmware is per-OS, not per-system, and thus Linux can use a different firmware bundle from any sibling macOS installations.
- edeion 5y ago
  If I recall correctly, high end hard drives used a protocol called SCSI in the 90s that was mostly embedded in hardware.
  - minedwiz 5y ago
    Somewhat related, SSDs run an entire microcontroller on-board to translate from I/O requests from the OS to proper use of the flash hardware.
    - vlovich123 5y ago
      If I recall correctly that’s not the case on Apple platforms. They do the translation themselves across raw NAND.
monocasa 5y ago
Are the ASC firmware blobs encrypted too? ie. are they easily available for static analysis?
- my123 5y ago
  They are regular Mach-Os, with some symbols still available too.
- marcan_42 5y ago
  Only the SEP firmware is encrypted; all the other copro firmwares are plaintext and your can analyze them to your heart's content.
  - grishka 5y ago
    A dumb question. What are they trying to achieve by encrypting the SEP firmware? If they want to prevent people modifying it, won't signing it be enough? Otherwise this smells of security through obscurity, which, strictly speaking, isn't really security, and Apple engineers are most likely aware of that.
    - my123 5y ago
      There's also the HDCP and some other DRM keys in there... but then, they encrypt iBoot too. So can't be all of it.
      - grishka 5y ago
        Yeah because clearly DRM has never been broken and none of those keys are known to the public already.
    - monocasa 5y ago
      Security through obscurity can absolutely be an important layer of a defense in depth strategy. It's just useless as the only layer.
    - marcan_42 5y ago
2bitencryption 5y ago
here's a (possibly dumb) question - assuming a 100% complete and successful "Asahi Linux", what does this mean for distros? Is this a kernel replacement, as in I could run Manjaro Gnome, and just load the Asahi Kernel and it all Just Works? Or will Asahi Linux need to be a full distro of its own, in order to be useful?
- idle_zealot 5y ago
  It looks like installing a Linux distro on an m1 Mac requires a special installation package, rather than a standard iso. So Asahi is going to be a distro packaged/distributed specifically for m1 Macs, but changes to the kernel etc are being upstreamed, so other distributions should be able to build their own installation media for m1 Macs too in the future.
- Raqbit 5y ago
  They are working on creating a full distro, based on Arch Linux ARM, which will be an easy-to-use package for end-users with bleeding-edge versions of the software they develop.[1] That said, all components will be upstreamed into their respective projects such that other distributions should eventually be able to add support for Apple's line of desktop computers with Apple Silicon. [1] https://asahilinux.org/about/#is-this-a-linux-distribution https://asahilinux.org/about/#is-this-a-linux-distribution
- marcan_42 5y ago
  It's several things (yes, we know it's confusing). Asahi Linux is the overall project. m1n1 is our bootloader, which once installed will present a standard (ish) U-Boot/UEFI boot environment. From there you will be able to boot any distro or USB installer, in principle, once the changes trickle upstream. Our installer will install m1n1 and then give you the choice of also installing a distro image. We'll be providing our own based on Arch Linux ARM, but we're open to other distros providing images so we can add them to the list. We already have interest from Fedora, for example. So we expect that people who want to run Linux (or in fact openbsd or anything else) on these Macs will first use our bootloader installer, then either pick one of the built-in images or use their own USB installation media from whatever distro.
jaimex2 5y ago
When the project is done will Linux running on an M1 have any advantages over just running Linux on a regular x86_64 system?
- sim_card_map 5y ago
  yes, completely silent for one (no cpu fan) also m1 is pretty quick
  - helloworld8796 5y ago
    The Pro has a CPU fan. Anyway, the ISA does not necessarily imply higher or lower energy consumption.
adevx 5y ago
Amazing work and any developer should work on whatever he pleases. But there is also something in me that wished development would focus on something more open. What if Apple tomorrow decides only signed kernels are allowed to boot (to protect the children). I know there currently is no ARM laptop equivalent to the M1, and ARM booting is a minefield. So I get that if the M1 becomes a viable Linux target this would be very interesting.
- grishka 5y ago
  I think Apple has specifically announced at WWDC that ARM macs won't be locked down? I've also read somewhere that they have specifically written some utilities to allow booting arbitrary kernels — they could have very well not done that, so it has to be very intentional. Apple engineers are also probably reading all this and are very impressed.
  - adevx 5y ago
    Would love to see a link to that announcement. I'm sure Apple engineers appreciate the skills that go into this, but they have little to no say in Apple's strategic direction which is ever tighter control of the platform. Don't get me wrong, I would love Apple to publicly endorse running arbitrary kernels on M1 hardware.
Br0w 5y ago
Update for all about app for new all systems in account Microsoft Windows and new status version network information Technology system for my akaun Google and support to all new status version system
blinkingled 5y ago
What are the licensing implications of using DCP firmware from macOS installations - just having the hardware and OS license is enough to use it within Linux?
- marcan_42 5y ago
  All Apple Silicon machine owners are licensed to use macOS (and all of its components), among other things, because it is actually a critical part of system firmware (as part of system recovery; the machine boot picker is itself macOS even). Apple provides restore images for this purpose (downloadable without any authentication). This is how the installer works, so we don't have to redistribute any firmware ourselves. Redistribution is the usual thorny firmware problem; since we don't have to do that, we're in a pretty good position. Whether Apple's EULA applies to macOS obtained in this way, without actually going through a normal boot for that instance and thus the click-through EULA, is legally unclear. That said, here's a quick analysis: 2A says you can only install and run a single copy of the software. That might seem to imply that you wouldn't be able to dual-boot macOS and Asahi Linux, but this clause is pretty dumb. By design, all of these machines with one instance of macOS have at least two copies of part of the software: the recovery image - is that a violation? What about the fact that the bootability process creates a copy of all system firmware? You end up with 4+ copies of some components. What about installing macOS multiple times? Multiple versions of macOS? Do APFS CoW clones count as copies? If so that's another two copies of the recovery image. If they don't, can we just CoW clone stuff from the currently installed macOS version within the same container instead of doing a from-scratch install? Once Apple's updater breaks the CoW link, does that mean they are causing you to violate the EULA at that point? These are all things Apple obviously intended for people to do with these machines, regardless of what the lawyers say, so I don't think we have to worry too much about it. Legal texts are often completely at odds with the technical realities involved, and in the end nobody cares. 2M explicitly allows you to replace the Open Source components of macOS with your own version. This is exactly what m1n1 is: it is a replacement for xnu, the open source macOS kernel. So this clause explicitly puts at least our original full-fat macOS install process in the clear. The clause also says their warranty does not cover damage caused by such modifications, but does not say your warranty is void by merely doing so (so they'd have to prove any damage was caused by it). 2N says no reverse engineering, but you don't care about that, we do. I'm pretty confident I'm not going to get a C&D from Apple's lawyers for working on Asahi Linux, and if I do, I know how to defend myself and what organizations can help with that. It would be terribly bad PR for them to do that. 4A says you can transfer your Apple software, but 4B says you can't do that if you've modified it under 2M. That might mean that, on paper, you can't give away or sell a Mac that has Asahi Linux installed, without first uninstalling the bootloader and having the next owner reinstall it. Again though, this is a silly technicality. What Apple means is they don't want you patching macOS and distributing it separately. They also say the macOS components are a bundle and cannot be distributed separately, but our installer doesn't distribute anything, it pulls specific components from Apple themselves, which they are distributing. 4C says that you may only use copies made available for restorative purposes for those purposes and may not be resold or transferred. That might put our usage of ipsw restore images in the installer out of compliance, though the "restorative purposes" thing is a bit unclear. Does it count as "restoring" Apple's boot components into a blank OS partition? Obviously we are not reselling or transferring anything, so that part is not an issue. This is an EULA, and to what extent these clauses are legally enforceable is of course unclear. We aren't doing the big copyright no-no of redistribution, and Apple themselves provide the software for free download, and it is a fact that every Mac user is licensed to use it. So in practice it would be quite questionable to try to go after people for technicalities here. The better question is whether Apple's lawyers will care, and I'm pretty sure the answer is no. The EULA is there to give them legal ammo against companies trying to do things like provide virtual macOS as a service or installing it on non-Apple machines; they don't really care what end-users do (they don't even care about hackintoshes as long as you aren't selling them, which is a blatant EULA violation). The general idea of running Linux with Apple's firmware is completely kosher per 2M (if done on a single macOS install, e.g. just replacing xnu with m1n1 without a separate OS instance), so there is no legal basis for Apple to block our project entirely. It would be extremely silly if they went after our users to block our specific install process just to annoy them or get them to replace macOS with Linux instead of dual-booting, and it would also put in jeopardy things that regular macOS developers do, like having multiple OS installs.

596 points by fanf2 5y ago

Absolutely amazing progress, I might even give it an install once the USB drivers mentioned at the end are working. https://www.patreon.com/marcan/ https://www.patreon.com/marcan/ https://github.com/sponsors/marcan https://github.com/sponsors/marcan

rowanG077 5y ago
IF you can choose please use the github sponsors instead of patreon :). It's better percentage wise then patreon.

SirensOfTitan 5y ago

This kind of brilliant work makes me feel very very tiny as an engineer. I struggle after work to find time to learn basic Rust. I’m totally in awe of folks who can do this kind of stuff. It’s just so impressive, and maybe one day I can benefit from all this awesome work.

gigatexal 5y ago
Same. People who can easily straddle the lowest level bits of a machine and also write performant and good c code and then to do all of that and reverse engineer things, amazing.
hivacruz 5y ago
I feel you. Sometimes I browse projects on GitHub and I'm astonished by what people can do and I can't. Example, OpenCore[0], a famous bootloader in the Hackintosh scene. How can people even start to code this.. Awewome work, awesome people. [0]: https://github.com/acidanthera/OpenCorePkg https://github.com/acidanthera/OpenCorePkg
- sho_hn 5y ago
  Preface: I can't do this (specifically). But I have done many types of software development across two decades. My journey began with LAMP-style web work, took me to C++ and the desktop (apps, GUI toolkits, browser engines), then to embedded - from smart TVs to smart speakers, to network protocols for drone systems and beefy car infotainment ECUs and lower-level microcontroller/borderline electronics work. My conclusion: You can get into just about anything, and for the most part the difficulty level is fairly uniform. But there's simply a vast sea of domain-specific spec knowledge out there. It doesn't mean that it's too hard for you or you can't learn it. Anything that is done at scale will fundamentally be approachable by most developers. Just be prepared you'll need to put in the time to acquire a familiarity with the local standards/specs and ways of doing things. Knowledge turns seemingly hard things into easy things, and if it's been done before chances are it's documented somewhere. The truly hard stuff is innovating/doing things that haven't been done before. Novel development happens rarely.
  - cmurf 5y ago
    >acquire a familiarity with the local standards/specs And with the bugs. Especially with bootloaders because you're in a preboot environment.
  - bartvk 5y ago
    Yeah, this is my conclusion too. I moved from the Oracle platform to embedded, scientific stuff like reading out custom electronics for IR cameras. And now I'm into iOS apps. It's more a question of what part of the stack feels interesting and doable to you, at a certain period in your professional life.
    - deleted 5y ago
      [deleted]
- secondaryacct 5y ago
  I ve done a bittorrent client, a 3D rendering engine on the PS3 and a printer driver for fun and while clearly not at the levels of a bootloader, I can have a few cookie points in interview for originality. What I learned starting these daunting task (especially the ps3 which was closed specs), is that it s still done by humans and following familiar patterns. Most of the time you bang your head against unclear doc or go through successive layers of abstraction (to do a ps3 rendering engine, better know your basic openGL on PC, which is only possible if you know matrix and vector geometry) but EVERYTHING is possible to reach at a workable level (expert level I feel comes with money incentive, team mates and repetition). I spent 2 years on japanese, 3 hours a day, and could integrate the meaning of Haikus at the end. I think the only true talent you must have is insane stubborness. To go through, a doc at a time. Usually after the first insane challenge (for me: learning english at a near native level, reading literature or discussing politics) of your life, you understand it s all pretty much time investment.
ostenning 5y ago
Re: finding time. I think this is true for all of life, as we get older our risk and reward profiles change. As we are encumbered by more responsibility, family, mortgage, etc, we stop taking the same risks and start playing life more “safely” or “securely”. Of course it doesn't have to be that way and I personally advocate for a debt free lifestyle for this reason. Too many times have we heard the story of the midlife crisis: the false deity of security and comfort that robs the well paid executive the majority of his or her life. Its a sad story. So my advice is to people is to work less for others and work more for your own projects and passions, life is simply too short to give your years to someone else, even if it pays well.
- machiaweliczny 5y ago
  I generally agree with you but total debt free life is suckery IMO when you are paid 90% by others people debt. It's better to take debt and profit from it (so invest and not consume, at least in current econ climate).
ip26 5y ago
Building useful and nonporous layers of abstractions and being able to quickly shift between them seems to be a key skill. When each layer leverages another, you can rapidly build something impressive. This in turn implies apart from technical skill, charting a good course from layer to layer can make a big difference, vs meandering without quite knowing where you are going.

rvz 5y ago

Great work, but as for the installer, use at your own risk or on another spare machine. Unless you want to risk losing your files or your entire machine. Maybe it would void your warranty if you do this. Who knows.

marcan_42 5y ago
Installing a custom kernel is an official feature on these machines and won't void your warranty. I've never had the installer do anything crazy, nor does it support any resize/deletion operations yet, so it's pretty unlikely that it'll wipe your data (it's much more likely to just fail to complete the installation properly). More likely is that if you boot Linux, a driver bug will cause data corruption. We've had some reports of filesystem issues, though as I said the kernel tree situation is haphazard right now, so we'll see if they still happen once we put together a tree with properly vetted patches :)
- zozbot234 5y ago
  The common feature with these embedded ARM chipsets is that a faulty kernel can very much hardbrick your machine. There's nothing like the amount of failsafes you get with ordinary PC-compatible hardware. I wouldn't want to rely on any promise that "installing a custom kernel won't void your warranty" - in practice, it very much will if you don't know what you're doing.
  - my123 5y ago
    Same for x86 machines really, the number of UEFI firmwares that hard-bricked the machine if you dared deleting all NVRAM variables... (and many more other issues)
    - floatboth 5y ago
      That number is not that big, IIRC just a few specific laptops. I haven't heard of any desktop mainboards with that issue.

rowanG077 5y ago

Wow that's some progress. This looks pretty close to useable it seems. Is there some kind of expected timeline? Like in 6 months. Kb, wifi etc work. In 1 year we expect the GPU to work?

marcan_42 5y ago
Unofficially, I still have it as a bit of a personal goal to get the GPU going by the end of the year. We already have the userspace side passing >90% of the GLES2 tests on macOS, it's just the kernel side that's missing, so it's not as far as it might seem.
- rowanG077 5y ago
  That would truly be amazing! I don't really expect anything official, I mean software is hard to estimate as it is. Let alone when you are reverse engineering where you never know what kind of insanity you will find. So for GPU we would need 3 pieces? Alyssa's work on reverse engineering the protocol and writing a driver to submit the correct commands to the GPU. A working DCP driver to handle actually displaying rendered frames. And finally a driver to be able to submit the commands to the GPU. And work on the last of those has not started yet, right? It's hard to piece together how everything fits for me.
  - marcan_42 5y ago
    There's a whole different coprocessor tied to the GPU for the rendering (AGX), though the generic RTKit/mailbox stuff is the same as it is for DCP. That will largely involve command submission, memory management, and (a relatively big unknown) GPU preemption. In principle, the GPU kernel side should be quite a bit simpler than DCP, since display management is quite a bit hairier than (relatively) simpler GPU operations; most of the complexity of the GPU is in the userspace side. But we won't know until we get there.
- jtl999 5y ago
  How exactly do you test your own GPU "rendering" under macOS?

boris 5y ago

Thanks for working on this! It would be great if making Asahi generally usable was not blocked by the GPU driver. Currently Apple M1 is the only generally-available ARM hardware that can be used for testing other software for compatibility with ARM. So an installable version without desktop support would be very appreciated.

opencl 5y ago
What makes all of the other ARM hardware available unsuitable?
- my123 5y ago
  Especially for example that a Jetson AGX Xavier with 32GB of RAM is available at the same price point as an M1 Mac mini. For $50 more, you can get: https://www.solid-run.com/arm-servers-networking-platforms/honeycomb-workstation/ https://www.solid-run.com/arm-servers-networking-platforms/h... on which you just add your own DRAM sticks too.
  - rjzzleep 5y ago
    If everything wasn't so built around CUDA the M1 GPU actually gives you twice the performance
    - bionade24 5y ago
      Source?
      - rjzzleep 5y ago
        Look at any online benchmark? It runs at a similar clock and has twice the tensor cores, the AGX is a 2 year old 12nm chip. Why would anyone be surprised if the M1 was faster?
        my123 5y ago

stefan_ 5y ago

That RPC interface looks very nice for reverse engineering, but what kind of horror is this going to be in the kernel implementing KMS with JSON^2 and pretend-C++-functions?

marcan_42 5y ago
Oh yes. We're aware, we've had and continue to have debates about how to tackle the monster... :-) The C++ stuff isn't that bad, in the end you can just pretend it's messages with fixed layout structures. But yes, the serialized dict-of-arrays-of-dicts type stuff can be approached in a few ways, none of which are particularly beautiful.
- rjzzleep 5y ago
  Any idea why they did that as opposed to something like RPMsg?
  - marcan_42 5y ago
    Apple have no reason to use existing standards when they can roll their own version tailored to their needs. It's for internal consumption, after all. This is very much a theme throughout their design.
    - rjzzleep 5y ago
      I'm aware of that, but that's not my question. Oftentimes there is a reason why they choose to ignore standards. They added a simple C++ (not full C++) layer on top of their driver code when they took FreeBSD drivers and integrated them into their OS. But there was a benefit to doing so, making the drivers arguably easier to compose. In this case the answer might be just that they were too time constrained to design something better. But I was just curious if the RPMsg framework has too many issues that would make it unsuitable.
      - gok 5y ago

emodendroket 5y ago

I'm not an early adopter for this kind of thing, but it's great to see progress all the same.

intricatedetail 5y ago

We need lawmakers to force Apple and other companies to open documentation that could enable writing drivers etc. Give Apple anti privacy stance, I can see why they don't want a platform they can't control on their hardware. This should be illegal.

porsupah 5y ago

Hugely nifty work! Makes me wish I had an M1 system even more so I could help out.

derefr 5y ago

Re: the installation procedure, why does Asahi Linux have to have its own separate APFS container, rather than being an APFS volume in the pre-existing APFS container (and so sharing the Recovery volume with the pre-existing macOS install, not requiring you to resize the pre-existing APFS container smaller, etc.)?

marcan_42 5y ago
I actually haven't tried doing multiple installs in the same container, but there's no reason why it wouldn't work as far as I know. It would be easy to change the installer to let you do that. Though there isn't much of a difference for Linux; you can't actually share the Recovery image (since it's per-OS, even within a single Recovery volume), and since you need to repartition to create standard Linux partitions anyway (since linux-apfs isn't quite at the point where you'd want to use it as your root filesystem as far as I know...) it doesn't make much of a difference if you create a 2.5G stub container too, and makes it much easier to blow away the entire Linux install without affecting macOS. Perhaps in the future, when linux-apfs is solid enough, it would be interesting to support this in the installer in order to have a fully space-sharing dual-boot macOS/linux system, without partitioning. Also, U-Boot would have to grow APFS support in order to have a truly all-APFS system :) (we plan to use U-Boot as a layer for UEFI services and such, so you don't have to burn kernels into the m1n1 image, which would suck for upgrades).
- derefr 5y ago
  > and since you need to repartition to create standard Linux partitions anyway If it's possible to do this in APFS (not sure), the installer could do something similar for APFS to what WUBI does for NTFS: fallocate(2) a contiguous-disk-block single-extent file inside the APFS volume, write the rootfs into it, and then configure the bootloader entry's kernel params with the APFS container+volume and the path to the file within the container. In this setup, linux-apfs would then only need to work well enough to expose that file's single extent's raw-block-device offset during early boot; then the initramfs script could unmount the linux-apfs volume and mount the ext4 rootfs directly from the block device at that offset. Yes, it's almost the same as resizing the disk smaller — but it's at least a less-"permanent" change, in the sense that deleting the rootfs file from macOS would give the space back, without needing to know to re-grow your macOS APFS container.

syntaxing 5y ago

Pardon my ignorance but what does the m1n1 hypervisor mean? Does this mean that it’s a single core hypervisor vm?

marcan_42 5y ago
m1n1 is our bootloader that bridges the Apple world and the Linux world together; it is also a hardware reverse engineering platform (remote controlled from a host) and now also a hypervisor. The hypervisor feature is indeed single core, but that's just because I haven't bothered implementing SMP (would need a bunch of extra locking, but it's doable, just not really necessary for us).

sydthrowaway 5y ago

Interesting. What's the project leaders day job, if I don't mind asking?

zamadatix 5y ago
From https://marcan.st/about/ https://marcan.st/about/ "Hello! I’m Hector Martin and like to go by the nickname “marcan”. I currently live in Tokyo, Japan as an IT/security consultant by day and a hacker by night. For some definition of day and night, anyway." Hacker for hire basically. This project was started via crowdfunding enough monthly sponsors (overnight from his previous reputation and interest in this project) and is somewhat half day job and half night hacking out of personal interest as a result.

mraza007 5y ago

This is so cool and the Asahi linux team has done amazing work. I can’t wait to use Linux as daily driver on my M1

sys_64738 5y ago

This is genius at work. If I was 5% as smart as these guys I'd be doing well.

dilap 5y ago

Damn, this is so cool. I can tell I'm going to be sucked back into to trying linux yet again...

knodi 5y ago

Linux on M1 mini is looking like a dream machine more and more.

black_puppydog 5y ago
On one level yes. I just can't imagine (anymore) pumping money into an ecosystem that purposefully makes it so difficult to run free software. I admit that excludes more and more modern hardware, but apple is the most expensive and profitable.
- vbezhenar 5y ago
  Mini is not expensive. At least in its base configuration. It's a pity you can't upgrade it with cheap RAM and disks anymore.

black_puppydog 5y ago

Since there are clearly a lot of people who have been following the asahi development in detail, I would like to hear your takes on this quote from their FAQ: > No, Apple still controls the boot process and, for example, the firmware that runs on the Secure Enclave Processor. However, no modern device is “fully open” - no usable computer exists today with completely open software and hardware (as much as some companies want to market themselves as such). I think they're aiming at purism here, but might have forgotten about the MNT Reform, even though it is currently specced at the lower end of "usable".

ploxiln 5y ago
There's also the Raptor Computing Talos line ... which is interesting, all open firmware and busses, but even more expensive and less practical unfortunately. https://www.raptorcs.com/TALOSII/ https://www.raptorcs.com/TALOSII/
- marcan_42 5y ago
  Open firmware, but who says the silicon isn't backdoored? And why is open firmware more important for your freedom than open silicon? What about on-chip ROMs? :-) In the end, you're always drawing arbitrary lines in the sand. If you really want to go all the way to actually reach a tangible goal, I'm only aware of one project that actually offers trust guarantees backed by hard engineering arguments: Precursor https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor (TL;DR on the trick is that, by using an FPGA, you make it nearly impossible to backdoor, because it would take a huge amount of compute power to engineer a backdoor into the FPGA silicon that can analyze arbitrary randomized FPGA designs to backdoor them). For more practical computing, I find M1s have a very solid secureboot design. We can retain that security even after putting m1n1/Asahi on there; doing so requires physical presence assertion and admin credentials and locks you into a single m1n1 version without repeating the process, so we can use that to root our own chain of trust. Similarly we can continue to use Apple's SEP (in the same way one would use a TPM, HSM, or a YubiKey for that matter; sure, it's a proprietary black box, but it also can't hurt you except where you let it) just like macOS does, for things like encryption and storing SSH secrets. And all the coprocessors have IOMMUs, and the whole thing is very logically put together (unlike the giant mess that are Intel CPUs; e.g. we know they have a JTAG backdoor in production chips after authenticating with keys only they have, never mind things like ME) and designed such that the main OS does not have to trust all the auxiliary firmwares. I'd love to have a more open system competing in the same space, but I have no problem trusting Apple's machines much more than I do the x86 PCs I use these days anyway, and it's hard to find things that compete in the same performance/power space that are more open than either of those, unfortunately.

cassepipe 5y ago

Kind of unrelated but I would like to benefit from the knowledge of people hanging out here to ask if anybody is aware of how good and how usable is Linux on Intel MacBook? Is there a specific Intel MacBook that's known to be particularly well supported by Linux ? Been searching but I couldn't find much else than vague information and lists of Linux distributions I could install on a MacBook.

horsawlarway 5y ago
Depends on the age of the macbook. Older models have reasonable support, newer models are (at best) a pain in the ass. I generally hit the arch wikis with specific models for the best information. This github repos also does a good job laying out current support for the 2016 models. https://github.com/Dunedan/mbp-2016-linux https://github.com/Dunedan/mbp-2016-linux Frankly, I haven't tried on a newer model then that - I don't buy apple hardware anymore.
fastssd 5y ago
15 inch Macbook Pro's from 2015 are regarded as the best Macs for Linux and hackers in general. The ports are a big plus too.
flatiron 5y ago
I use Arch as a daily driver on my 2013 MacBook. Their wiki has all I needed to tweak to get it running perfect. Needs a few extra steps (had to pass some max specific kernel parameters to turn off thunder bolt for instance) but it’s leaps and bounds better than macOS.
nicholasjarr 5y ago
I have a 2017 MacBook Pro with Touchbar and have Manjaro installed in it. It works fine but it is not perfect. No reliable bluetooth, never got touchbar working (so no esc and function keys). Its is not my main OS (I use Windows for work), but for studying and trying new things I use it. I wouldn't risk installing it without leaving a MacOS partition.

jjcon 5y ago

Can anyone comment on the possibility of going in the opposite direction? I’m considering buying the frame.work laptop, daily driving pop!_os and then virtualizing OSX on it for the few OSX programs I use (this supports framework and not apple). It looks like it may be fairly easy and possible with a 10-20% performance hit? https://github.com/foxlet/macOS-Simple-KVM https://github.com/foxlet/macOS-Simple-KVM From what I can tell you can pass through a single GPU with a bit of work, even a iGPU? Is that correct?

heavyset_go 5y ago
This and VirtualBox work well for Mac emulation on Linux.
flatiron 5y ago
I’ve never passed a GPU to a mac guest but I have done Xcode work in a VM and it worked fine on Arch. If I had the cash I would too get a framework laptop!
mixmastamyk 5y ago
macOS doesn't work on non-apple hardware, including under VMs. Unless you've patched it somehow?
- inside_out_life 5y ago
  Have you been living under a rock? Do you know what a hackintosh is? It's been going for so long that ccurrent bootloaders allow to run it completely unmodified, working updates etc. macOS also runs under some VMs, with some config tweaks
  - mixmastamyk 5y ago
    I'm familiar with that, why I mentioned "patched" in my above comment. It's still a tenuous position to be in, unless you enjoy diagnosing errors rather than working.

dm319 5y ago

I find Marcan's live streams on this fascinating/mesmerising, and I'm not a programmer.

fastssd 5y ago
Agreed. I have even learned some things casually watching his streams over the last month or so.

mlindner 5y ago

> For the initial kernel DCP support, we expect to require the firmware released with macOS 12 “Monterey” (which is currently in public beta); perhaps 12.0 or a newer point release, depending on the timing. We will add new supported firmware versions as we find it necessary to take advantage of bugfixes and to support new hardware. Please don't do this! Monterey is an OS I will never install given that it will include the Apple-provided spyware. This shouldn't be the earliest supported version! I suggest instead finalizing on a current/later release of Mac OS 11 as updates for it will slow down once Monterey is released. A lot of people won't be updating to Monterey.

marcan_42 5y ago
You need Monterey firmware only. You can just do a side install once (to update your system firmware, which needs to be at least as new as the newest OS bundle) into another volume, nuke it, then install Asahi with the Monterey firmware bundle option, and keep your main macOS install at whatever version you want.
marcellus23 5y ago
> A lot of people won't be updating to Monterey. I’m quite sure this won’t be true, HN threads full of uninformed complaints notwithstanding.

stiltzkin 5y ago

Hector Martin is a hacker machine.

mlindner 5y ago

It's unfortunate in a lot of ways that this is all getting written before Rust support is in the kernel. If that was the case then all these new drivers could get written in Rust instead. Oh well.

aranchelk 5y ago
As described, the crux of this work seems to be learning how to interface with Apple’s proprietary hardware. If Rust enthusiasts want to go back later and reimplement, they’ll have a working open source reference implementation.
uartman 5y ago
Asking people to use an experimental feature that will probably be ready in a couple years only to write stuff today is an extremely bizzare thing to do.

haberman 5y ago

> The silver lining of using this complicated DCP interface is that DCP does in fact run a huge amount of code – the DCP firmware is over 7MB! It implements complicated algorithms like DisplayPort link training, real-time memory bandwidth calculations, handling the DisplayPort to HDMI converter in the Mac mini, enumerating valid video modes and performing mode switching, and more. It would be a huge ordeal to reverse engineer all of this and implement it as a raw hardware driver, so it is quite likely that, in the end, we will save time by using this higher-level interface and leaving all the dirty work to the DCP. In particular, it is likely that newer Apple Silicon chips will use a shared DCP codebase and the same interface for any given macOS version, which gives us support for newer chips “for free”, with only comparatively minor DCP firmware ABI updates. How interesting: by moving some of the driver to firmware, Apple has effectively made it easier for OSs like Linux to have good support for the hardware, because the OS<->hardware protocol operates at a higher level of abstraction and may work across multiple chips. The trade-off is that the protocol is not stable and so Linux has to decide which versions it will support, and make sure the OS driver always matches the version of the hardware firmware: > As a further twist, the DCP interface is not stable and changes every macOS version! [...] Don’t fret: this doesn’t mean you won’t be able to upgrade macOS. This firmware is per-OS, not per-system, and thus Linux can use a different firmware bundle from any sibling macOS installations.

edeion 5y ago
If I recall correctly, high end hard drives used a protocol called SCSI in the 90s that was mostly embedded in hardware.
- minedwiz 5y ago
  Somewhat related, SSDs run an entire microcontroller on-board to translate from I/O requests from the OS to proper use of the flash hardware.
  - vlovich123 5y ago
    If I recall correctly that’s not the case on Apple platforms. They do the translation themselves across raw NAND.

monocasa 5y ago

Are the ASC firmware blobs encrypted too? ie. are they easily available for static analysis?

my123 5y ago
They are regular Mach-Os, with some symbols still available too.
marcan_42 5y ago
Only the SEP firmware is encrypted; all the other copro firmwares are plaintext and your can analyze them to your heart's content.
- grishka 5y ago
  A dumb question. What are they trying to achieve by encrypting the SEP firmware? If they want to prevent people modifying it, won't signing it be enough? Otherwise this smells of security through obscurity, which, strictly speaking, isn't really security, and Apple engineers are most likely aware of that.
  - my123 5y ago
    There's also the HDCP and some other DRM keys in there... but then, they encrypt iBoot too. So can't be all of it.
    - grishka 5y ago
      Yeah because clearly DRM has never been broken and none of those keys are known to the public already.
  - monocasa 5y ago
    Security through obscurity can absolutely be an important layer of a defense in depth strategy. It's just useless as the only layer.
  - marcan_42 5y ago

2bitencryption 5y ago

here's a (possibly dumb) question - assuming a 100% complete and successful "Asahi Linux", what does this mean for distros? Is this a kernel replacement, as in I could run Manjaro Gnome, and just load the Asahi Kernel and it all Just Works? Or will Asahi Linux need to be a full distro of its own, in order to be useful?

idle_zealot 5y ago
It looks like installing a Linux distro on an m1 Mac requires a special installation package, rather than a standard iso. So Asahi is going to be a distro packaged/distributed specifically for m1 Macs, but changes to the kernel etc are being upstreamed, so other distributions should be able to build their own installation media for m1 Macs too in the future.
Raqbit 5y ago
They are working on creating a full distro, based on Arch Linux ARM, which will be an easy-to-use package for end-users with bleeding-edge versions of the software they develop.[1] That said, all components will be upstreamed into their respective projects such that other distributions should eventually be able to add support for Apple's line of desktop computers with Apple Silicon. [1] https://asahilinux.org/about/#is-this-a-linux-distribution https://asahilinux.org/about/#is-this-a-linux-distribution
marcan_42 5y ago
It's several things (yes, we know it's confusing). Asahi Linux is the overall project. m1n1 is our bootloader, which once installed will present a standard (ish) U-Boot/UEFI boot environment. From there you will be able to boot any distro or USB installer, in principle, once the changes trickle upstream. Our installer will install m1n1 and then give you the choice of also installing a distro image. We'll be providing our own based on Arch Linux ARM, but we're open to other distros providing images so we can add them to the list. We already have interest from Fedora, for example. So we expect that people who want to run Linux (or in fact openbsd or anything else) on these Macs will first use our bootloader installer, then either pick one of the built-in images or use their own USB installation media from whatever distro.

jaimex2 5y ago

When the project is done will Linux running on an M1 have any advantages over just running Linux on a regular x86_64 system?

sim_card_map 5y ago
yes, completely silent for one (no cpu fan) also m1 is pretty quick
- helloworld8796 5y ago
  The Pro has a CPU fan. Anyway, the ISA does not necessarily imply higher or lower energy consumption.

adevx 5y ago

Amazing work and any developer should work on whatever he pleases. But there is also something in me that wished development would focus on something more open. What if Apple tomorrow decides only signed kernels are allowed to boot (to protect the children). I know there currently is no ARM laptop equivalent to the M1, and ARM booting is a minefield. So I get that if the M1 becomes a viable Linux target this would be very interesting.

grishka 5y ago
I think Apple has specifically announced at WWDC that ARM macs won't be locked down? I've also read somewhere that they have specifically written some utilities to allow booting arbitrary kernels — they could have very well not done that, so it has to be very intentional. Apple engineers are also probably reading all this and are very impressed.
- adevx 5y ago
  Would love to see a link to that announcement. I'm sure Apple engineers appreciate the skills that go into this, but they have little to no say in Apple's strategic direction which is ever tighter control of the platform. Don't get me wrong, I would love Apple to publicly endorse running arbitrary kernels on M1 hardware.

Br0w 5y ago

Update for all about app for new all systems in account Microsoft Windows and new status version network information Technology system for my akaun Google and support to all new status version system

blinkingled 5y ago

What are the licensing implications of using DCP firmware from macOS installations - just having the hardware and OS license is enough to use it within Linux?

marcan_42 5y ago
All Apple Silicon machine owners are licensed to use macOS (and all of its components), among other things, because it is actually a critical part of system firmware (as part of system recovery; the machine boot picker is itself macOS even). Apple provides restore images for this purpose (downloadable without any authentication). This is how the installer works, so we don't have to redistribute any firmware ourselves. Redistribution is the usual thorny firmware problem; since we don't have to do that, we're in a pretty good position. Whether Apple's EULA applies to macOS obtained in this way, without actually going through a normal boot for that instance and thus the click-through EULA, is legally unclear. That said, here's a quick analysis: 2A says you can only install and run a single copy of the software. That might seem to imply that you wouldn't be able to dual-boot macOS and Asahi Linux, but this clause is pretty dumb. By design, all of these machines with one instance of macOS have at least two copies of part of the software: the recovery image - is that a violation? What about the fact that the bootability process creates a copy of all system firmware? You end up with 4+ copies of some components. What about installing macOS multiple times? Multiple versions of macOS? Do APFS CoW clones count as copies? If so that's another two copies of the recovery image. If they don't, can we just CoW clone stuff from the currently installed macOS version within the same container instead of doing a from-scratch install? Once Apple's updater breaks the CoW link, does that mean they are causing you to violate the EULA at that point? These are all things Apple obviously intended for people to do with these machines, regardless of what the lawyers say, so I don't think we have to worry too much about it. Legal texts are often completely at odds with the technical realities involved, and in the end nobody cares. 2M explicitly allows you to replace the Open Source components of macOS with your own version. This is exactly what m1n1 is: it is a replacement for xnu, the open source macOS kernel. So this clause explicitly puts at least our original full-fat macOS install process in the clear. The clause also says their warranty does not cover damage caused by such modifications, but does not say your warranty is void by merely doing so (so they'd have to prove any damage was caused by it). 2N says no reverse engineering, but you don't care about that, we do. I'm pretty confident I'm not going to get a C&D from Apple's lawyers for working on Asahi Linux, and if I do, I know how to defend myself and what organizations can help with that. It would be terribly bad PR for them to do that. 4A says you can transfer your Apple software, but 4B says you can't do that if you've modified it under 2M. That might mean that, on paper, you can't give away or sell a Mac that has Asahi Linux installed, without first uninstalling the bootloader and having the next owner reinstall it. Again though, this is a silly technicality. What Apple means is they don't want you patching macOS and distributing it separately. They also say the macOS components are a bundle and cannot be distributed separately, but our installer doesn't distribute anything, it pulls specific components from Apple themselves, which they are distributing. 4C says that you may only use copies made available for restorative purposes for those purposes and may not be resold or transferred. That might put our usage of ipsw restore images in the installer out of compliance, though the "restorative purposes" thing is a bit unclear. Does it count as "restoring" Apple's boot components into a blank OS partition? Obviously we are not reselling or transferring anything, so that part is not an issue. This is an EULA, and to what extent these clauses are legally enforceable is of course unclear. We aren't doing the big copyright no-no of redistribution, and Apple themselves provide the software for free download, and it is a fact that every Mac user is licensed to use it. So in practice it would be quite questionable to try to go after people for technicalities here. The better question is whether Apple's lawyers will care, and I'm pretty sure the answer is no. The EULA is there to give them legal ammo against companies trying to do things like provide virtual macOS as a service or installing it on non-Apple machines; they don't really care what end-users do (they don't even care about hackintoshes as long as you aren't selling them, which is a blatant EULA violation). The general idea of running Linux with Apple's firmware is completely kosher per 2M (if done on a single macOS install, e.g. just replacing xnu with m1n1 without a separate OS instance), so there is no legal basis for Apple to block our project entirely. It would be extremely silly if they went after our users to block our specific install process just to annoy them or get them to replace macOS with Linux instead of dual-booting, and it would also put in jeopardy things that regular macOS developers do, like having multiple OS installs.