linux-kernel - Re: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group

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, 9 Sep 2022 09:07:33 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     "Tian, Kevin" <kevin.tian@...el.com>
Cc:     Nicolin Chen <nicolinc@...dia.com>, Joerg Roedel <joro@...tes.org>,
        "will@...nel.org" <will@...nel.org>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
        "marcan@...can.st" <marcan@...can.st>,
        "sven@...npeter.dev" <sven@...npeter.dev>,
        "alyssa@...enzweig.io" <alyssa@...enzweig.io>,
        "robdclark@...il.com" <robdclark@...il.com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
        "mjrosato@...ux.ibm.com" <mjrosato@...ux.ibm.com>,
        "gerald.schaefer@...ux.ibm.com" <gerald.schaefer@...ux.ibm.com>,
        "orsonzhai@...il.com" <orsonzhai@...il.com>,
        "baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
        "zhang.lyra@...il.com" <zhang.lyra@...il.com>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        "vdumpa@...dia.com" <vdumpa@...dia.com>,
        "jonathanh@...dia.com" <jonathanh@...dia.com>,
        "jean-philippe@...aro.org" <jean-philippe@...aro.org>,
        "cohuck@...hat.com" <cohuck@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "shameerali.kolothum.thodi@...wei.com" 
        <shameerali.kolothum.thodi@...wei.com>,
        "thunder.leizhen@...wei.com" <thunder.leizhen@...wei.com>,
        "christophe.jaillet@...adoo.fr" <christophe.jaillet@...adoo.fr>,
        "yangyingliang@...wei.com" <yangyingliang@...wei.com>,
        "jon@...id-run.com" <jon@...id-run.com>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "asahi@...ts.linux.dev" <asahi@...ts.linux.dev>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible
 domain and device/group

On Fri, Sep 09, 2022 at 05:00:16AM +0000, Tian, Kevin wrote:

> > I have started this effort by combining this list and the one from
> > the side thread:
> > 
> > @@ -266,6 +266,13 @@ struct iommu_ops {
> >  /**
> >   * struct iommu_domain_ops - domain specific operations
> >   * @attach_dev: attach an iommu domain to a device
> > + *              Rules of its return errno:
> > + *               ENOMEM  - Out of memory
> > + *               EINVAL  - Device and domain are incompatible
> > + *               EBUSY   - Device is attached to a domain and cannot be changed
> 
> With this definition then probably @attach_dev should not return -EBUSY
> at all given it's already checked in the start of __iommu_attach_group():

I think the EBUSY would be only for non-conforming drivers. The API
semantic is you can always attach a new domain and replace an existing
domain.

So things like AMD's "can't do anything but idenitity on RID when
PASID enabled" would be -EBUSY.

Seems right that it should be rare though.

> > + *               ENODEV  - Device or domain is messed up: device is not mapped
> > + *                         to an IOMMU, no domain can attach, and etc.
> 
> if domain is messed up then should return -EINVAL given using another domain
> might just work. IMHO here -ENODEV should only cover device specific problems
> preventing this device from being attached to by any domain.

Agree
 
> > + *              <others> - Same behavior as ENODEV, use is discouraged
> 
> didn't get the "Same behavior" part. Does it suggest all other errnos should
> be converted to ENODEV?

It says all other errnos should be treated as ENODEV by the caller but
forwarded to userspace for further detail.

> btw what about -ENOSPC? It's sane to allocate some resource in the attach
> path while the resource might be not available, e.g.:

Seems resaonable that it is similar to ENOMEM

> As discussed in a side thread a note might be added to exempt calling
> kAPI outside of the iommu driver. 

Sadly, not really.. The driver is responsible to santize this if it is
relevant. It is the main downside of this approach.

Jason