Incorrect. Apple's original presentations on Arm Macs suggested that booting other operating systems would be supported, and recently this has been confirmed by two of the engineers who worked on it. twitter.com/NikolajSchlej/status/133979… twitter.com/XenoKovah/status/1339914714… Although you cannot turn off secure boot on Arm Macs, Apple has deliberately provided a path by which you can prove that you really want to chainload to a user provided bootloader not signed by Apple. From there, obviously, it will be possible to load the kernel of another operating system, such as Linux.

> It probably wasn't a quick hack that a couple of guys stuck in when nobody was looking. I mean, that's not what the parent comment said: > I agree that this is mostly a small number of engineers (with approval) being helpful. Here's some more details from someone who actually worked on this: twitter.com/XenoKovah/status/1339914714…

The guy that did the boot loader work made it work that way on purpose: x.com/XenoKovah/status/1339914714055368…

I think the dev that was responsible for the bootloader or some security chip having the option to be opened posted on twitter a while ago. Pretty sure he implied or mentioned that this was what he was hoping for. Edit: this was what I was remembering: x.com/XenoKovah/status/1339914714055368…

Being most-upvoted doesn’t mean there is any truth to it. The “principle of least privilege” is a cornerstone of developing secure software and if you view Apple’s new security features through this lens you can see what they are doing: sandboxing and translocation, moving input processing to isolated services, requiring permission before accessing privacy-sensitive APIs, preventing privilege escalation through inter-app debugging/tracing/code injection, etc. Code running in the kernel violates this concept and the only way to put up walls is to eject it to userland. And maybe having things like huge network file system implementations in the kernel wasn’t a great idea for system stability or security in the first place. macOS will continue to be locked down but Apple has consistently built “escape hatches” for tinkerers: System Integrity Protection can be disabled; all Macs including the M1 can boot non-Apple kernels[0]; the kernel can be built from source[1]. The iPhone security research device program was in response to complaints about iOS being too opaque, and was a significant reversal in Apple’s position in locking down its crown jewel OS. You can argue they don’t go far enough with those escape hatches---I sympathize, speaking as someone who publishes a kext that patches the kernel. I hate that holding certain kinds of entitlements makes a process much more difficult to debug. And they can always change their minds later. Orthogonal to least privilege is vetting that code is trusted, which is the root of fears over an App Store-only software distribution model, but most changes regarding code signatures can similarly be viewed through the lens of malware protections, given a sharp increase in the number of attacks targeting macOS. 0: twitter.com/XenoKovah/status/1339914714… 1: kernelshaman.blogspot.com/2021/02/build…...

Windows on arm64 systems aren't locked down. Meanwhile for arm64 Macs, they aren't either. Yesterday, twitter.com/xenokovah/status/1339914714…... was released to run unsigned kernels.