For some reason wifi vendors typically ship devices without any radio firmware at all, but leave it up to the driver to load it. Rendering the device 100% useless without loading some external proprietary blob.

Hard drives don't have that problem.

Hard drives definitely have proprietary blobs on them. You just have even less visibility on them.

A key difference is that a hard drive can't secretly send information out. I'm fine with an isolated component the rest of the architecture can treat as a black box (even sending only encrypted data to it). But the wifi chip can easily build its own IP packets and leak a bunch of information to the internet or it can have an easily exploitable backdoor.

a hard drive is a huge source of attack vector. In particular if you're running full disk encryption with a very tiny unencrypted ext2 boot/grub2 partition, malicious firmware on a disk can intercept the plaintext keystrokes for a passphrase-unlock on FDE. This is a known intelligence agency attack vector.

https://theintercept.com/2015/04/27/encrypting-laptop-like-m...

see the "attacks against disk encryption" section.

I wouldnt describe that as a huge source considering it requires a tpm vulnerability in secure-signed envs.

This specific platform has all of the tpm module feature set disabled, no? Since the code running inside the tpm is proprietary and closed. To the best of my knowledge super gpl zealot users rarely choose to store a key in the tpm for full disk encryption unlocking purposes.

Does the SSD have network access?

It can if it wants to.

Care to elaborate?

The SSD runs its own proprietary firmware that controls the raw disk device itself. If it wants to insert a blob of code into your bootloader or grub2 that can do keystroke interception on a full-disk-encryption unlock, it can. This is the same idea as a technique used by intelligence agencies with a typical "evil maid" attack.

Ah yes, if you execute unsigned code from it then that's definitely possible.

Signing the code doesn't help. Where are you reading the signature-verification code from?

Presumably you use TPM and the various trusted boot technologies.

I think you’ll still have the problem with this thing being on a pci-e bus though.

Yes, I was more curious if a malicious actor (the hard drive) with access to the nvme bus could manage to exfiltrate data directly via the network interfaces without involving the OS.

I suggest you look into TPM and the full signed-code architectures it enables.