linux-kernel - Re: [PATCH 1/1] iommu/vt-d: Add opt-in for ATS support on discrete devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Mar 2023 09:18:00 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     "Tian, Kevin" <kevin.tian@...el.com>
Cc:     Robin Murphy <robin.murphy@....com>,
        Baolu Lu <baolu.lu@...ux.intel.com>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] iommu/vt-d: Add opt-in for ATS support on discrete
 devices

On Fri, Mar 03, 2023 at 08:19:29AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@...dia.com>
> > Sent: Thursday, March 2, 2023 1:43 AM
> > 
> > If Intel BIOS's have populated the "satcu" to say that ATS is not
> > supported by the HW when the HW supports ATS perfectly fine, then get
> > the BIOS fixed or patch the ACPI until it is fixed. The BIOS should
> > not be saying that the HW does not support ATS when it does, it is a
> > simple BIOS bug.
> > 
> 
> That is not the purpose of SATC.
> 
> The ATS support in VT-d side is reported in two interfaces:
> 
> 1) "Device-TLB support" in Extended Capability Register;
> 2) Root port ATS capability in ACPI ATSR structure;
> 
> A device gets ATS enabled if 1/2 are true and !pdev->untrusted. Same
> as SMMU does.
> 
> The main purpose of SATC is to describe which ATS-capable integrated
> device meets the requirements of securely using ATS as stated in VT-d
> spec 4.4. 

Then it should be mapped to pdev->untrusted and possibly
pdev->untrusted to be enhanced to be more descriptive.

iommu driver and BIOS should have no role in security policy beyond
feeding in data to a common policy engine.

Jason