Comment by hollow-moe
3 days ago
M series macs are weird tho, yes the bootloader allows it but absolutely no documentation on the hardware, drivers etc. Can't help but to think the goal of this wasn't to actually allow third-party OSes, but for development purposes(and ye they could hide the feature behind apple account with paid dev license) or anti-anti-trust measures à-la Google with Firefox: in front of a jury of normal people they can simply say "look there's these nerds making Asahi" the same way "look we're not a monopoly Firefox has .2% market share".
> M series macs are weird
More weird than the opaque Management Engines on Intel or AMD chips that can take full control of your system at any time that you have no control over?
> Can't help but to think the goal of this wasn't to actually allow third-party OSes
Apple has explicitly stated that allowing third party OSes is exactly the purpose of the new bootloader.
I don't know about Intel ME but AMD PSP is basically the equivalent of Apple's Secure Enclave, so there's that.
You should probably do do some reading on the subject to gain a bit more understanding:
> This puts [Apple Silicon Macs] somewhere between x86 PCs and a libre-first system like the Talos II in terms of freedom to replace firmware and boot components; while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even old ThinkPads).
https://asahilinux.org/docs/platform/introduction/
The Secure Enclave is equivalent to a PC's TPM (a TPM is now required to run Windows) not any form of a management engine.
3 replies →
Did Apple state it? I remember it was one of the lead engineers who worked on Apple Silicon, which I guess could count as an Apple statement
Yes, more weird than that. x86 PCs have fairly standardised boot and autoconfiguration (UEFI and ACPI). ARM based systems, including the Apple M series, don't. You just have to know what's there (device trees), and Apple isn't going to tell you. Hence why it's difficult to make another OS run on it, because you first need to find out what hardware's even there, and how to talk to it. It's initialised by Apple before iBoot runs, sure, but you don't even know what it is, so good luck writing a driver for it.
The Intel ME / AMD PSP are creepy, and probably a security risk to the device owner, but they're not weird, you can run an OS without even knowing they're there, and they like it that way.
Asahi Linux already does use an open source UEFI implementation (U-Boot) to boot Linux.
https://en.wikipedia.org/wiki/Das_U-Boot
The Asahi installer will also allow you to install UEFI alone, in case you want to use UEFI to install some other OS.
The hardware management engines in modern x86 chips are backdoors running at a higher privilege level than the installed OS's kernel.
It's hard to see them as anything else.
3 replies →
It's true that UEFI and ACPI cover a lot of ground whose equivalent on Apple Silicon is undocumented. But note that Linux on x86 does still rely on lots of reverse-engineered drivers to talk to various devices - not necessarily on servers which are designed to run Linux, but very much so on desktops and (especially) laptops.
>ARM based systems, including the Apple M series, don't.
You're thinking of old SBCs, most likely. ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included) have +/- same level of auto-configuration and hardware resource discovery as x86 PCs.
2 replies →
>More weird than the opaque Management Engines on Intel or AMD chips that can take full control of your system at any time that you have no control over?
Considering they're pretty much fully undocumented (officially, that is) and could contain any number of IME equivalents since we know that they already have independent processors like the secure enclave running its own OS: yeah, probably more weird. Just because Asahi did not find one doesn't mean it doesn't exist.
There are plenty of people looking, not just the Asahi people.
That's just a normal part of Mac development. Apple sees documentation as a net negative for them, something that can constrain them in the future. So they only document the major highways and leave everything else as an exercise to the reader.
If you're using an unstable API they expect you to figure everything out yourself. It doesn't mean that they don't want you to use it though.
I think they are wary about macOS becoming a designated DMA gatekeeper, it would certainly be very close to the user and income thresholds.
> Can't help but to think the goal of this wasn't to actually allow third-party OSes, but for development purposes
Could also be pretending to be open while making sure nothing dangerous actually gets made.
The design of the exposed mechanism is explicitly about booting unsigned versions of MacOS. There is zero support for booting anything else, but no enforcement that it must be MacOS.
However, apple's justification for exposing this mechanism to users appears to explicitly include "booting linux" even if the mechanism has zero explicit support for booting linux.