| Message ID | 20181112160628.86620-1-mika.westerberg@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | PCI / iommu / thunderbolt: IOMMU based DMA protection | expand |
On Mon, Nov 12, 2018 at 07:06:24PM +0300, Mika Westerberg wrote: > Recent systems shipping with Windows 10 version 1803 or newer may be > utilizing IOMMU to prevent DMA attacks via Thunderbolt ports. This is > different from the previous security level based scheme because the > connected device cannot access system memory outside of the regions > allocated for it by the driver. > > When enabled the BIOS makes sure no device can do DMA outside of RMRR > (Reserved Memory Region Record) regions. This means that during OS boot, > before it enables IOMMU, none of the connected devices can bypass DMA > protection for instance by overwriting the data structures used by the > IOMMU. The BIOS communicates support for this to the OS by setting a new > bit in ACPI DMAR table [1]. > > Because these systems utilize an IOMMU to block possible DMA attacks, > typically (but not always) the Thunderbolt security level is set to "none" > which means that all PCIe devices are immediately usable. This also means > that Linux needs to follow Windows 10 and enable IOMMU automatically when > running on such system otherwise connected devices can read/write system > memory pretty much without any restrictions. What if the system is booted from a Thunderbolt-attached disk? Won't this suddenly break with these patches? That would seem like a pretty significant regression. What if the only GPU in the system is Thunderbolt-attached? Is it possible to recognize such scenarios and automatically exempt affected devices from IOMMU blocking? Thanks, Lukas
On Mon, Nov 12, 2018 at 8:12 PM Lukas Wunner <lukas@wunner.de> wrote: > > On Mon, Nov 12, 2018 at 07:06:24PM +0300, Mika Westerberg wrote: > > Recent systems shipping with Windows 10 version 1803 or newer may be > > utilizing IOMMU to prevent DMA attacks via Thunderbolt ports. This is > > different from the previous security level based scheme because the > > connected device cannot access system memory outside of the regions > > allocated for it by the driver. > > > > When enabled the BIOS makes sure no device can do DMA outside of RMRR > > (Reserved Memory Region Record) regions. This means that during OS boot, > > before it enables IOMMU, none of the connected devices can bypass DMA > > protection for instance by overwriting the data structures used by the > > IOMMU. The BIOS communicates support for this to the OS by setting a new > > bit in ACPI DMAR table [1]. > > > > Because these systems utilize an IOMMU to block possible DMA attacks, > > typically (but not always) the Thunderbolt security level is set to "none" > > which means that all PCIe devices are immediately usable. This also means > > that Linux needs to follow Windows 10 and enable IOMMU automatically when > > running on such system otherwise connected devices can read/write system > > memory pretty much without any restrictions. > > What if the system is booted from a Thunderbolt-attached disk? > Won't this suddenly break with these patches? That would seem like a > pretty significant regression. My assumption is that either it isn't supported on such platforms (at least with this security configuration active) so this doesn't break anything, it never worked there, or the BIOS configures IOMMU in a way that allows the disk to work until the OS will take control and configure the IOMMU according to OS decisions. In the latter case, the kernel+initrd will be loaded before IOMMU configuration will be changed, and then the kernel should be able to config it correctly to work. (Unless I really don't understand the mechanism and workflow of using IOMMU, which is possible.)
On Mon, Nov 12, 2018 at 07:06:24PM +0300, Mika Westerberg wrote: > Lu Baolu (1): > iommu/vt-d: Force IOMMU on for platform opt in hint > > Mika Westerberg (3): > PCI / ACPI: Identify external PCI devices > iommu/vt-d: Do not enable ATS for external devices > thunderbolt: Export IOMMU based DMA protection support to userspace Looks good to me. Which tree should go this trough? In case its not the IOMMU tree, for the iommu-parts: Acked-by: Joerg Roedel <jroedel@suse.de> Reviewed-by: Joerg Roedel <jroedel@suse.de> Thanks, Joerg
On Mon, Nov 12, 2018 at 07:12:14PM +0100, Lukas Wunner wrote: > On Mon, Nov 12, 2018 at 07:06:24PM +0300, Mika Westerberg wrote: > > Recent systems shipping with Windows 10 version 1803 or newer may be > > utilizing IOMMU to prevent DMA attacks via Thunderbolt ports. This is > > different from the previous security level based scheme because the > > connected device cannot access system memory outside of the regions > > allocated for it by the driver. > > > > When enabled the BIOS makes sure no device can do DMA outside of RMRR > > (Reserved Memory Region Record) regions. This means that during OS boot, > > before it enables IOMMU, none of the connected devices can bypass DMA > > protection for instance by overwriting the data structures used by the > > IOMMU. The BIOS communicates support for this to the OS by setting a new > > bit in ACPI DMAR table [1]. > > > > Because these systems utilize an IOMMU to block possible DMA attacks, > > typically (but not always) the Thunderbolt security level is set to "none" > > which means that all PCIe devices are immediately usable. This also means > > that Linux needs to follow Windows 10 and enable IOMMU automatically when > > running on such system otherwise connected devices can read/write system > > memory pretty much without any restrictions. > > What if the system is booted from a Thunderbolt-attached disk? > Won't this suddenly break with these patches? Like Yehezkel commented, it either is not supported or alternatively it is (the BIOS/boot loader utilizes IOMMU as well), loads the OS image and what is needed from the disk, disables BME (bus mastering enable) and resets the IOMMU back to the default state before handing over to the OS. > That would seem like a pretty significant regression. What if the > only GPU in the system is Thunderbolt-attached? Is it possible to > recognize such scenarios and automatically exempt affected devices > from IOMMU blocking? "IOMMU blocking" does not mean that the device cannot be used at all. It actually means that the device is immediately usable and can do DMA as the driver has programmed (using DMA-API) but it cannot access any memory outside of those regions the driver has programmed. The point of this exercise is to prevent so called drive-by DMA attacks where you go to take a cup of coffee and during that time someone plugs in a malicous device to Thunderbolt port of your laptop and reads all your secrets. When IOMMU is enabled the malicous device still is usable (assuming there is driver for it) but it cannot go and read all the memory, just the memory driver has programmed. So in your GPU case it should just work assuming the GPU has a driver.
On Tue, Nov 13, 2018 at 09:54:24AM +0100, Joerg Roedel wrote: > On Mon, Nov 12, 2018 at 07:06:24PM +0300, Mika Westerberg wrote: > > Lu Baolu (1): > > iommu/vt-d: Force IOMMU on for platform opt in hint > > > > Mika Westerberg (3): > > PCI / ACPI: Identify external PCI devices > > iommu/vt-d: Do not enable ATS for external devices > > thunderbolt: Export IOMMU based DMA protection support to userspace > > Looks good to me. Which tree should go this trough? In case its not the > IOMMU tree, for the iommu-parts: I was thinking to take them through Thunderbolt tree. > Acked-by: Joerg Roedel <jroedel@suse.de> > Reviewed-by: Joerg Roedel <jroedel@suse.de> Thanks!