[2636381321]

I wonder if malware could bypass the speaker safety daemon and potentially damage hardware or even start a fire? Looks like Apple is relying too much on TrustZone and Secure Boot to prevent physical hardware damage?

Also, Apple can now say that jailbreaking the devices could present a physical safety issue. So one more reason for making jailbreaking illegal?

[seba_dos1]

There are and always have been lots of ways for malware to damage hardware.

[Dalewyn]

"Modification can lead to danger." has been an excuse used against end-user modification for as long as the concept of legal liability has existed.

It's why most things have "warranty void if removed" stickers and warnings against messing around all over the place. Once anything is intentionally moved out of spec, the manufacturer wants nothing to do with it (and rightfully so).

[krunkcoin]

1. The consequences of playing loud sounds with no protection are unlikely to involve open flames. You're just going to fry speaker coils, after which they won't sound good (or make much sound at all).

2. Apple doesn't implement TrustZone. They don't even implement EL3 (the exception level typically used for TZ) in their Arm core designs, just EL0 (userspace), EL1 (kernel), and EL2 (VM monitor). They appear to have completely rejected the concept of an above-the-OS supervisor responsible for security and other system maintenance tasks, which is the idea behind things like TrustZone and Intel's insane System Management Mode.

3. One of the fairly novel things about Apple's Arm Macs is their secure boot infrastructure. Although it's clearly derived from iOS secure boot, it has been greatly extended, in part because (contrary to what you assume) Apple doesn't believe Macs should have to be jailbroken when users want to run something not signed by Apple. See this for more details than you probably require:

https://support.apple.com/guide/security/startup-disk-securi...

So, no jailbreak is required to boot Asahi Linux, or any other unsigned OS. Note that while Apple's documentation refers to booting an unsigned "XNU kernel" (XNU being the macOS kernel), the binary doesn't actually have to be XNU. In Asahi's case, it's a bootloader which loads another bootloader which loads the Linux kernel. (IIRC - I might have that chain a bit wrong.)

Also, if you want to take the time to read through all of that link, you'll find Apple did put a lot of thought into making it possible to bypass while simultaneously keeping it quite robust against malware. Barring truly horrific implementation flaws, it should be impossible to remotely automate the bypass, and the procedure is designed to provide some level of warning to victims of social engineering. And, it's a per-OS preference, so you don't have to reduce the security of your macOS install at all if you just want to play around with Asahi on a different partition.

Even more interesting - the low-security "unsigned" boot path is technically still signed, in a very useful way. Attesting that you'd like to boot an unsigned "XNU kernel" stores the "XNU" binary's cryptographic signature in Apple's Secure Enclave. Every time you boot it, its signature is checked to make sure it hasn't been modified since you authorized it. Which means... if that binary is a loader which does its own cryptographic signature check on the next stage loader, which does its own check on the next stage (or Linux kernel etc), you've built your own secure boot chain on top of Apple's, without having to ask Apple to sign anything. Pretty cool.