Re: [PATCH 6/7] x86/boot/tboot: Move tboot_force_iommu() to Intel IOMMU

[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