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

Date:   Thu, 16 Dec 2021 16:48:31 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     "Tian, Kevin" <kevin.tian@...el.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

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.

Jason