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.
Macs have always allowed you to run another OS.
iDevices have always had a locked bootloader.
People shouldn't confuse the two.
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.
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.
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.
Apple can lock your Mac just like other manufacturers can do via Intel ME. All of them are backdoors.
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.
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.
> 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.
AMD PSP is little more than an embedded TPM. The capabilities are significantly different vs. Intel ME.
Again, you've got some reading to do.
> the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any type of activity or events and implementing an appropriate response".
Critics worry it can be used as a backdoor and is a security concern.
https://www.wikipedia.org/wiki/AMD_Platform_Security_Process...
> the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any type of activity or events and implementing an appropriate response".
It implements TPM or something similar. It is used in the boot process for a secure boot chain. And the last generic point is probably just that it implements the hardware random number generator for the CPU, which Secure Enclave also does (in a different way).
I could worry about Secure Enclave being used as a backdoor and being a security concern, too. Doesn't mean it actually is!
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.
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.
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.
Could also be pretending to be open while making sure nothing dangerous actually gets made.
I think it would be nice if we could run unsigned apps on iOS (in the US), but booting your own OS on an iPhone is a whole different story
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.
Really, all I want from a phone is to be able to run Linux/xfce on it.
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.
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.
The onus is on Apple to not make iBoot suck, they don't get a free pass for Microsoft-level boot volume ignorance.
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.
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".
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.
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?
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.
if going through trouble means "doing less shit to lock their systems down", then yes.
Apple ultimately dgaf about linux.