What does that have to do with anything? Linux doesn’t run on HFS+ or APFS.
FileVault/Encryption also encrypts the EFI partition when full disk encryption is set. What’s unclear is the behavior after you turn off all the protection with the T2 chip. With previous chips, the EFI partition is unlocked cause the disk is fully decrypted.
I don’t see why that would matter, since you can install linux on a mac without disabling filevault.
Okay, seems the issue is Linux literally can’t see the controller that handles the internal SSD. It’s no longer using a standard NVMe according to teardowns, so yes, the internal SSD actually has the T2 as it’s controller, directly communicating with the NAND that’s soldered onto the mainboard. (So no, you cannot upgrade your SSD anymore)
1 Like
Yep, that was my guess earlier. Linux needs to support that T2 controller. Question is whether Apple plays ball or they need to reverse-engineer it, in which case it could be awhile.
Same deal with the iMac Pro. With T1 and T2, it’s not NVMe, it’s bare NAND and a proprietary controller. Though arguably it was a proprietary SSD in modified NVMe form factor in 2015, but at least Linux can see that Samsung controller, even though it was “proprietary.”
The 2017 MBP works and Linux can see the internal SSD, but T2 is invisible to Linux.
You mean industry standard AES?
Do you remember when the PowerMac G5 was released, they said it would take a supercomputer 149 trillion years to defeat AES? That was how the world was introduced to FileVault.
And found the archive [dot] org page:
https://web.archive.org/web/20031202024908/http://www.apple.com/macosx/features/filevault/
What’s your point?
Mine was that it isn’t “proprietary encryption” - it is industry standard AES. Same stuff used in millions of IPSEC connections the world over, other on disk encryption setups, etc.
There was a compatibility issue with the encryption when High Sierra got introduced, but then I quickly realized that can happen with any form of encryption, as implementation can cause these problems, not the actual crypto itself.
So yeah, I wasn’t gonna explain myself and look dumb. I originally had the point that Apple’s encryption was the root of the problem, but it’s not the crypto, it’s the implementation.
Now that we know Linux can’t even see the T2 controller, that rules out filesystem/full disk encryption cause people have been able to install other OSes on T1 just fine.
The wrong information is still being spread.
The point is that Apple won’t sign it, not that open-source devs are unwilling to sign it.
The defaults are (according to Apple) to literally ignore the traditional UEFI signing CA (Microsoft Corporation UEFI CA 2011), and only accept the Windows CA (Microsoft Windows Production CA 2011) and Apple’s own CA. (see page 9)
You can only disable Secure Boot entirely to boot Linux. (see page 10)
1 Like
That might be his point. The few distos that do sign their stuff piggy back on the windows certificate. A Linux certificate doesn’t exist so there’s no one talking to apple to make it happen.
1 Like
Even if there was who would own it and decide what gets signed?
1 Like
God emperor Stallmann /s
Red hat most likely considering they get their stuff signed by Microsoft at the moment for PCs.
2 Likes
The distro vendor should have their own cert that they use to sign their own code. They then petition to get that added to machines and/or provide instructions for PC users to do it (i.e., add the distro vendor’s cert to the UEFI) to PCs.
Whether or not apple sign it is another thing entirely, as @Eden said, my point is that 99% of the linux community are all “secure boot! bad! evil!” rather than actually doing something to make use of the technology which has legitimate real-world benefits. Outside of implementation fuck ups, if you have a reliable code-signing architecture you can prevent malicious code from third parties from ever running on your machine. For the average end user, this is great, once they know how it works.
Apple’s business is providing a secure platform where code-signing can be enforced. Long term, you aren’t going to get Apple to give users the option to turn off the equivalent of secure boot. So you either get on board and sign your code and get the relevant certificates added to the UEFI, or miss out.
I’m still trying to figure out how all this works, but it sounds like Linux shims actually use a separate “root” than Windows. According to this Microsoft TechNet blog post, both of these are roots that can be entries in the SecureBoot db database, and it suggests that both are commonly in mainboard firmware:
-
Microsoft Corporation UEFI CA 2011- 3rd party signing -
Microsoft Windows Production PCA 2011- Windows signing
Confusingly, Apple’s document says they include:
Microsoft Windows Production CA 2011
not
Microsoft Windows Production PCA 2011
Is this just a typo, or actually a different cert?
Anyway, it’s clear that the Microsoft 3rd party cert is not being included on Apple hardware. If you want an open OS, you’ll probably need to disable SecureBoot, since I don’t see Apple as willing to let you set your own PK key.
@thro Apple already lets you disable SecureBoot (see my previous post, page 10 in the T2 document; or Apple Support HT208330).
Apple are interested in selling hardware, not getting people to run their OS. I don’t think it’s some underhanded lock-in scheme. If they screwed something up that makes it hard to boot another OS, they’ll probably fix it.
On the other hand, Linux needs to come up with their own drivers for new hardware constantly, this isn’t a new way of tormenting Linux users that was dreamed up by Apple’s evil legion of sadistic product developers. There’s just no software support yet in Linux, and it’s questionable if anyone even cares enough to write the Linux drivers any time soon.
I myself have tinkered around with creating drivers for freebsd to get the keyboard working on my mac. But I only felt like it for a day or two before I stopped caring. I’d rather run macOS than Linux or Windows. There just isn’t a big incentive to work on Linux support.
Apple don’t even charge for macOS (upgrades are free, at least), but IMO that is one of the most valuable things you are paying for when you get a mac. I think it is a little silly to pay the Apple premium and not use their OS. That said, they have supported your choice to do so for a long time, short of writing drivers for every obscure OS themselves.
Some more info on T2