linux-kernel - RE: [RFC 12/20] iommu/iommufd: Add IOMMU_CHECK

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]

Message-ID: <BN9PR11MB54334A552C3E606F4394EF298CA29@BN9PR11MB5433.namprd11.prod.outlook.com>
Date:   Wed, 22 Sep 2021 03:41:50 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>, "Liu, Yi L" <yi.l.liu@...el.com>
CC:     "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "hch@....de" <hch@....de>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "jean-philippe@...aro.org" <jean-philippe@...aro.org>,
        "parav@...lanox.com" <parav@...lanox.com>,
        "lkml@...ux.net" <lkml@...ux.net>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "lushenming@...wei.com" <lushenming@...wei.com>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "corbet@....net" <corbet@....net>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "yi.l.liu@...ux.intel.com" <yi.l.liu@...ux.intel.com>,
        "Tian, Jun J" <jun.j.tian@...el.com>, "Wu, Hao" <hao.wu@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "jacob.jun.pan@...ux.intel.com" <jacob.jun.pan@...ux.intel.com>,
        "kwankhede@...dia.com" <kwankhede@...dia.com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
        "david@...son.dropbear.id.au" <david@...son.dropbear.id.au>,
        "nicolinc@...dia.com" <nicolinc@...dia.com>
Subject: RE: [RFC 12/20] iommu/iommufd: Add IOMMU_CHECK_EXTENSION

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Wednesday, September 22, 2021 1:47 AM
> 
> On Sun, Sep 19, 2021 at 02:38:40PM +0800, Liu Yi L wrote:
> > As aforementioned, userspace should check extension for what formats
> > can be specified when allocating an IOASID. This patch adds such
> > interface for userspace. In this RFC, iommufd reports EXT_MAP_TYPE1V2
> > support and no no-snoop support yet.
> >
> > Signed-off-by: Liu Yi L <yi.l.liu@...el.com>
> >  drivers/iommu/iommufd/iommufd.c |  7 +++++++
> >  include/uapi/linux/iommu.h      | 27 +++++++++++++++++++++++++++
> >  2 files changed, 34 insertions(+)
> >
> > diff --git a/drivers/iommu/iommufd/iommufd.c
> b/drivers/iommu/iommufd/iommufd.c
> > index 4839f128b24a..e45d76359e34 100644
> > +++ b/drivers/iommu/iommufd/iommufd.c
> > @@ -306,6 +306,13 @@ static long iommufd_fops_unl_ioctl(struct file
> *filep,
> >  		return ret;
> >
> >  	switch (cmd) {
> > +	case IOMMU_CHECK_EXTENSION:
> > +		switch (arg) {
> > +		case EXT_MAP_TYPE1V2:
> > +			return 1;
> > +		default:
> > +			return 0;
> > +		}
> >  	case IOMMU_DEVICE_GET_INFO:
> >  		ret = iommufd_get_device_info(ictx, arg);
> >  		break;
> > diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
> > index 5cbd300eb0ee..49731be71213 100644
> > +++ b/include/uapi/linux/iommu.h
> > @@ -14,6 +14,33 @@
> >  #define IOMMU_TYPE	(';')
> >  #define IOMMU_BASE	100
> >
> > +/*
> > + * IOMMU_CHECK_EXTENSION - _IO(IOMMU_TYPE, IOMMU_BASE + 0)
> > + *
> > + * Check whether an uAPI extension is supported.
> > + *
> > + * It's unlikely that all planned capabilities in IOMMU fd will be ready
> > + * in one breath. User should check which uAPI extension is supported
> > + * according to its intended usage.
> > + *
> > + * A rough list of possible extensions may include:
> > + *
> > + *	- EXT_MAP_TYPE1V2 for vfio type1v2 map semantics;
> > + *	- EXT_DMA_NO_SNOOP for no-snoop DMA support;
> > + *	- EXT_MAP_NEWTYPE for an enhanced map semantics;
> > + *	- EXT_MULTIDEV_GROUP for 1:N iommu group;
> > + *	- EXT_IOASID_NESTING for what the name stands;
> > + *	- EXT_USER_PAGE_TABLE for user managed page table;
> > + *	- EXT_USER_PASID_TABLE for user managed PASID table;
> > + *	- EXT_DIRTY_TRACKING for tracking pages dirtied by DMA;
> > + *	- ...
> > + *
> > + * Return: 0 if not supported, 1 if supported.
> > + */
> > +#define EXT_MAP_TYPE1V2		1
> > +#define EXT_DMA_NO_SNOOP	2
> > +#define IOMMU_CHECK_EXTENSION	_IO(IOMMU_TYPE,
> IOMMU_BASE + 0)
> 
> I generally advocate for a 'try and fail' approach to discovering
> compatibility.
> 
> If that doesn't work for the userspace then a query to return a
> generic capability flag is the next best idea. Each flag should
> clearly define what 'try and fail' it is talking about

We don't have strong preference here. Just follow what vfio does
today. So Alex's opinion is appreciated here. 😊

> 
> Eg dma_no_snoop is about creating an IOS with flag NO SNOOP set
> 
> TYPE1V2 seems like nonsense

just in case other mapping protocols are introduced in the future

> 
> Not sure about the others.
> 
> IOW, this should recast to a generic 'query capabilities' IOCTL
> 
> Jason