Linux: Coming Soon To M1 Macbooks

Regardless of the chipset or original intended use of any computer system, someone somewhere is going to want to try and run Linux on it. And why not? Linux is versatile and free to use as well as open-source, so it’s quite capable of running on almost anything. Of course, it takes a little while for the Linux folk to port the software to brand new hardware, but it’s virtually guaranteed that it’s only a matter of time before Linux is running on even the most locked-down of hardware, like the M1 MacBooks.

[Hector Martin] aka [marcan] has been hard at work getting Linux up and running on the latest Apple offerings with their ARM-based M1 processors. Since these are completely divorced from their x86 product line the process had to be worked from the ground up which included both booting Linux and modifying the kernel to include support for the hardware. [marcan] has a lot of hardware working such as the USB ports and the SD card slot, and notes that his setup is even compatible with the webcam notch included in the latest batch of MacBooks.

There are a few things still missing. He’s running Arch and doesn’t have the GPU configured yet, so all of the graphics are rendered in software. But he has put the computer through the wringer including running some computationally-intense software for nearly a full day before realizing that the machine wasn’t charging, which did not make much difference in performance. These machines are indeed quite capable with their new ARM chipsets and hopefully his work going forward will bring Linux to the rest of us who still use Macs even if they don’t want to run macOS.

60 thoughts on “Linux: Coming Soon To M1 Macbooks

    1. There’s more to sales than raw sales. There’s support. There’s their brand, their image, which matters a lot to Apple. Apple’s software is a huge part of the value add, in their mind. And they obviously believe that in the big picture it’s in their interest to keep it to Apple.

      As I age I’m coming to appreciate using tools for projects and not letting the tools become the projects themselves. If I want to run Linux, I’ll do it where there’s the best support. Probably first in a VM. Raspberry pi if I want to interface to special hardware.

        1. I don’t think this is correct. They didn’t have to consciously engineer it to run alternate OSs, they simply had to neglect the likely futile effort of making a system that specifically CANNOT run an alternate OS. MS and Sony have both tried with their game consoles, but they keep failing. Apple has tried with all their idevices, and they keep failing. Why waste the money? Instead they have Apple IDs and large numbers of dedicated and ignorant customers.

          1. This isn’t an x86 PC where the platform is naturally open and it isn’t open by neglect. As Hector put it, they could have cloned their entire locked-down system from the iphone (which uses a nearly identical chip), but instead they set up a system where you could register alternate OS kernels to boot. It’s radically different and they really didn’t have to go to all the trouble to design and build it, just for the M1, when everything else is the same.

        2. More likely, and alternative not scenario is for factory reset and development and they just didn’t lock down the option. Not closing something isn’t the same as making it open.

          Unlike the iphone they don’t appear to be assigning part alignment to the extent of iPhones. That said it doesn’t mean they’re supportive of third party OS options.

          The likes of XBox and Playstation make the extra effort as hardware is a loss leader for Mike than half the product life and make money from licensing for content sales and access. Apple makes money in the hardware and the desktop/laptop tools are required to build iOS applications… Where they make most of their money.

          I’m pretty sure creative professionals are a secondary thought at this point beyond supporting iOS development. They like the mindshare but it’s not the biggest money maker.

    2. Apple is not disallowing it. It’s just they are not supporting it like they did with bootcamp. That would mean they would have to develop and support drivers for the custom SoC which they would probably never make their money back on.

    3. It would be super interesting as its such compelling hardware, I wonder though if the sales would be enough to “move the needle” for them. If it officially becomes supported I’d more quickly assume it being an internal pet project.

  1. Hey Bryan! I give you ten gold stars. The most I have ever given anyone. You actually wrote “run through the wringer”! I am so accustomed to seeing morons write “run through the ringer”. So refreshing and so right.

    Hearing about linux on the M1 is cool too. Thanks.

    1. The insanity called upstart and snap is the real issue, not systemd. Granted that systemd still requires lots of polish (e.g. it still cannot do nearly all the stuff cgmanager did but you cannot use both) and lots of documentation still only documents the old way without systemd. However, systemd can actually handle user sessions by keeping each session in its own cgroup.

  2. This article doesn’t reflect reality.

    This is possible specifically because the M1 machines *are not* locked down. As [Hector Martin] put it, apple had to intentionally engineer a way for them to run alternate OSs.

    [Hector Martin] is also by far not the only one working on this. There’s a team of at least half a dozen people. Alyssa Rosenzweig, for example, who has been developing an openGL driver for the M1 GPU.

    The note that the install is notch-compatible was a joke. It isn’t. The notch simply happened to cover a region whether there isn’t anything on the GUI bar. In the final version, it’s likely they may disable the entire top row of the screen in the graphics driver.

    By far, the most important thing about this work is that it’s upstream-first. Corellium also made an M1 port but it’s an awful hacky mess that will never see the light of day, much less the mainline. That suits them just fine, but the Asahi devs have been continually cleaning up and upstreaming all the drivers, in a modular format, such that supporting future chips may be as simple as tweaking the device tree configuration.

    1. Fanboi much?

      >[Hector Martin] is also by far not the only one working on this

      From looking at the commits for M1 on the LKML he seems to be one of the least involved.
      If you’re one of the people that is sponsoring Hector maybe you should consider redirecting you money to the Sven guy as he seems to be the most active.

      >Corellium also made an M1 port but it’s an awful hacky mess that will never see the light of day

      Corellium posted their port to the LKML while Hector was making his big song and dance about how he was going to be the guy to port Linux to the M1 based on being sent from heaven to port Linux to the PS4 (Which never got mainlined and is abandoned AFAIK). That made Hector go bananas on twitter and accuse the Corellium guys of not doing the work to his high standards, basically not doing it behind his Asahi banner because he’s the only one allowed to port Linux, blah blah when it was pretty obvious he was just annoyed that they beat him to the punch after making so much noise.

      >but the Asahi devs have been continually cleaning up and upstreaming all the drivers, in a modular format,

      By using the standard linux driver model like every other platform supported by Linux and the Corellium guys also used? You better get on the LKML and tell everyone, including the guys that came up with the driver model/device tree etc, about this massive new technological wonder the asahi project has introduced to Linux so well that it existed before the Asahi project and was written by totally different people.

      1. It’s a absolutely a team effort. Sven is the most active on the LKML because he’s working to polish code for upstream inclusion. At the same time Sven is not the one doing the bulk of the reverse engineering work. And then there’s the openGL driver, which neither of them work on.

        Nearly none of Corellium’s work is fit for mainline inclusion, and nearly none of it is in the mainline. A prime example is the nasty hackery they did to make PCIe work, which would have completely screwed over literally every other CPU on earth that uses PCIe. It was, like DEC’s port of linux to alpha, largely exploratory for them to learn more about how to emulate the M1 for their own business. In the end the alpha port that got merged was a separate effort undertaken by Linus.

        The thing that sets they way they’re doing things apart is the THIS IS NOT how it’s normally done for SoCs. This is indeed normal for the vast majority of linux-supported platforms. In SoC land, however, it’s almost always the case to merge one massive fucking driver for every single model of chip. This one driver covers ALL the functional blocks in the chip, fron USB to GPIO to PCIe, and is all melded together. This makes it much more difficult to support future versions with different numbers of the basic building blocks or other small changes, and it’s something Asahi as a whole seeks to avoid.

        Learn to look beyond the LKML. Most of the work of Asahi happens off-list or has yet to land. For example: https://rosenzweig.io/blog/asahi-gpu-part-4.html

        1. >In SoC land, however, it’s almost always the case to merge one massive
          >fucking driver for every single model of chip.

          Even if that was true. It doesn’t matter. Linux has a generic driver model that can handle multiple variants in a single driver and has for a long time. Asahi didn’t bring anything new to the table there.

          >This one driver covers ALL the functional blocks in the chip,
          >fron USB to GPIO to PCIe, and is all melded together.

          And it doesn’t work like that in Linux and never has. Do some of your own research.

          1. “can handle” and “is actually done this way in the real world” are to completely different things.

            Come back when you’ve actually tried to grok some nasty vendor downstream kernels.

          2. >Come back when you’ve actually tried to grok some nasty vendor downstream kernels.

            I’ve done exactly that. I’m the maintainer of an ARM platform in mainline that was entirely reverse engineered via ghidra and scraps of vendor code.

          3. >but none of the Corellium patches have ever landed on mainline and never will.

            Because Hector made a stink and they let him have his way.
            In a parallel universe the Corellium guys cared more, told Hector that he doesn’t own the right to mainlining a platform and worked on their series for a few months and got it mainlined.

            >It was never intended as anything more than a publicity stunt

            That’s irrelevant. Lots of people have ulterior motives for getting their code into mainline. One of the most common is being able to make out you are a core Linux kernel dev on your CV because you once sent a drive by patch that actually made it in.

            >1) the M1’s absurd power/efficiency

            Don’t care.

            >2) the speed at which the various parts of this port have come together

            Nothing to do with the years of hard work others have put in to make it not an complete shit show to get a new ARM64 platform support then?

            >3) the completeness of the port. It’s rather impressive that they’re covering

            It is impressive considering there is no documentation etc but it’s not the second coming.

          4. Nothing ever pleases you does it? No meaning in your life?

            It’s clear by now that the only reason you’re here is because you have a vendetta against Hector and company and are incapable of rational thought on the subject.

        2. Sorry for the double post but this is important.

          >Nearly none of Corellium’s work is fit for mainline inclusion, and nearly none of it is in the mainline.

          Neither was the Asahi work. The whole point of the LKML and the kernel development process is that you publish, get comments, re-work, get comments multiple times before someone pulls your code.
          If you are not sure how something should be done properly you basically have to throw your junky “works for me” code out to the LKML to get it seen by the people that can tell you it won’t work or will break everyone else’s stuff.

          I’m not sure why the Asahi work has to be some groundbreaking thing for you. This isn’t the first time some weird platform has been reverse engineered and added into the Linux kernel. The GPU RE is interesting but aside from that this is just another bring up of a poorly documented ARM SoC.

          1. That’s great and all, but none of the Corellium patches have ever landed on mainline and never will. It was never intended as anything more than a publicity stunt and learning experience for the engineers developing their emulation platform.

            What makes Asahi somewhat special are the following:

            1) the M1’s absurd power/efficiency

            2) the speed at which the various parts of this port have come together

            3) the completeness of the port. It’s rather impressive that they’re covering so many details of the SoC. Power management? certainly not mandatory.

  3. Since nearly all FOSS apps available for Linux are also available for macOS and there is commercial software which runs on macOS that is not available for Linux, it’s not clear to me what the advantage is of running Linux on a Mac. Well, other than being able to say “I got Linux to run on a Mac!”

    1. The advantage lies in being in control of your system and those apps that got waved away under “nearly all”.

      Even if you really wanted to and had the knowledge, you’d have a hard time changing the MacOS kernel. It’s relatively easy on Linux.

      Really, if you can’t see the advantages of running Linux instead of MacOS, you’re not trying, you’re fanboying.

        1. Damn near. After the bootloader jumps to your code, you have full reign over the main CPU cores with nothing able to interrupt you. Contrast that with SMM on x86, which can interrupt everything, kernel included, for anything it likes for as long as it likes.

          There are lots of little cores for all kinds of small purposes, but guess what, even RMS’s thinkpad has those (what did you think controlled thermal throttling?). On the M1 they’re isolated from the main CPU core by way of one of two different mailbox interfaces. Those which need DMA (eg wifi and graphics) are on the other side of the IOMMU barrier.

          There’s no ME-like little core that has access to the whole damn system, anywhere at any time.

    2. @Isaac said: “Since nearly all FOSS apps available for Linux are also available for macOS and there is commercial software which runs on macOS that is not available for Linux, it’s not clear to me what the advantage is of running Linux on a Mac.”

      The advantage of running Linux (or any system other than Apple’s macOS) is it distances yourself further from Apple:

      If you think Apple will allow Linux (or anything else for that matter) to “infect” macOS, you don’t know how truly Evil they are. That is ironic though given how macOS is really a Frankenstein system built in large part with the stolen bones of other people’s labor. But Apple’s Marketing is so good, few of their users know about this. Here’s an example:

      https://hackaday.com/2021/03/21/the-long-journey-ahead-for-linux-on-apple-silicon/#comment-6333028

      This is the Unix Timeline which shows the spawn of macOS from BSD UNIX (the Berkeley Software Distribution) via a short hop on NeXTSTEP v3.3, another BSD derivative that became proprietary, to vacuum up anything Apple likes along the way:

      https://en.wikipedia.org/wiki/File:Unix_timeline.en.svg

      With the exception of NeXTSTEP which Apple bought-out in 1996, in my opinion Apple’s predation on Free Open Source Software (FOSS) continues through today, and I have never heard of one instance of Apple giving anything back to the FOSS community contribution.

      Finally, don’t forget Apple lobbies against efforts to stop slave labor in Communist China, where it builds many of its products:

      https://www.washingtonpost.com/technology/2020/11/20/apple-uighur/

        1. Where did they say they would buy any Apple hardware?

          To me the stupendous prices they tend to charge, usually for often rather poor hardware (for the price) in its shiny case is enough to avoid them, every now and then they get something really right ahead of the competition, be it that massive actually nice to use trackpad that as far as I know was the first decent trackpad ever put in a production machine, or these new M1 chips that really do seem to be quite impressive, to the point that for once the cost of the machine actually feels somewhat justified – high performance, and high efficiency for good battery life – maybe the current crop of AMD cpu with their blistering performance and great calculations per watt are better for you, it would certainly be my choice of the two, but no denying the M1 chips look good for a great many things.

    3. MacOS is much more of a pain in the ass to use if you’re not within the narrow use case they design for. It’s chock full of restrictions.

      Linux is also the go-to OS for building software and doing real work. Being able to run a regular linux distro means being able to follow along with the packages and dependencies they ship, rather than try to hack them to install on macOS. It’s hard enough matching between versions of ubuntu, nevermind going to a completely different OS.

      1. I fully agree. Every Apple device is about user adjusting to the system, not system being capable of being adjustable to user needs. If you are not technical, it could be a blessing. If you know how you want your window manager or whatever part up work and your wish doesn’t match with Apple design, you’re out of luck with Apple official software.

    4. There are specific areas of business where Linux is dominant e.g. some areas of data science, bioinformatics, high power computing, particle physics and using anything else than Linux is a bit of a pain as using anything than MacOS for e.g. in graphics design is a pain and a hustle.

  4. “Apple reserves CPU register x18”, is there any public information about how Apple are using this register yet ?

    It means that any hand crafted assembly code for normal AArch64 systems may need to have a special version that does not use the x18 register created for Apple M1 hardware. It may even have a knock on effect that people will stop using x18 when handcrafting code for AArch64 systems to avoid needing two version of their code.

    I saw this yesterday while reading up on GNU Multiple Precision Arithmetic Library after seeing the Karatsuba’s algorithm article here. And the Apple developer site states this for Apple hardware: “The platforms reserve register x18. Don’t use this register.

      1. What I was really wondering was if it was a software or a hardware thing. Basically if you are not using OSX, which might be using it for some internal special purpose, then you can use it. Or does the M1 chip use the x18 register for some internal special purpose, in which case …

  5. It’s nice these days that you can get hardware that supports Linux and is relatively open or even very open. The manufacturers of those things need your support. Apple doesn’t need you for any reason whatsoever.

    I put my money in a PinePhone Pro yesterday, instead of Pixel 6 or similar locked-down thing.

    1. I completely agree with your sentiment, but a Pixel can be VERY easily rooted and have the entire Android OS replaced. Google provides the tools. An iPhone would have been a much better example of your point, especially since you’re already talking about Apple.

    2. But when proprietary hardware is better (and M1 in many ways is better than x86 laptops or even other ARM laptops), extending Linux support to it by whatever means benefits Linux. Whether to buy Apple hardware in first place is a different choice that everyone has to make personally.

      1. Hector also made the point that there’s lots of sub cores running firmware you talk to through a mailbox, on the M1 you *completely* own the main CPU cores. After the bootloader switches over yo you, that’s it. You’re in charge.

        On intel systems there’s system management mode, the ME, and all kinds of other lower-ring crap to deal with that makes the CPU impossible to trust. The apple CPUs are no POWER9, but they’re leagues ahead.

        1. >lots of sub cores running firmware you talk to through a mailbox,

          Ok.

          >on the M1 you *completely* own the main CPU cores.

          Ok.

          >that’s it. You’re in charge.

          How does that make any sense if you have lots of sub cores and you own only the main CPUs and you can only imagine what the sub cores do as you only see the mailbox end of the sausage factory.
          You better hope those sub cores don’t have access to the address space as the main CPU and can spy on what it’s doing.

          >On intel systems there’s system management mode, the ME,
          >and all kinds of other lower-ring crap to deal with that makes the CPU impossible to trust.

          This is exactly the same except they are doing it with multiple external CPUs instead of relying on say ARM Trusted Firmware running on the main CPU with carve outs that the normal OS can’t see.
          Those other CPUs are in the same die as the main CPUs. Potentially they can spy on everything the main CPUs are doing totally undetected.

          1. On an intel CPU an SMM (System Management Mode) interrupt may arrive at any time and kick everything off all the main CPU cores. Doesn’t matter if they’re all kernel threads. The SMM task then runs for as long as it wants and accesses whatever it wants, before eventually returning to whatever was running before. Linux’s only defence? Kernel panic if it’s detected that you were in SMM mode too long, after you eventually come back.

            That straight up cannot happen on the main CPU cores of the M1. Once the bootloader finished it’s job and jumps into the kernel, the kernel has complete control over everything those cores do. Nothing can interrupt it.

            The sub cores do not have direct access to the main system memory. That’s what it means to be behind a mailbox interface. Communication between them and the main CPU is very strictly controlled. For components like the wifi or display driver that also have DMA access for passing things like packets or framebuffers, they’re sheilded from the CPU/RAM by the IOMMU, which is something Asahi have been able to get working.

            The ME differs from these sub cores because, again, they don’t have access to the main CPU, or RAM, or really much of anything at all. They all have only their specific small job to do, and they’re communicated with through one of two kinds of mailbox. The ME, by contrast, can access absolutely anything at any time.

            Do some research.

          2. >The sub cores do not have direct access to the main system memory.

            Ok…

            >For components like the wifi or display driver that also have DMA access for passing things like packets or framebuffers, they’re sheilded from the CPU/RAM by the IOMMU,

            Oh so they actually do have access to the system memory. Make your mind up.
            You seem to be forgetting that the sub CPUs are on the same die. For all you know the sub CPUs can directly spy on bus traffic and/or can see all of the CPU registers.
            As none of this is publicly documented you don’t know so you can’t make any claims either way.

            >That’s what it means to be behind a mailbox interface.

            The mailbox is an interface. It says nothing about what buses etc those other CPUs can see.

          3. *Do you understand the concept of an IOMMU?*

            Anything on the other side of an IOMMU *does not* have direct access to main memory. Any region it needs to read or write to must be explicitly mapped by the driver.

            Those other CPU’s aren’t attached to any “other busses.” Most of them are things like standard USB-C interface chips. Take your tinfoil hat back to roswell or learn to fab your own chips because nothing else will ever satisfy you.

  6. Why Linux: I recall an x86 Xserve review perhaps 15 year back that included benchmarks for Apache 2 and MySQL comparing performance with OSX, Linux, and a similar Dell running Windows Server. For a variety of reasons, starting with how the Mach and Linux kernels spawned processes, the Linux Xserve configuration processed considerably more requests/sec than OSX. If these reasons are still true, it’s one rationale to run Linux on your M1 Mac.

    1. Linux has eaten the world, and these M1s are the pretty much the fastest hardware around.

      So of course the Linux guys would love to get their hands all over them. :D Even Linux Torvalds wants one, if it can run linux.

  7. Full PC’s running on ARM was my prediction years ago and everyone would just dock their phones so they have all their data everywhere and enough power for everything. I thought apple would go that route instead of just putting it into a MacBook shell and can’t even lock it down, guess they have lost their touch.

    1. They intentionally DID NOT lock it down. They could have used the same system they use on iphones (which have damn-near-identical chips) but instead they expended a huge amount of time and effort ENGINEERING a boot policy system that allows other OSs to be loaded and run. It is no accident that running linux is possible.

      The reason nobody docks a phone like this (except the PostmarketOS people, who only have phones to work with anyway) is because phones are tiny and weak. You can put a much beefier chip in even something as small as a laptop, nevermind a desktop.

      ARM was always coming. x86 pays an enormous price for the complexity of it’s badly-design CISC instruction set, and the M1 happily bypasses that price for both high performance and high efficiency. I can’t wait to see it scaled up to a massive many-core monster. The limiting factor is memory bandwidth. The M1 already has the memory bandwidth of a 8-channel server motherboard, thanks to it’s tightly integrated ram chips.

  8. I’m typing this on my M1 Mac, I have Multipass running which easily spins up an Ubuntu virtual machine. And I can create Docker containers with ease. Do I have a Linux desktop? No, that’s the only bit not there (as far as I know). Honestly, I’m pretty happy with what works right now.

    1. I expect the M1 has lit a fire under a lot of companies peddling semi-custom chips with bog-standard ARM cores to come up with a more powerful, competitive product. This can only be a good thing.

  9. Oh boy, a new architecture that cuts corners on protocols (ie, can’t book off an external disk if your internal one is broken) and can’t run most software even after a year of people trying to port it.

    I don’t understand why anyone is excited about this. It’s crap console hardware good only for use in the specific configuration that Apple ships them. Anyone wanting to do anything more (or less) will be out of luck.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.