On 4/29/26 00:40, Theodore Tso wrote:
On Tue, Apr 28, 2026 at 04:50:14PM -0400, Demi Marie Obenour wrote:
This is an example of a BadUSB attack, which has been known since at least 2014. USB sticks *do* have their own microcontrollers to run their firmware. At least in the past this firmware has been programmable and not been digitally signed. This means that the USB stick *can* be reprogrammed to perform a TOCTOU attack on a filesystem, or indeed to implement a completely different kind of USB device.
Honestly, if that's what you are worried about, then best solution is put epoxy in every single USB port. I've since financial institutions that have done precisely this, and both Android and Chrome OS supports enterprise security policies which does the equivalent in software.
That works well in enterprises using laptops, tablets, or mobile devices. Enterprises can require that all devices have built-in, non-USB input devices or touchscreens. Furthermore, corporate environments use network-based backup and file sharing. So there is hardly a need for USB except for security tokens, smart card readers, OS installation media, and miscellaneous hardware devices that generally will not be hotplugged. Only the third is a block device, it is trusted, and it can be a USB stick with a physical write-protect switch and signed firmware.
Protecting against replay attacks requires a Merkle tree. The only Linux filesystems that I know have one are ZFS, bcachefs, and BTRFS. The first two are out of tree and the third is not shipped in RHEL at least.
FYI, there was a patch for btrfs, but it was never landed. It's unclear how many people would be willing to pay the performance tax of using hmac-sha256 for every single data and metadata block write.
I thought BTRFS already had one. In any case corrupting an encrypted disk will cause a checksum failure with fairly high probability, as a 128-bit region is completely scrambled.
Of course, you are free to choose which (if any) of these attacks you care about. One can that USB sticks should be mounted in userspace, UEFI secure boot with Microsoft keys is irrelevant as long as administrator -> kernel isn't a security boundary on Windows, and that confidential computing only makes sense for stateless workloads (which can use dm-verity) until there is a way to trust storage devices. But it's always best to be aware that an attack vector exists, whether or not one chooses to address it.
Sure, but a drive-by comment on a patch review advocating that we slow down ext4 to protect a single instance where the attacker has read/write access to a mounted block device, when the file system doesn't have generalized protections against that whole class of attacks.... isn't particularly helpful.
My main goal is to point out that the attack vector does exist. If nothing else, hopefully this will persuade distro maintainers to switch to using libguestfs + FUSE as the default way to mount USB drives. That isolates the driver in a VM. Qubes OS users can already mount the device in a disposable VM, and presumably many of them already do that. Again, this provides strong isolation and severely limits the impact of an exploit. I do wonder if this could be used against confidential computing workloads. That said, work there would more likely be put into allowing them to attest their storage.
By the way, I'm not aware of *any* company that has been interested in funding work to protect against this class of attacks. Given that most file system developers prefer food with their meals, and have enough *other* unfunded mandates from our user community, it doesn't seem likely that we're going to see much forward progress towards your desires/interests. I'm not surprised at all.
The people who would benefit the most from this work are consumers who are running desktop Linux on general purpose computers they own. I have spent most of my career providing secure solutions for these people. I worked on Qubes OS for several years, and I now work on Spectrum. Unfortunately, this group has very little budget and so very little market power. Therefore, work that benefits them is perpetually and massively underfunded. Grants do exist, and crowdfunding might also be an option. However, unless one is very passionate about the client space, it is hard to resist much better-paying jobs in the server world. -- Sincerely, Demi Marie Obenour (she/her/hers)