3 ms·

> So your argument is that not security, but cost is the reason that USB "won" the external device interface competition with FireWire? Sorry, but I heavily su

> So your argument is that not security, but cost is the reason that USB "won" the external device interface competition with FireWire? Sorry, but I heavily suspect that you didn't read the original article and I suggest you to do so. Security has nothing to do with 1394's market adoption, in the 2010s, some desktops still have 1394, and some laptops still have ExpressCard, and you don't see anyone complains about security, only some security researchers. The reason was partially cost, but also a bad business decision by Steve Jobs, which made Intel and Microsoft stopped their efforts for pushing 1394, largely damaged it before it even got a chance for wider adoption. > FireWire's principal creator, Apple, nearly killed it before it could appear in a single device. And eventually the Cupertino company effectively did kill FireWire, just as it seemed poised to dominate the industry. > Intel sent its CTO to talk to Jobs about the change, but the meeting went badly. Intel decided to withdraw its support for FireWire—to pull the plug on efforts to build FireWire into its chipsets—and instead throw its weight behind USB 2.0. > Sirkin believes that Microsoft could have reversed the new licensing policy by citing the prior signed agreement. "Microsoft must have thrown it away," he speculated, because it would have "stopped Apple in its tracks."* -- > Good to know that USB4 implementations are making the same mistake as FireWire implementors did in choosing performance over security. DMA is optional and can be disabled. Speaking of usability, DMA is limited to the Thunderbolt part (which is ultimately the PCI-E part) of USB 4 standard. You don't have to use USB 4's PCI-E. Unless the USB device really needs PCI-E, like RAID storage box or a GPU, disabling DMA is not a problem. Requiring explicit user consent for PCI-E is also a solution, operating systems already does it for Thunderbolt devices. Same treatment can be applied to USB 4. And again, calling out DMA support is only shooting the messenger while ignoring the underlying problem. DMA is essential for any high-performance system bus, and it can a problem regardless of who supported it, or whether it's connected to an external port. A Wi-Fi controller handles untrusted data, but despite being an internal device on the motherboard, it's still potentially an exploit vector for DMA attackers. > (or an OS with fuzzed IOMMU and also controller firmwares) Only IOMMU is needed (and possibly a good driver, but not strictly required, see QubesOS). If your IOMMU is good, you don't have to trust firmware or hardware, since arbitrary DMAs are blocked by IOMMU, just like how memory protection (MMU) works but for I/O. Memory spaces are isolated. The IOMMU vulnerabilities I previous mentioned are already patched, and a complete bypass of IOMMU is unlikely to occur in the future. Driver bugs are still an issue, more RAM regions can be exposed by drivers than what's really needed, and potentially you can pretend to be any hardware and feed bad data to trick the most vulnerable driver to expose more RAM regions, and I expect to see more bugs. Turn on IOMMU, and apply OS patches often, and you'll probably be fine.

westurner 6y ago
I read much of the article (which assumed that "FireWire" failed because of issues with suppliers failing to work together instead of waning demand (due in part to corporate customers' knowledge of the security risks of most implementations)). Thanks for the info on USB-4, DMA, IOMMU. IOMMU: https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_ma... Looks like there are a number of iommu Linux kernel parameters: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html?highlight=iommu https://www.kernel.org/doc/html/latest/admin-guide/kernel-pa... Wonder what the defaults are and what the comparable parameters are for common consumer OSes. Looks like NX bit support is optional in IOMMUs. Can I configure the amount of RAM allocated to this?
- segfaultbuserr 6y ago
  > Wonder what the defaults See the Thunderclap FAQ, most of your questions are explained. Thunderclap is the DMA attack on Thunderbolt, and everything should be applicable to USB 4 as well, since USB 4 incorporated Thunderbolt directly. https://thunderclap.io/ https://thunderclap.io/ From the FAQ, > In macOS 10.12.4 and later, Apple addressed the specific network card vulnerability we used to achieve a root shell. However the general scope of our work still applies; in particular that Thunderbolt devices have access to all network traffic and sometimes keystrokes and framebuffer data. > Microsoft have enabled support for the IOMMU for Thunderbolt devices in Windows 10 version 1803, which shipped in 2018. Earlier hardware upgraded to 1803 requires a firmware update from the vendor. This brings them into line with the baseline for our work, however the more complex vulnerabilities we describe remain relevant. > Recently, Intel have contributed patches to version 5.0 of the Linux kernel (shortly to be released) that enable the IOMMU for Thunderbolt and prevent the protection-bypass vulnerability that uses the ATS feature of PCI Express. But note that Microsoft says on its website, > This feature does not protect against DMA attacks via 1394/FireWire, PCMCIA, CardBus, ExpressCard, and so on. Basically, IOMMU is enabled by default in most systems now. However, only on Thunderbolt devices (and USB 4 devices, since Thunderbolt is now its subset). But not on other PCI-E ports, such as the internal PCI-E ports, or external ones like 1394 or ExpressCard. I think it's due to fears of performance and compatibility issues, there's no reason why it cannot be implemented if one insists. Also, from the macOS example, you see that bad drivers can be a problem, even with IOMMU, if a driver is bad, attackers can exploit them and trick them to give more RAM access (If my memory is correct, Linux's implementation was better, but since it's an early FAQ, I don't know if macOS has improved). > what the comparable parameters are for common consumer OSes. On the Linux kernel, with an Intel CPU, the kernel option "intel_iommu=on" will enable IOMMU completely for everything, internal and external, which is the most ideal option. You should see DMAR: IOMMU enabled in dmesg. Some people report compatibility issues for Intel's integrated GPU that causes glitches or system hang, use "intel_iommu=on,igfx_off" should fix it (which is not really a security problem, the GPU is already in the CPU). I've been running my PC with IOMMU for years by now. didn't notice any problem for me. IOMMU needs support from the CPU and motherboard chipset, Intel's IOMMU is called VT-D and marketed it as I/O virtualization for virtual machines. Most i3, i5, and i7 CPUs are supported. You may need to turn it on in BIOS if there's an option. It should work on most laptops, even an old Ivy Bridge laptop should work - which is good news, laptops are the most vulnerable platform. Unfortunately, on desktops, Intel intentionally removed IOMMU from high-end CPUs preferred by PC enthusiasts in the 1st (Nehalem), 2nd (Sandy Bridge), 3rd (Ivy Bridge), and 4th (Haswell) generations, possibly as a strategy to sell more Xeon chips to enterprise virtualization users (likely in line with their cripple-ECC strategy). Most high-end overclockable K-series CPUs have their IOMMU removed, while the non-K counterparts are supported. Also, in these generations, some motherboard chipsets are crippled and don't have IOMMU. Fortunately, Intel no longer does it since 5/6th gen (Broadwell/Skylake) CPUs. No experience on AMD yet, but it should be similar. I think possibly better, my impression is that AMD doesn't intentional crippling IOMMU or ECC like Intel does (a nasty strategy...). Check the docs.

westurner 6y ago

I read much of the article (which assumed that "FireWire" failed because of issues with suppliers failing to work together instead of waning demand (due in part to corporate customers' knowledge of the security risks of most implementations)). Thanks for the info on USB-4, DMA, IOMMU. IOMMU: https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_ma... Looks like there are a number of iommu Linux kernel parameters: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html?highlight=iommu https://www.kernel.org/doc/html/latest/admin-guide/kernel-pa... Wonder what the defaults are and what the comparable parameters are for common consumer OSes. Looks like NX bit support is optional in IOMMUs. Can I configure the amount of RAM allocated to this?

segfaultbuserr 6y ago
> Wonder what the defaults See the Thunderclap FAQ, most of your questions are explained. Thunderclap is the DMA attack on Thunderbolt, and everything should be applicable to USB 4 as well, since USB 4 incorporated Thunderbolt directly. https://thunderclap.io/ https://thunderclap.io/ From the FAQ, > In macOS 10.12.4 and later, Apple addressed the specific network card vulnerability we used to achieve a root shell. However the general scope of our work still applies; in particular that Thunderbolt devices have access to all network traffic and sometimes keystrokes and framebuffer data. > Microsoft have enabled support for the IOMMU for Thunderbolt devices in Windows 10 version 1803, which shipped in 2018. Earlier hardware upgraded to 1803 requires a firmware update from the vendor. This brings them into line with the baseline for our work, however the more complex vulnerabilities we describe remain relevant. > Recently, Intel have contributed patches to version 5.0 of the Linux kernel (shortly to be released) that enable the IOMMU for Thunderbolt and prevent the protection-bypass vulnerability that uses the ATS feature of PCI Express. But note that Microsoft says on its website, > This feature does not protect against DMA attacks via 1394/FireWire, PCMCIA, CardBus, ExpressCard, and so on. Basically, IOMMU is enabled by default in most systems now. However, only on Thunderbolt devices (and USB 4 devices, since Thunderbolt is now its subset). But not on other PCI-E ports, such as the internal PCI-E ports, or external ones like 1394 or ExpressCard. I think it's due to fears of performance and compatibility issues, there's no reason why it cannot be implemented if one insists. Also, from the macOS example, you see that bad drivers can be a problem, even with IOMMU, if a driver is bad, attackers can exploit them and trick them to give more RAM access (If my memory is correct, Linux's implementation was better, but since it's an early FAQ, I don't know if macOS has improved). > what the comparable parameters are for common consumer OSes. On the Linux kernel, with an Intel CPU, the kernel option "intel_iommu=on" will enable IOMMU completely for everything, internal and external, which is the most ideal option. You should see DMAR: IOMMU enabled in dmesg. Some people report compatibility issues for Intel's integrated GPU that causes glitches or system hang, use "intel_iommu=on,igfx_off" should fix it (which is not really a security problem, the GPU is already in the CPU). I've been running my PC with IOMMU for years by now. didn't notice any problem for me. IOMMU needs support from the CPU and motherboard chipset, Intel's IOMMU is called VT-D and marketed it as I/O virtualization for virtual machines. Most i3, i5, and i7 CPUs are supported. You may need to turn it on in BIOS if there's an option. It should work on most laptops, even an old Ivy Bridge laptop should work - which is good news, laptops are the most vulnerable platform. Unfortunately, on desktops, Intel intentionally removed IOMMU from high-end CPUs preferred by PC enthusiasts in the 1st (Nehalem), 2nd (Sandy Bridge), 3rd (Ivy Bridge), and 4th (Haswell) generations, possibly as a strategy to sell more Xeon chips to enterprise virtualization users (likely in line with their cripple-ECC strategy). Most high-end overclockable K-series CPUs have their IOMMU removed, while the non-K counterparts are supported. Also, in these generations, some motherboard chipsets are crippled and don't have IOMMU. Fortunately, Intel no longer does it since 5/6th gen (Broadwell/Skylake) CPUs. No experience on AMD yet, but it should be similar. I think possibly better, my impression is that AMD doesn't intentional crippling IOMMU or ECC like Intel does (a nasty strategy...). Check the docs.