Live data from Hacker News

Secure Boot in the Era of the T2

duo.com

41–50 of 97 posts

Re: Secure Boot in the Era of the T2

#41

Earlier quoted context omitted.

Serious question - how well does UEFI secure boot protect against an attacker with a high degree of physical access to the machine? Online docs focus mostly on the software/firmware security but less on the hardware side. Is hardware security specified, or left up to individual vendors?

> how well does UEFI secure boot protect against an attacker with a high degree of physical access to the machine? Everything is relative. When enabled, what Secure Boot ensures is that only boot media signed by a trusted a key (which unless user-replaced, typically are the vendor-provided key which trusts MS Windows and common Linux-distros) can be booted. This guarantees that the base OS and kernel booted by the ma…

> Basically Secure Boot is not a full security solution

Which is what the Apple T2 chip is... which is why it is being lauded as such.

Re: Secure Boot in the Era of the T2

#42
post #32

Earlier quoted context omitted.

> 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…

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

Re: Secure Boot in the Era of the T2

#43

> We believe the T2 platform is a leap forward in platform security in the Apple ecosystem, and it begins to bring exciting security properties like Secure Boot capabilities to the mass market. So the vast PC-market with UEFI secure boot which predates this by 6 year was somehow not the “mass market”, but the relatively tiny MacBook market is? With factual errors like this present already in the introduction, it’s ha…

You are missing the bigger picture in your attempt to immediately discard the original articles premise because you feel like it comes off as fanboy-fluff. No other device on the market currently provides a secondary processor that runs full validation of the UEFI firmware before allowing the processor to start booting. It's not just secure boot, which has been around for a while, it's everything around it. On almost…

> On almost all other devices you could write new data to a flash chip and that now becomes the UEFI boot loader that is used (and can bypass secure boot).

Let me see if I understand you completely.

What you're saying that if an attacker is willing to physically dismantle the machine, he can then, using SPI-flasher HW, replace the UEFI firmware on the machine with a custom UEFI firmware which does not enforce secure-boot...

And thus the machine's security is compromised?

If so, let me just state my opinion: If that's the kind of attacker you are trying to protect against, no matter of security measures is going to keep you fully secure.

And if we're going down that lane: what prevents an attacker this sophisticated from doing the same with the T2-chip's firmware?

What Apple offers with the T2 chip, for most people, has almost zero value, while providing lots of drawbacks over traditional UEFI Secure Boot.

This is all about Apple extending their platform lock-in to no longer only apply to mobile and tablet-space, but also to their traditional computer-line of products.

There's nothing noble being done here. It's just a plain-in-sight money-grab.

Re: Secure Boot in the Era of the T2

#44
post #17

Earlier quoted context omitted.

I've read that the T2 chip also provides the mass storage interface and without documentation or drivers, Linux cannot be run from the internal drive. Devices with the T2 chip can be booted and run from USB connections with the security disabled but not an internal drive.

Yes, that's unfortunate - the lack of drivers means that Linux devs will once again have to reverse someone's proprietary software to develop their own drivers. It's not a fun state of affairs. Unfortunately, Apple is not likely to start fully supporting Linux on Mac hardware by providing drivers and documentation. But the point here is that they haven't done anything technically to prevent you from running Linux.

From what I remember, it acts as a "normal" NVMe device and you can just add its PCI ID and see the disk in Linux…

but in 10 seconds after that it powers the system off because it detects something like an unauthorized OS. Sounds a bit like prevention.

Re: Secure Boot in the Era of the T2

#45

Earlier quoted context omitted.

> how well does UEFI secure boot protect against an attacker with a high degree of physical access to the machine? Everything is relative. When enabled, what Secure Boot ensures is that only boot media signed by a trusted a key (which unless user-replaced, typically are the vendor-provided key which trusts MS Windows and common Linux-distros) can be booted. This guarantees that the base OS and kernel booted by the ma…

> Basically Secure Boot is not a full security solution Which is what the Apple T2 chip is... which is why it is being lauded as such.

It's being presented as something revolutionary and new, while that's clearly not the case.

And it provides Apple with the means to enforce platform-lock in, not only on its mobile line of offerings, but also on their regular laptops and machine, which traditionally has been 100% open computing owner by the end-users.

Which is why it is being widely criticized as unwanted, as a misfeature.

Re: Secure Boot in the Era of the T2

#46
post #32

Earlier quoted context omitted.

> 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…

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..

Re: Secure Boot in the Era of the T2

#47
post #31

Earlier quoted context omitted.

which is great for data privacy. ...and absolutely horrible for freedom. It used to be the case, and still widely accepted for a lot of other products, that physical ownership actually meant something beyond just being a consumer. Now companies are turning the security against users, lest they also be attackers. From the point of view of the DRM-advocating media corporations, the user is an attacker. Locking down the…

> It used to be the case, and still widely accepted for a lot of other products, that physical ownership actually meant something beyond just being a consumer. It still does. The only thing is we've distinguished physical ownership and mere physical possession. It is a feature that if I leave my personal laptop at my desk at work while using the bathroom, my IT department can't rootkit it. It is an improvement to my…

Even if you turn secure boot off you cannot grant for love or any amount of money permission for software of your choosing to access the built in storage which is pretty much required for normal people to be able to run software of their choosing on the machine.

Few people will buy equivalent external ssd storage for 300-500 and carry it around with them to have access to a second OS.

There is absolutely no reason to believe that they will ever act to increase your ownership of your own device and every reason to believe that you will ultimately have about the same privileges as someone using their employers machine at work while being expected to fall full freight.

It's especially bemusing when you understand that evil maid is almost nonexistent in reality while your actual loss of freedom has real effects now.

Re: Secure Boot in the Era of the T2

#48

Earlier quoted context omitted.

You are missing the bigger picture in your attempt to immediately discard the original articles premise because you feel like it comes off as fanboy-fluff. No other device on the market currently provides a secondary processor that runs full validation of the UEFI firmware before allowing the processor to start booting. It's not just secure boot, which has been around for a while, it's everything around it. On almost…

> On almost all other devices you could write new data to a flash chip and that now becomes the UEFI boot loader that is used (and can bypass secure boot). Let me see if I understand you completely. What you're saying that if an attacker is willing to physically dismantle the machine, he can then, using SPI-flasher HW, replace the UEFI firmware on the machine with a custom UEFI firmware which does not enforce secure-…

> What you're saying that if an attacker is willing to physically dismantle the machine, he can then, using SPI-flasher HW, replace the UEFI firmware on the machine with a custom UEFI firmware which does not enforce secure-boot...

Yeah, that's kind of the classic evil maid attack, and it is not unheard of for various spy agencies to dismantle devices to gain access or install bugs.

> If that's the kind of attacker you are trying to protect against

That is exactly what the T2 chip is designed to protect against, and more.

The T2 chip also runs all of the encryption/decryption for the integrated storage, this way all data on the flash is encrypted at all times.

I can imagine that the T2 chip over time will be able to do much more to help provide extra verification and security to the device and help keep users safe.

> And if we're going down that lane: what prevents an attacker this sophisticated from doing the same with the T2-chip's firmware?

Because the firmware on the T2 chip is signed and the way the chip is designed the only way to get firmware on it is to decap it because it is stored internal to the chip itself.

With your stock standard x86 motherboard that is not the case because the firmware is loaded from an unencrypted and unverified flash chip.

> What Apple offers with the T2 chip, for most people, has almost zero value

We'll have to agree to disagree, because the T2 chip also does full line-rate encryption/decryption of the storage with no OS involvement at all. This means if your laptop falls in the wrong hands, now people can't get at the data even by reading directly from the flash chips.

----

You are the one that claimed that the article was fanboy-fluff, I just described a feature that no other machine has... and you immediately consider it a money-grab rather than something to laud Apple for. Yet SecureBoot is good enough? Why not keep improving upon the status quo? Why not make it easier for people to keep their data private and secure?

It's all about defense in depth, and Apple added one more depth to their platform.

Re: Secure Boot in the Era of the T2

#49

Earlier quoted context omitted.

> On almost all other devices you could write new data to a flash chip and that now becomes the UEFI boot loader that is used (and can bypass secure boot). Let me see if I understand you completely. What you're saying that if an attacker is willing to physically dismantle the machine, he can then, using SPI-flasher HW, replace the UEFI firmware on the machine with a custom UEFI firmware which does not enforce secure-…

> What you're saying that if an attacker is willing to physically dismantle the machine, he can then, using SPI-flasher HW, replace the UEFI firmware on the machine with a custom UEFI firmware which does not enforce secure-boot... Yeah, that's kind of the classic evil maid attack, and it is not unheard of for various spy agencies to dismantle devices to gain access or install bugs. > If that's the kind of attacker yo…

> Because the firmware on the T2 chip is signed

So is pretty much all UEFI firmware too though. It may not be encrypted, but it is certainly verified. Feel free to ask the Coreboot people about details here.

> We'll have to agree to disagree, because the T2 chip also does full line-rate encryption/decryption of the storage with no OS involvement at all.

But for people who has been using BitLocker or LUKS transparently (because it's built into the OS) for half a decade+, there are absolutely zero new things offered, and no visible improvements offered.

The only effective change is restrictions in end-user freedom.

> Yet SecureBoot is good enough? Why not keep improving upon the status quo? Why not make it easier for people to keep their data private and secure?

If a security feature which can easily be implemented (securely) in the OS is moved to firmware, I could be willing to consider that a good thing, but not it comes at the cost of end-user freedom.

And here it certainly does.

Re: Secure Boot in the Era of the T2

#50

Earlier quoted context omitted.

Even with secure boot disabled you can't install Linux on the internal SSD. Installing Linux on a Mac has already been very flaky for the last few years, but now is impossible. https://unix.stackexchange.com/questions/463422/how-can-you-...

The likely problem is a lack of driver support for using the T2 as an SSD controller. I don’t think, based on Apple’s white paper, that they did anything to explicitly block Linux from accessing the internal SSD - it just needs to go through the T2 for that. Hopefully someone is working on the necessary driver support - these laptops are still very new so maybe nobody has gotten around to it yet.

Apple is actively blocking unsigned software from accessing the internal storage as a security measure and providing no means to add allowed keys. Its possible there is a defect in this security that could be exploited but it would be explicitly a bug and would be liable to be patched in the next version of the software. You have completely misread the situation. This is apple taking over your machine while still expecting you to pay for it.
Post reply on HN