Hacker News Reader

Comment by josteink | Hacker News Reader

> Does this have any bearing on running linux on macbooks

Unlike on PCs, on T2 Macs Linux will only be bootable with Secure boot disabled making the system much less secure.

To make matters worse, the T2 chip administers access to the built in SSD, so it will be completely inaccessible for Linux to use for anything.

When Apple stops supporting this machine, you won’t be able to keep it chugging by loading another OS.

I could say Apple is trying to terminate the only remaining computing platform which respects end-user freedom and ownership, but I’m not sure if it would be a joke or not...

View on HN

> the T2 chip administers access to the built in SSD, so it will be completely inaccessible for Linux to use for anything.

This isn’t true. You can install Linux on this, providing you disable Secure Boot. You can’t currently access the SSD, but that’s more the result of a driver not existing than it being inherently disallowed.

> You can’t currently access the SSD, but that’s more the result of a driver not existing than it being inherently disallowed.

That's not clear yet. There is a NVMe driver available in Linux which works fine with pre-T2 Macs. On T2 Macs however the whole platform resets a few seconds after initializing the NVMe controller. The question is: Is that a bug in the driver or NVMe implementation of the T2 chip or something Apple does intentionally?

Let's not attribute to malice what can easily be attributed to incompetence.

In a chip that has "secure" in its name, it's quite likely that a sudden system shutdown is intentional..

I can envision a scenario where T2, when booted with Secure Boot disabled, tries to protect a Secure Boot OS and user data stored on the internal mass storage device in the event of the user subsequently re-enabling Secure Boot thus adding a layer of guarantee that everything is safe even during the time window when Secure Boot was disabled.

If intentional, this behaviour is nonetheless not documented in the whitepaper.

In such a scenario, a possible solution could be to offer an option to force an internal disk erasure upon toggling secure boot, in which case the internal device would be cleared for non-secure OS access.

That's interesting; I was not aware of the exact circumstances around why this driver didn't exist. Do you know where I could look to find more detail on the state of development for this?

Reply on news.ycombinator.com