On 2022-03-21 10:58, mika.westerberg@xxxxxxxxxxxxxxx wrote:
Hi Mario,
On Fri, Mar 18, 2022 at 10:29:59PM +0000, Limonciello, Mario wrote:
[Public]
Between me trying to get rid of iommu_present() and Mario wanting to
support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has
shown
that the iommu_dma_protection attribute is being far too optimistic.
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device(s)
we care about. Furthermore, all that DMAR_PLATFORM_OPT_IN really does
is tell us that memory was protected before the kernel was loaded, and
prevent the user from disabling the intel-iommu driver entirely. While
that lets us assume kernel integrity, what matters for actual runtime
DMA protection is whether we trust individual devices, based on the
"external facing" property that we expect firmware to describe for
Thunderbolt ports.
It's proven challenging to determine the appropriate ports accurately
given the variety of possible topologies, so while still not getting a
perfect answer, by putting enough faith in firmware we can at least get
a good bit closer. If we can see that any device near a Thunderbolt NHI
has all the requisites for Kernel DMA Protection, chances are that it
*is* a relevant port, but moreover that implies that firmware is playing
the game overall, so we'll use that to assume that all Thunderbolt ports
should be correctly marked and thus will end up fully protected.
This approach looks generally good to me. I do worry a little bit about older
systems that didn't set ExternalFacingPort in the FW but were previously setting
iommu_dma_protection, but I think that those could be treated on a quirk
basis to set PCI IDs for those root ports as external facing if/when they come
up.
There are no such systems out there AFAICT.
And even if there are, as above they've never actually been fully
protected and still won't be, so it's arguably a good thing for them to
stop thinking so.
I'll send up a follow up patch that adds the AMD ACPI table check.
If it looks good can roll it into your series for v3, or if this series goes
as is for v2 it can come on its own.
CC: Mario Limonciello <mario.limonciello@xxxxxxx>
Signed-off-by: Robin Murphy <robin.murphy@xxxxxxx>
---
v2: Give up trying to look for specific devices, just look for evidence
that firmware cares at all.
I still do think you could know exactly which devices to use if you're in
SW CM mode, but I guess the consensus is to not bifurcate the way this
can be checked.
Indeed.
The patch looks good to me now. I will give it a try on a couple of
systems later today or tomorrow and let you guys know how it went. I
don't expect any problems but let's see.
Thanks a lot Robin for working on this :)
Heh, let's just hope the other half-dozen or so subsystems I need to
touch for this IOMMU cleanup aren't all quite as involved as this turned
out to be :)
Cheers,
Robin.
