Messages in this thread | | | Date | Wed, 18 May 2022 15:38:08 +0800 | Subject | Re: [PATCH 6/7] x86/boot/tboot: Move tboot_force_iommu() to Intel IOMMU | From | Baolu Lu <> |
| |
On 2022/5/17 19:13, Jason Gunthorpe wrote: > On Tue, May 17, 2022 at 10:05:43AM +0800, Baolu Lu wrote: >> Hi Jason, >> >> On 2022/5/17 02:06, Jason Gunthorpe wrote: >>>> +static __init int tboot_force_iommu(void) >>>> +{ >>>> + if (!tboot_enabled()) >>>> + return 0; >>>> + >>>> + if (no_iommu || dmar_disabled) >>>> + pr_warn("Forcing Intel-IOMMU to enabled\n"); >>> Unrelated, but when we are in the special secure IOMMU modes, do we >>> force ATS off? Specifically does the IOMMU reject TLPs that are marked >>> as translated? >> >> Good question. From IOMMU point of view, I don't see a point to force >> ATS off, but trust boot involves lots of other things that I am not >> familiar with. Anybody else could help to answer? > > ATS is inherently not secure, if a rouge device can issue a TLP with > the translated bit set then it has unlimited access to host memory.
Agreed. The current logic is that the platform lets the OS know such devices through firmware (ACPI/DT) and OS sets the untrusted flag in their device structures. The IOMMU subsystem will disable ATS on devices with the untrusted flag set.
There is some discussion about allowing the supervisor users to set the trust policy through the sysfs ABI, but I don't think this has happened in upstream kernel.
> Many of these trusted iommu scenarios rely on the idea that a rouge > device cannot DMA to arbitary system memory.
I am not sure whether tboot has the same requirement.
Best regards, baolu
| |