linux-kernel - RE: Plan for /dev/ioasid RFC v2

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:   Wed, 9 Jun 2021 09:37:39 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     "eric.auger@...hat.com" <eric.auger@...hat.com>,
        Jason Gunthorpe <jgg@...dia.com>,
        "Alex Williamson (alex.williamson@...hat.com)" 
        <alex.williamson@...hat.com>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        David Gibson <david@...son.dropbear.id.au>,
        "Jason Wang" <jasowang@...hat.com>,
        "parav@...lanox.com" <parav@...lanox.com>,
        "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Shenming Lu <lushenming@...wei.com>
CC:     Jonathan Corbet <corbet@....net>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>, "Wu, Hao" <hao.wu@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        "Kirti Wankhede" <kwankhede@...dia.com>,
        Robin Murphy <robin.murphy@....com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "David Woodhouse" <dwmw2@...radead.org>,
        Joerg Roedel <joro@...tes.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Lu Baolu <baolu.lu@...ux.intel.com>
Subject: RE: Plan for /dev/ioasid RFC v2

> From: Eric Auger <eric.auger@...hat.com>
> Sent: Wednesday, June 9, 2021 4:15 PM
> 
> Hi Kevin,
> 
> On 6/7/21 4:58 AM, Tian, Kevin wrote:
> > Hi, all,
> >
> > We plan to work on v2 now, given many good comments already received
> > and substantial changes envisioned. This is a very complex topic with
> > many sub-threads being discussed. To ensure that I didn't miss valuable
> > suggestions (and also keep everyone on the same page), here I'd like to
> > provide a list of planned changes in my mind. Please let me know if
> > anything important is lost.  :)
> >
> > --
> >
> > (Remaining opens in v1)
> >
> > -   Protocol between kvm/vfio/ioasid for wbinvd/no-snoop. I'll see how
> >     much can be refined based on discussion progress when v2 is out;
> >
> > -   Device-centric (Jason) vs. group-centric (David) uAPI. David is not fully
> >     convinced yet. Based on discussion v2 will continue to have ioasid uAPI
> >     being device-centric (but it's fine for vfio to be group-centric). A new
> >     section will be added to elaborate this part;
> >
> > -   PASID virtualization (section 4) has not been thoroughly discussed yet.
> >     Jason gave some suggestion on how to categorize intended usages.
> >     I will rephrase this section and hope more discussions can be held for
> >     it in v2;
> >
> > (Adopted suggestions)
> >
> > -   (Jason) Rename /dev/ioasid to /dev/iommu (so does uAPI e.g. IOASID
> >     _XXX to IOMMU_XXX). One suggestion (Jason) was to also rename
> >     RID+PASID to SID+SSID. But given the familiarity of the former, I will
> >     still use RID+PASID in v2 to ease the discussoin;
> >
> > -   (Jason) v1 prevents one device from binding to multiple ioasid_fd's. This
> >     will be fixed in v2;
> >
> > -   (Jean/Jason) No need to track guest I/O page tables on ARM/AMD.
> When
> >     a pasid table is bound, it becomes a container for all guest I/O page
> tables;
> while I am totally in line with that change, I guess we need to revisit
> the invalidate ioctl
> to support PASID table invalidation.

Yes, this is planned when doing this change.

> >
> > -   (Jean/Jason) Accordingly a device label is required so iotlb invalidation
> >     and fault handling can both support per-device operation. Per Jean's
> >     suggestion, this label will come from userspace (when VFIO_BIND_
> >     IOASID_FD);
> 
> what is not totally clear to me is the correspondance between this label
> and the SID/SSID tuple.
> My understanding is it rather maps to the SID because you can attach
> several ioasids to the device.
> So it is not clear to me how you reconstruct the SSID info
> 

Yes, device handle maps to SID. The fault data reported to userspace
will include {device_label, ioasid, vendor_fault_data}. In your case
I believe SSID will be included in vendor_fault_data thus no reconstruct
required. For Intel the user could figure out vPASID according to device_
label and ioasid, i.e. no need to include PASID info in vendor_fault_data.

Thanks
Kevin