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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Aug 2021 09:00:46 +0000 From: "Tian, Kevin" <kevin.tian@...el.com> To: "eric.auger@...hat.com" <eric.auger@...hat.com>, Jason Gunthorpe <jgg@...dia.com>, "Alex Williamson (alex.williamson@...hat.com)" <alex.williamson@...hat.com>, Jean-Philippe Brucker <jean-philippe@...aro.org>, David Gibson <david@...son.dropbear.id.au>, "Jason Wang" <jasowang@...hat.com>, "parav@...lanox.com" <parav@...lanox.com>, "Enrico Weigelt, metux IT consult" <lkml@...ux.net>, Paolo Bonzini <pbonzini@...hat.com>, Shenming Lu <lushenming@...wei.com>, Joerg Roedel <joro@...tes.org> CC: Jonathan Corbet <corbet@....net>, "Raj, Ashok" <ashok.raj@...el.com>, "Liu, Yi L" <yi.l.liu@...el.com>, "Wu, Hao" <hao.wu@...el.com>, "Jiang, Dave" <dave.jiang@...el.com>, Jacob Pan <jacob.jun.pan@...ux.intel.com>, "Kirti Wankhede" <kwankhede@...dia.com>, Robin Murphy <robin.murphy@....com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>, "David Woodhouse" <dwmw2@...radead.org>, LKML <linux-kernel@...r.kernel.org>, "Lu Baolu" <baolu.lu@...ux.intel.com> Subject: RE: [RFC v2] /dev/iommu uAPI proposal > From: Eric Auger <eric.auger@...hat.com> > Sent: Tuesday, August 10, 2021 3:17 PM > > Hi Kevin, > > On 8/5/21 2:36 AM, Tian, Kevin wrote: > >> From: Eric Auger <eric.auger@...hat.com> > >> Sent: Wednesday, August 4, 2021 11:59 PM > >> > > [...] > >>> 1.2. Attach Device to I/O address space > >>> +++++++++++++++++++++++++++++++++++++++ > >>> > >>> Device attach/bind is initiated through passthrough framework uAPI. > >>> > >>> Device attaching is allowed only after a device is successfully bound to > >>> the IOMMU fd. User should provide a device cookie when binding the > >>> device through VFIO uAPI. This cookie is used when the user queries > >>> device capability/format, issues per-device iotlb invalidation and > >>> receives per-device I/O page fault data via IOMMU fd. > >>> > >>> Successful binding puts the device into a security context which isolates > >>> its DMA from the rest system. VFIO should not allow user to access the > >> s/from the rest system/from the rest of the system > >>> device before binding is completed. Similarly, VFIO should prevent the > >>> user from unbinding the device before user access is withdrawn. > >> With Intel scalable IOV, I understand you could assign an RID/PASID to > >> one VM and another one to another VM (which is not the case for ARM). > Is > >> it a targetted use case?How would it be handled? Is it related to the > >> sub-groups evoked hereafter? > > Not related to sub-group. Each mdev is bound to the IOMMU fd > respectively > > with the defPASID which represents the mdev. > But how does it work in term of security. The device (RID) is bound to > an IOMMU fd. But then each SID/PASID may be working for a different VM. > How do you detect this is safe as each SID can work safely for a > different VM versus the ARM case where it is not possible. PASID is managed by the parent driver, which knows which PASID to be used given a mdev when later attaching it to an IOASID. > > 1.3 says > " > > 1) A successful binding call for the first device in the group creates > the security context for the entire group, by: > " > What does it mean for above scalable IOV use case? > This is a good question (as Alex raised) which needs more explanation in next version: https://lore.kernel.org/linux-iommu/20210712124150.2bf421d1.alex.williamson@redhat.com/ In general we need provide different helpers for binding pdev/mdev/ sw mdev. 1.3 in v2 describes the behavior for pdev via iommu_register_ device(). for mdev a new helper (e.g. iommu_register_device_pasid()) is required and then the IOMMU-API will also provide a pasid variation for creating security context per pasid. sw mdev will also have its binding helper to indicate no routing info required in ioasid attaching. Thanks Kevin
Powered by blists - more mailing lists