linux-kernel - RE: [RFC v16 1/9] iommu: Introduce attach/detach_pasid

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] [day] [month] [year] [list]

Message-ID: <BN9PR11MB52765F70759C3905177588768C4A9@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Tue, 4 Jan 2022 02:42:39 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     "peter.maydell@...aro.org" <peter.maydell@...aro.org>,
        "lushenming@...wei.com" <lushenming@...wei.com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        "maz@...nel.org" <maz@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "vsethi@...dia.com" <vsethi@...dia.com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "wangxingang5@...wei.com" <wangxingang5@...wei.com>,
        "vivek.gautam@....com" <vivek.gautam@....com>,
        "zhangfei.gao@...aro.org" <zhangfei.gao@...aro.org>,
        "eric.auger.pro@...il.com" <eric.auger.pro@...il.com>,
        "will@...nel.org" <will@...nel.org>,
        "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>
Subject: RE: [RFC v16 1/9] iommu: Introduce attach/detach_pasid_table API

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Friday, December 17, 2021 4:49 AM
> 
> On Sat, Dec 11, 2021 at 03:57:45AM +0000, Tian, Kevin wrote:
> 
> > This might be the only open as I still didn't see why we need an
> > explicit flag to claim a 'full device' thing. From kernel p.o.v the
> > ARM case is no different from Intel that both allows an user
> > page table attached to vRID, just with different format and
> > addr width (Intel is 64bit, ARM is 84bit where PASID can be
> > considered a sub-handle in the 84bit address space and not
> > the kernel's business).
> 
> I think the difference is intention.
> 
> In one case the kernel is saying 'attach a RID and I intend to use
> PASID' in which case the kernel user can call the PASID APIs.
> 
> The second case is saying 'I will not use PASID'.
> 
> They are different things and I think it is a surprising API if the
> kernel user attaches a domain, intends to use PASID and then finds out
> it can't, eg because an ARM user page table was hooked up.
> 
> If you imagine the flag as 'I intend to use PASID' I think it makes a
> fair amount of sense from an API design too.
> 
> We could probably do without it, at least for VFIO and qemu cases, but
> it seems a little bit peculiar to me.
> 

ok, combining the kernel user makes the flag more sensible.

Thanks
Kevin