UPDATE: It looks like a developer set up a Patreon for bringing Linux to the Apple M1. Although this is unlikely to be a one-man job, supporting his work may help in getting Linux to Macs faster.
As most of us will know, Linux and ARM have been around for several decades, up to the point of considering the Linux kernel the de facto choice for a vast majority of application of ARM (A-series) chips. While this support has shown to be extremely successful for example in the case of Raspberry Pi, or all single-board computers in general, there is an important detail that we should ignore in it: the chips used in these boards were usually chosen because of their openness and often mainline Linux support, not the other way round.
As the field of Android phones taught us the hard way, several ARM chips are still far from mainline Linux support, especially those (like the majority of Mediatek, Exynos and HiSilicon) used in low-budget or entirely in-house manufactured phones. In fact, this has not only been the only limit, due to several manufacturers (Huawei, BlackBerry, some Sonys) preventing bootloaders from being unlocked at all, thus limiting even the theoretical possibility of running a kernel different from the one these devices were released with.
The question is, if the Android phone market is already so fragmented, can we hope to run Linux on the newly presented, ARM-powered Apple M1 MacBooks?
The Apple M1 chip
Let's admit it: this chip is cool. Like, almost as cool as they marketed it. In some ways, we could say it's literally cool, since benchmarks have shown it to be able to deliver high performance, with relatively low heat or power consumption [See: Phoronix]. In fact, even Linus Torvalds claimed to be interested in getting his hands on an ARM MacBooks in the near future, yet corrected himself to state that only proper Linux support (since he has "no time to tinker with it") will make him buy one.
As a reminder, Apple made arm chips for a very long while, since the iPhone 4 (2010), and the Apple Silicon chip used in some iPad Pro models already proved to be some interesting competition to mid-range Intel SoCs used in several of their laptops. And in spite of the M1 chip showing also some limitations of being essentially an overclocked mobile processor, this means that this was the most logical direction for Apple to follow to be entirely in control of their environment while cutting out the growing number of "Hackintoshes".
The first obstacle to running the Linux kernel is so-called "secure boot", which can be seen in a variant in the bootloader locks used both by mobile and (some) desktop manufacturers to prevent "unsigned" kernels from being executed.
This is a policy that Windows tried to enforce for years, since the Windows 8 days, in order to cut out the competition and cut the possibility for users to install Linux on a native Windows machine. This is not the only case when Microsoft tried something similar, to prevent users from exploring alternative software by force rather than by beating the competition. While this trend has been partially reversed by several manufacturers in the next years, as apparently even relatively inexperienced users were avoiding excessively locked devices, the situation has not changed for smartphones, to prevent "software modding" of devices (and in the latest years, also Linux installs).
The good news is that while Apple has implemented a variant of "secure boot" in their bootloader, it left advanced users the possibility to circumvent this by uploading "custom" signatures, which means that compiling and signing a certain Linux kernel will make it work on these devices. This is not as scary as it sounds: Ubuntu has been providing signed kernels for years, and self-signing all new kernels should thus not be required except when otherwise manually (re)compiled. To further confirm this thesis, internal sources at Apple stated that they are not forbidding Windows from running on the machine, but rather letting Microsoft the choice of whether to do a port of Windows to this chip.
In the most extreme case, even if this "custom key" system was revoked, or proved not to be possible in the end (which is at this point very unlikely), there could still be hope for a hardware exploit, like the popular checkr4in which allowed jailbreaking of most modern Apple chips and of the Apple T2 ARM security coprocessor used in Intel MacBooks. This would be, however, a much longer and riskier path, possibly resulting in a theoretically possible, yet extremely limited execution of the Linux kernel.
We could say that drivers are "the ugly" part of the process. While development of these is almost always technically possible, with no public documentation for the chip internals the process of reverse-engineering (or "reversing") the chip may take a very long time.
Since the platform is entirely new, several drivers would have to be developed for this family of devices, including:
- CPU drivers, to support any custom instructions, and other hardware particularities using in the design of this particular architecture
- SoC drivers, since all in-chip components need to be reversed and supported correctly. This includes the inner chip structure, the PLL (in simple words, the hardware affecting the dynamic frequency scaling) and all chip-specific low-level details, such as interrupt handling or even lower level technical and near-electrical details
- All other board components (keyboard, battery charging IC, wireless cards...), which may be hopefully following a fairly standardized structure, or could be at least shared with other existing iDevices, meaning that the work done on Project Sandcastle and this may be overlapping.
The point of it all
As this question seems to come up often in comments, the answer is: "yes, there is".
As nice as macOS may look, users should be aware that their Mac device will become officially obsolete in about 5 to 7 years from its production date, and operating systems updates will become impossible after that date. Combine this with the fact that apps (especially on Macs) are often not well backwards compatible, and your machine will be become progressively more useless in just a few years. Needless to say, a fair share of Mac buyers also like dual-booting Linux when the device is new, be it for personal preference or as a development playground, which makes the importance of native Linux support even more valid.
Finally, if the trend of "signed execution" of apps (see below) continues, even running proper apps coming from outside the Apple Store may get tricky in the future, which makes having proper "escape doors" more relevant than ever.
How much will it take?
The work of porting Linux to a brand-new platform is usually intensive, which means that any time estimate before 2022 for complete support would be too bold even in the best case. But if no particular hardware quirks are encountered, or if the needed work proves to partially overlap with that being done by the Project Sandcastle team in these months, then support may come in a relatively near future.
Necessary rant about locked bootloaders
Although some of you may have noticed how my take on locked bootloaders was not exactly enthusiastic even in the paragraphs above, I imagine some of you feeling puzzled about why locked bootloaders can even exist.
The answer here is simple: they shouldn't. Similar practices in other fields of the consumer market have been illegal for years, which makes it marginally surprising for these to be still so in fields that have not been as widely explored by the law so far. Computers, or CPUs specifically, are made to execute things, the way a car is made to bring you from a place to another, or wheels of a bike are meant to rotate. This means that people cannot be denied the right to execute what they want on machines they legally own, be it after manually disabling some security features that may harm the most inexperienced users.
Yet Windows 10 S (or S-mode) and iOS / iPadOS do exactly this, by preventing all software not coming from a certain, paid and proprietary store to be executed, and macOS is following that route as well. This gets worse when such OS cannot be replaced with another, meaning that one machine will be stuck with executing applications designed for that specific version of that specific OS, for which support will be dropped within a few years from the product launch, and leaving perfectly capable computers as useless bricks in their legal owners' hands.
The European Union seems to be slowly moving in that direction with the "right to repair" laws, although the current laws only prevent carrier ("cellular network") locks after the device warranty ends.
As you can see, the points expressed above were the result of a mostly theoretical analysis from what is known rather than facts. Whether Apple will let you run Linux on its M1 MacBooks is still at least partly unknown. Having said that, is moving consumer laptops to the ARM machines a good thing in general? It depends.
Technically, the answer is yes, by a lot. ARM is efficient, tends to need less heating, follows a more predictable RISC architecture, etc. But as seen on phones, it is still a much more locked-in and fragmented realm than that of x86 chips (AMD / Intel), with a majority of drivers still needing to be written and most secondary chip manufacturers not having enough documentation to allow a clean Linux port so far. Definite Device Tree files (DTS) are needed to run Linux to "know" the board and chip internals, and DTs need reversing, and reversing is a long and resource-intensive process.
It goes without saying that, in spite of the hopes above, buying a M1 Mac for Linux makes little if any sense at the moment - which means just days after its release - but this clearly makes our hopes of us seeing it running there not any less present.