Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

i don't think either of those is really true?

https://asahilinux.org/docs/platform/open-os-interop/



Literally the first step of the boot overview depends on a proprietary and irreplaceable Apple-controlled blob:

  iBoot2 loads the custom kernel, which is a build of m1n1
Apple decides whether or not m1n1 ever loads.


Only if you boot into macOS and connect it to the internet. iBoot2 never changes by itself, you, the user, decides if you want to boot into recovery or macOS and run an update.

So can Apple stop signing new iBoot2 versions? Sure! And that sucks. But it's a bit of FUD to claim that Apple at arbitrary points in time is going to brick your laptop with no option for you to prevent that.

Granted, if you boot both macOS and Asahi, then yes, you are in this predicament, but again, that is a choice. You can never connect macOS or recovery to the internet, or never boot them.


> You can never connect macOS or recovery to the internet, or never boot them

In other words, you're completely fucked if you brick your install. I consider iBoot a direct user-hostile downgrade from UEFI for this reason.

YMMV, but I would never trust my day-to-day on an iBoot machine. UEFI has no such limitations, and Apple is well-known for making controversial choices in OTA updates that users have no alternative to.


> In other words, you're completely fucked if you brick your install. I consider iBoot a direct user-hostile downgrade from UEFI for this reason.

That's a bit of a creative perspective, isn't it? You have no control over the UEFI implementation of your vendor, same can be said for AGESA and ME, as well as any FSP/BSP/BUP packages, BROM signatures or eFused CPUs. And on top of that, you'll have preloaded certificates (usually from Microsoft) that will expire at some point, and when they do and the vendor doesn't replace them, the machine might never boot again (in a UEFI configuration where SecureBoot cannot be disabled as was the case in this Fujitsu - that took a firmware upgrade that the vendor had to supply, which is the exception rather than the rule). For DIY builds this tends to be better, Framework also makes this a tad more reliable.

If anything, most OEM UEFI implementations come with a (x509) timer that when expires, bricks your machine. iBoot2 is just a bunch of files (including the signed boot policy) you can copy and keep around, forever, no lifetimer.

Now, if we wanted to escape all this, your only option is to either get really old hardware, or get non-x86 hardware that isn't Apple M-series or IBM. That means you're pretty much stuck with low-end ARM and lower-end RISC-V, unless you accept AGESA or Intel ME at which point coreboot becomes viable.


Basically your counterpoint is that I'm absolutely right to be concerned, but I'm wrong because UEFI can also be implemented with the same objectionable backdoors that Apple implements.

We're done here, have a nice day.


It's not a counterpoint, it's a display of your factually incorrect statement.


except apple silicon notebooks are notably unbrickable[0]? you can always do https://docs.fedoraproject.org/en-US/fedora-asahi-remix/trou...

[0](through any user-accessible software action, obviously)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: