← Back to context

Comment by LoganDark

7 days ago

If anyone wants to read up on how much effort Apple actually went through to keep Apple Silicon Macs open, take a look here: https://asahilinux.org/docs/platform/security/#per-container...

Secure Boot on other platforms is all-or-nothing, but Apple recognizes that Mac users should have the freedom to choose exactly how much to peel back the security, and should never be forced to give up more than they need to. So for that reason, it's possible to have a trusted macOS installation next to a less-trusted installation of something else, such as Asahi Linux.

Contrast this with others like Microsoft who believe all platforms should be either fully trusted or fully unsupported. Google takes this approach with Android as well. You're either fully locked in, or fully on your own.

> You're either fully locked in, or fully on your own.

I'm not sure what you mean by that. You can trivially root a Pixel factory image. And if you're talking about how they will punish you for that by removing certain features: Apple does that too (but to a lesser extent).

https://github.com/cormiertyshawn895/RecordingIndicatorUtili...

  • On Android devices with AVB (so basically everything nowadays), once the bootloader is unlocked, so many things already either lock you out or degrade your service in various ways. For example, Netflix will downgrade you to 480p, Google Pay will stop working, many apps will just straight up disappear from the Play Store because SafetyNet will stop passing (especially on newer devices with hardware attestation), banking apps (most notably Cash App) will often stop working, many other third-party apps that don't even have anything to do with banking will still lock you out, etc.

    On many Android devices, unlocking the boot loader at any point will also permanently erase the DRM keys, so you will never again be able to watch high resolution Netflix (or any other app that uses Widevine), even if you relocked the bootloader and your OS passed verified boot checks.

    On a Mac, you don't need to "unlock the bootloader" to do anything. Trust is managed per operating system. As long as you initially can properly authenticate through physical presence, you totally can install additional operating systems with lower levels of trust and their existence won't prevent you from booting back into the trusted install and using protected experiences such as Apple Pay. Sure, if you want to modify that trusted install, and you downgrade its security level to implement this, then those trusted experiences will stop working (such as Apple Pay, iPhone Mirroring, and 4K Netflix in Safari, for instance), but you won't be rejected by entire swathes of the third-party app ecosystem and you also won't lose the ability to install a huge fraction of Mac apps (although iOS and iPadOS apps will stop working). You also won't necessarily be prevented from turning the security back up once you're done messing around, and gaining every one of those experiences back.

    So sure, you can totally boil it down to "Apple still punishes you, only a bit less", but not only do they not even punish your entire machine the way Microsoft and Google do, but they even only punish the individual operating system that has the reduced security, don't punish it as much as Microsoft and Google do, and don't permanently lock things out just because the security has ever been reduced in the past.

    Do keep in mind though, the comparison to Android is a bit unfair anyway because Apple's equivalent to the Android ecosystem is (roughly; excluding TV and whatever for brevity) iPhone and iPad, and those devices have never and almost certainly will never offer anything close to a bootloader unlock. I just had used it as an example of the all or nothing approach. Obviously Apple's iDevice ecosystem doesn't allow user tampering at all, not even with trusted experiences excluded.

    Fun fact though: The Password category in System Settings will disappear over iPhone Mirroring to prevent the password from being changed remotely. Pretty cool.

    • This is a pretty wild take.

      Its reasonable to install a different OS on Android, even if some features don't work. I've done this, my friends and family have done this, I've seen it IRL.

      I've never seen anyone do this on iPhone in my entire life.

      But I flipped and I'm a Google hater. Expensive phones and no aux port. At least I can get cheap androids still.

      3 replies →

    • That is a good point. I wish dual booting with different security settings was possible on Android as well. The incentives for Google to implement that aren't really there though.

If anyone wants to read up on all the features Apple didn't implement from Intel Macs that made Linux support take so long, here is a list of UEFI features that represents only a small subset of the missing support relative to AMD and Intel chipsets: https://en.wikipedia.org/wiki/UEFI#Features

Alternatively, read about iBoot. Haha, just kidding! There is no documentation for iBoot, unlike there is for uBoot and Clover and OpenCore and SimpleBoot and Freeloader and systemd-boot. You're just expected to... know. Yunno?

  • To be fair, this is how homebrew for Apple devices has always worked. You've always had to effectively reverse engineer the platform in order to write privileged code. Although I get the argument that if Apple were explicitly trying to support alternative operating systems they probably could have done more to make it easy, really what they were doing with this was first and foremost enabling additional use cases for macOS, and then maybe silently doing it in a way that third parties would also be able to benefit from. The Asahi wiki does a bit of a better job of explaining this, but the suspicion is that Apple did this not necessarily to make it easier for alternative operating systems to exist but to prevent the Mac from needing to be jailbroken when alternative operating systems were bound to happen anyway.

    • It's not how homebrew worked on Intel Macs, or even PowerMacs[0] either. It's a change made with the Apple Silicon lineup - I cannot speak on Apple's behalf to tell you why they did that. But I can blame UEFI as the reason why the M3 continues to have pitiful Linux support when brand-new AMD and Intel chips have video drivers and power management on Day One.

      [1] https://mac-classic.com/articles/open-firmware-basics/

      2 replies →

the only macbook I’ve tried to put linux on was a t2 machine, and it still doesn’t sleep/suspend right, so I’m a bit skeptical that apple is really leading the way here, but maybe I’ve just not touched any recent windows devices either

  • To be fair, sleep/suspend has been a rather infamously difficult problem for Linux when it comes to devices that weren't designed to run Linux. I think the Macs with T2 chips were a bit weird anyway and I wonder if they had already been working on Apple Silicon Macs that far back and that's why the T2 became a thing?

    • Apple is also rather notorious for tinkering with Intel's ACPI files, for better or worse. Suspend is finnecky enough on hardware that supports it, and probably outright impossible if your CPU power states disagree with what the software is expecting.