4 ms·

I would argue that the complexity of TPMs[1] and UEFI[2] leads to a larger attack surface with more bugs present, making it easier to launch attacks such as the

by dhx 4y ago

I would argue that the complexity of TPMs[1] and UEFI[2] leads to a larger attack surface with more bugs present, making it easier to launch attacks such as the one described. The opaqueness of these technologies and inability for and difficulty of security researchers to investigate and debug implementations of these technologies does not help either. There is no chance of a typical system owner having the time and skill to understand TPM and UEFI technologies in enough detail to know whether their systems are vulnerable or compromised. [1] Example: 176 pages at https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p_r14_pub.pdf https://trustedcomputinggroup.org/wp-content/uploads/PC-Clie... [2] Example: 2540 pages at https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9...

fguerraz 4y ago
> There is no chance of a typical system owner having the time and skill... Hence the suggestion to make it tamper obvious. As for the attack surface, it is true, but it's a separate problem. You don't have to bloat your firmware to make it trusted.
Avamander 4y ago
In theory yes, more functionality means more surface, but then some aspects are fundamentally designed to be less exposed or dangerous. We will keep on finding a bunch of bugs in those implementations, but I suspect the end result is better than what we could've ever had with BIOS. I don't think there was any chance for a typical system owner to have the time or skill or even the foundation required to understand if their machine's BIOS is vulnerable or compromised. UEFI provides some basis to actually start with that process. I also think there is a real opportunity to write open-source versions of these components in safe/verifiable languages. That way we could have our cake and eat it too.
- lmm 4y ago
  > I suspect the end result is better than what we could've ever had with BIOS. I would take that bet, if there were any way to objectively assess. The surface area of BIOS is just so much smaller. > I also think there is a real opportunity to write open-source versions of these components in safe/verifiable languages. In theory yes. In practice they're always going to be giant blobs of C written by hardware makers, massaged just enough to get Windows to boot.

by dhx 4y ago

fguerraz 4y ago

> There is no chance of a typical system owner having the time and skill... Hence the suggestion to make it tamper obvious. As for the attack surface, it is true, but it's a separate problem. You don't have to bloat your firmware to make it trusted.

Avamander 4y ago

In theory yes, more functionality means more surface, but then some aspects are fundamentally designed to be less exposed or dangerous. We will keep on finding a bunch of bugs in those implementations, but I suspect the end result is better than what we could've ever had with BIOS. I don't think there was any chance for a typical system owner to have the time or skill or even the foundation required to understand if their machine's BIOS is vulnerable or compromised. UEFI provides some basis to actually start with that process. I also think there is a real opportunity to write open-source versions of these components in safe/verifiable languages. That way we could have our cake and eat it too.

lmm 4y ago
> I suspect the end result is better than what we could've ever had with BIOS. I would take that bet, if there were any way to objectively assess. The surface area of BIOS is just so much smaller. > I also think there is a real opportunity to write open-source versions of these components in safe/verifiable languages. In theory yes. In practice they're always going to be giant blobs of C written by hardware makers, massaged just enough to get Windows to boot.