[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181112181214.xaahc5wni4vuwl6h@wunner.de>
Date: Mon, 12 Nov 2018 19:12:14 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: iommu@...ts.linux-foundation.org, Joerg Roedel <joro@...tes.org>,
David Woodhouse <dwmw2@...radead.org>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Ashok Raj <ashok.raj@...el.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Jacob jun Pan <jacob.jun.pan@...el.com>,
Andreas Noever <andreas.noever@...il.com>,
Michael Jamet <michael.jamet@...el.com>,
Yehezkel Bernat <YehezkelShB@...il.com>,
Christian Kellner <ckellner@...hat.com>,
Mario.Limonciello@...l.com,
Anthony Wong <anthony.wong@...onical.com>,
linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection
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
Powered by blists - more mailing lists