linux-kernel - RE: [RFC 3/7] iommufd: Add iommufd_device_bind

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB5276A47616E386F00AC50D728CA8A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Wed, 8 Nov 2023 08:46:27 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     "Liu, Yi L" <yi.l.liu@...el.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "jgg@...dia.com" <jgg@...dia.com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>
CC:     "cohuck@...hat.com" <cohuck@...hat.com>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "nicolinc@...dia.com" <nicolinc@...dia.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "mjrosato@...ux.ibm.com" <mjrosato@...ux.ibm.com>,
        "chao.p.peng@...ux.intel.com" <chao.p.peng@...ux.intel.com>,
        "yi.y.sun@...ux.intel.com" <yi.y.sun@...ux.intel.com>,
        "peterx@...hat.com" <peterx@...hat.com>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "shameerali.kolothum.thodi@...wei.com" 
        <shameerali.kolothum.thodi@...wei.com>,
        "lulu@...hat.com" <lulu@...hat.com>,
        "suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "Duan, Zhenzhong" <zhenzhong.duan@...el.com>,
        "Martins, Joao" <joao.m.martins@...cle.com>
Subject: RE: [RFC 3/7] iommufd: Add iommufd_device_bind_pasid()

> From: Liu, Yi L <yi.l.liu@...el.com>
> Sent: Wednesday, November 8, 2023 3:45 PM
> 
> On 2023/10/10 16:19, Tian, Kevin wrote:
> >> From: Liu, Yi L <yi.l.liu@...el.com>
> >> Sent: Monday, October 9, 2023 4:51 PM
> >>
> >> +struct iommufd_device *iommufd_device_bind_pasid(struct
> iommufd_ctx
> >> *ictx,
> >> +						 struct device *dev,
> >> +						 u32 pasid, u32 *id)
> >> +{
> >> +	struct iommufd_device *idev;
> >> +	int rc;
> >> +
> >> +	/*
> >> +	 * iommufd always sets IOMMU_CACHE because we offer no way for
> >> userspace
> >> +	 * to restore cache coherency.
> >> +	 */
> >> +	if (!device_iommu_capable(dev, IOMMU_CAP_CACHE_COHERENCY))
> >> +		return ERR_PTR(-EINVAL);
> >> +
> >> +	/*
> >> +	 * No iommu supports pasid-granular msi message today. Here we
> >> +	 * just check whether the parent device can do safe interrupts.
> >> +	 * Isolation between virtual devices within the parent device
> >> +	 * relies on the parent driver to enforce.
> >> +	 */
> >> +	if (!iommufd_selftest_is_mock_dev(dev) &&
> >> +	    !msi_device_has_isolated_msi(dev)) {
> >> +		rc = iommufd_allow_unsafe_interrupts(dev);
> >> +		if (rc)
> >> +			return ERR_PTR(rc);
> >> +	}
> >> +
> >
> > Only MemWr w/o pasid can be interpreted as an interrupt message
> > then we need msi isolation to protect.
> 
> yes.
> 
> >
> > But for SIOV all MemWr's are tagged with a pasid hence can never
> > trigger an interrupt. From this angle looks this check is unnecessary.
> 
> But the interrupts out from a SIOV virtual device do not have pasid (at
> least today). Seems still need a check here if we consider this bind for
> a SIOV virtual device just like binding a physical device.
> 

this check assumes the device is trusted. as long as there is no way
for malicious guest to generate arbitrary interrupt messages then
it's fine.

for physical device a MemWr can be interpreted as interrupt so
we need msi isolation.

for SIOV all MemWr has pasid then we don't have such worry.
IMS is under host's control so interrupt messages are already
sanitized.