Enabled by the T2 chipset, new generations of the Macbook Pro and the iMac Pro aim to mitigate many software and hardware-based attacks against the very first pieces of code executed during the initial boot process. By ditching the flash memory chip containing Unified Extensible Firmware Interface (UEFI) firmware and using chipset functionality typically reserved for server architectures, the T2 is able to dynamically provide and validate UEFI payload contents at runtime.
We have spent considerable time looking at the T2 and have written a paper that outlines the technical details of what actually happens when the power button is pressed. The T2 is a great first step in the right direction, but there is still room for improvement when it comes to the secure boot process on an Apple T2-enabled device.
Security at the expense of user ownership and repairability. Pick your poison.
The biggest problem in computer security is user implementation. As long as products are not designed with that in mind, the best lock-out chip in the world isn’t going to keep out the bad guys.
Apart from that, I’m not convinced that there are no possible alternatives to boot security that don’t harm product ownership.
Edited 2018-11-22 02:21 UTC
emphyrio,
I think I agree with you, but with all those negatives in one sentence it’s hard to tell
Between microsoft, apple, and google, I am concerned with where restrictions are headed. Little by little, they’re becoming the tech police telling us what we can and cannot do on our machines.
Edited 2018-11-22 04:14 UTC
At least Google tries to allow people to install plain Linux on their Chromebooks, although you won’t have the extra security anymore.
What about Windows?
I say the best alternative to “locked closed” secure boot is “locked open”. In other words, refuse to install/run system software that cannot be verified as matching a commit in a public repository.
This is the model I am going to use in UX/RT ( https://gitlab.com/uxrt/ ), the OS I’m writing. All packages in the base system will be built, verified, and signed against their repositories by multiple servers, and the package manager will refuse to overwrite any verified package with an unverified one (it will be possible to turn this off, but it will require editing a config file, and it will also be possible to require verification on all packages). Relatively little in my verification layer will be UX/RT-specific, and it will be portable to most other Unix-like OSes. The main limitation is that it will require reproducible builds for all packages to be verified, but that won’t be a problem for UX/RT since all packages in the base system will be required to support them.
Having every build verified by multiple servers controlled by multiple independent organizations as traceable to a particular commit will provide far superior security to having to trust a particular single vendor’s word that a particular build hasn’t been compromised.
https://www.t2tea.com/en/au/Home
I like Pu-erh and Jasmine, and every now and then a bit of Earl Grey and Gunpowder Green.
Lapsang Souchong or a nice cup of builders tea but mostly decaf peppermint – gallons of it.
“Builders Tea” is what we, in the UK, refer to as a strong, dark red tea. The sort of thing builders/road workers etc brew up to keep them on the job.
Black, no sugar plz!
Simple Tomahawk missile facing crapple building will take care of it 100% xD
I partake in grain coffee Inka
(which was devised half a century ago in People’s Republic of Poland probably as a way to deal with shortages of “real” coffee …but I acquired a taste for it while in a hospital dozen+ years ago, where they served it for breakfast)
… from the developers that released an OS in which you could gain root access by typing “root” with no password…
… and then released a patch which re-enabled the bug.
… from the company that released a password hint system for encrypted drives that could show you the plaintext password instead.
Apple has a long history of glaring security holes. They once relied on an environment variable to determine whether you should have elevated privileges.
Why secure the bootloader if you’re distributing an insecure OS?
Freedom comes with a price tag…. I don’t want to belong in a walled garden, ever.
Not talking about the real issues.
Refreshing.
Thanks, Thom