It seems like this is a bug, apple went through the trouble to allow something like asahi to be possible in the first place. I doubt they're purposely trying to break it.
Apple designed a bootloader for Apple Silicon Macs that allows you to run an unsigned OS without degrading security when you boot into MacOS. This wasn't an accident.
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".
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.
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).
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.
Apple's Secure Enclave and ARM's Truszone work the same way as Intel ME and AMD PSP. All of them have a separate specialized minimal OS running on a specially protected memory that cannot be accessed by the normal OS.
Apple can lock your Mac just like other manufacturers can do via Intel ME. All of them are backdoors.
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.
> ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included)
Either this is untrue or misinterpreted - the SystemReady DeviceTree band (the only one Macs could possibly fit into, given they don't implement ACPI) still requires that devices implement EBBR, which requires that devices implement UEFI. Macs don't, and so are very much not SystemReady compliant.
>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.
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.
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.
And if Apple were going to change their mind and try to block linux, they would intentionally modify the bootloader to remove that functionality, not break the boot picker.
I have fond memories in the early 2000s of getting the first MacBook Pro's with Intel Core i7's and the first thing we did at my company was build and install gentoo.
Reminds me of when the Xbox 360 came out, Microsoft had to buy a bunch of Macs because Macs had PowerPC processors, so it was kind of a no-brainer to get the darn thing going quickly enough. Ultimately Windows was the standard way to build Xbox games but it is kind of funny to think, one day someone at Apple saw an order for easily several dozens of Macs from Microsoft, and wondered if hell froze over.
Back in the 2000s MS agreed to port Office and Internet Explorer to the Mac. This was a good move for both companies. Bill Gates appeared on screen during an Apple Conference to talk with Steve. Huge boos. Steve had to work the crowd back from the ledge.
Then Office and IE were ported. It was so weird running Word on a Mac. It was a good port too. They did a good job of embracing Mac UI ideas. I found the Mac Word better than Win Word.
I was kind of new to the Mac back then.
I imagine Apple donated a bunch of early OS 10 machines to MS for development. I wonder if the MS Mac Dev team was a pariah at MS.
Word was originally released for the Mac in 1985, so the deal was not that Office would be ported, just that MS would keep developing Office for the Mac.
> I think it would be nice if we could run unsigned apps on iOS
Apple enforces those restrictions via the permanently locked bootloader. The main benefit of unlocking the bootloader on an iPhone would be to run a modified version of iOS that allows for the installation of unsigned apps. Apple wouldn't like it and might even get litigious over it, but still.
> (in the US)
Apps intended for release onto alternative app stores in the EU, Japan, and Brazil still need to be approved and signed by Apple. These laws were nearly useless.
I think iPhone hardware is better for the price on the used market. (I refuse to buy new phones. They're too locked down and shitty to warrant spending that much.)
IDecices should absolutely be treated as laptops and desktops which allow another OS to run on the device. This why I have not bought an Apple device for years.
EU is the only governing body that would push owning the device you _buy_. Unfortunately their seem more geared moving to a surveillance state at the moment with chat control.
They're different for now, but it's frog-boiling. Apple has been steadily adding more and more hoops to the process for Macs, and eventually they are going to end up as locked down as iPhones.
The boot flag was undocumented, like most features of Apple devices that are required knowledge for being able to port another operating system to them.
Because of this lack of documentation, every release of a new version of Apple hardware or software may require the restarting of the reverse engineering work, like in this case, just to keep working the alternative operating system.
The boot flag might have been undocumented, but so was absolutely everything else that was reverse engineered to make Asahi possible.
Rather than blaming Apple for this, the correct approach would have been to post something like "if you dual boot Asahi, don't upgrade to macOS 27 until you've done this".
I keep wondering when "undocumented" stopped meaning "don't rely on this because it can and probably will change at the vendors will and they don't want you to shoot yourself in the foot and then you're on your own"? Nothing was "owed" for the undocumented...if it worked after an upgrade, it was a good day.
The "correct approach" is "Apple doesn't support Linux on M-series processors. If you're not willing to accept shit breaking regularly and having to do (much more likely, relying on other people without compensating them) the actual work to RE Apples ever-changing stuff then don't buy hardware that explicitly does not support the OS you want to run. If you want 'plug-and-play', you are barking up the wrong tree." This really isn't hard.
Back in the heyday of Hackintosh, there was always someone who wandered into one of the forums to shittalk Apple for not supporting some chunk of hardware they owned but Apple never shipped (usually with some whining to the effect "Windows supports my knock-off of a knock-off Alibaba special and it's totally unreasonable that unsupported MacOS on unsupported hardware doesn't Just Work!"), but I don't recall the adults in the room giving that sort of nonsense the time of day other than to say "here's the stuff that we know works...if you don't have that, it's on you not Apple or the uncompensated Hackintosh devs to figure it out".
How times change, I guess.
Edit: s/plug-and-pay/plug-and-play/ Freudian slip, I guess.
The 'onus' is on Apple to support an OS they never said they'd support, to the potential detriment of the one they do support, because a tiny number of people bought Apple hardware to run...lemme look again...an OS Apple never said they'd support? That's an...interesting...point of view, but probably not suprising considering the pervasive "how dare you not do unpaid work to make me happy no matter what your priorities are" attitude running around OSS these days. At least Apple won't rage-quit the project or have a nervous breakdown because the free-riders are demanding something never promised.
Such bugs have happened and been reported before. Asahi exercises "raw boot" facilities that just don't get all that much attention in any other context.
If the happy path disappears, the not-so-happy path will be taken to allow for booting custom kernels, one that will likely rely on turning the some or a lot of the RE energy towards breaking the Secure Enclave, the bootloader, and so on. Apple practically laid the red carpet out to avoid people trying to crack the parts of the hardware/software chain-of-trust they would really rather not have cracked. A similar strategy helped keep the Xbox One un-pwned for over a decade (running homebrew was allowed in a specific mode). It is doubtful Apple's legal department isn't aware of the value of the current software strategy.
Nothing is perfectly secure on its own. No system designed or checked by humans ever will be. After all, the Xbox One was indeed pwned, relatively recently. However, because the juice wasn't worth the squeeze for so long, it got pwned years after it was a relevant, money making console.
Novel jailbreaks for ancient iPhones are not worth much. But attention on current, brand new devices means increasing the danger that a mistake gets found, which increases the odds that that mistake is found by someone who wants to sell it for the most money. Also, from Apple's perspective a zero-day in the bootloader on macOS also means a zero-day in the bootloader in all of the billions of iOS devices out there too. They do not want to give anyone anymore reason than what already exists to try and pwn LLB or iBoot. Given a happy path, all of that hacker energy for "put Linux on my M1 Macbook" is put towards device drivers and support, rather than "how the hell do we get an alternative kernel booting on this thing".
Fewer bullets pinging off the armor. Fewer cracks in the fuselage forming. Fewer knives to dodge. All of it means Apple's boot process for their current devices are less likely to be pwned before they turn into e-waste (whenever that is, not making a comment on Apple's perhaps accelerated or otherwise practices in obsolescence).
Just like a jetliner will eventually succumb to entropy and become dangerous to fly, so too will a lot of "secure" software. You only need to actively maintain a jetliner while it is flying passengers or cargo. Once it is retired, it can rot, people can break into the husk of it at the junkyard and fornicate and smoke crack and smash windows and steal parts of the fuselage. At that point, who cares?
No, if their lawyers want it gone, Apple will just update the bootloader to reject local signing keys.
The actual problem was that Apple has an undocumented APFS key for if a volume is bootable, which Asahi wasn't setting and Apple wasn't checking, but now they do, so they do.
Macs have always allowed you to run another OS.
iDevices have always had a locked bootloader.
People shouldn't confuse the two.