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: <MWHPR11MB1886239C82D6B66A732830B88C309@MWHPR11MB1886.namprd11.prod.outlook.com>
Date:   Tue, 15 Jun 2021 02:31:39 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Alex Williamson <alex.williamson@...hat.com>,
        Jason Gunthorpe <jgg@...dia.com>
CC:     Joerg Roedel <joro@...tes.org>,
        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>,
        Eric Auger <eric.auger@...hat.com>,
        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: Plan for /dev/ioasid RFC v2

> From: Alex Williamson <alex.williamson@...hat.com>
> Sent: Tuesday, June 15, 2021 12:28 AM
> 
[...]
> > IOASID. Today the group fd requires an IOASID before it hands out a
> > device_fd. With iommu_fd the device_fd will not allow IOCTLs until it
> > has a blocked DMA IOASID and is successefully joined to an iommu_fd.
> 
> Which is the root of my concern.  Who owns ioctls to the device fd?
> It's my understanding this is a vfio provided file descriptor and it's
> therefore vfio's responsibility.  A device-level IOASID interface
> therefore requires that vfio manage the group aspect of device access.
> AFAICT, that means that device access can therefore only begin when all
> devices for a given group are attached to the IOASID and must halt for
> all devices in the group if any device is ever detached from an IOASID,
> even temporarily.  That suggests a lot more oversight of the IOASIDs by
> vfio than I'd prefer.
> 

This is possibly the point that is worthy of more clarification and
alignment, as it sounds like the root of controversy here.

I feel the goal of vfio group management is more about ownership, i.e. 
all devices within a group must be assigned to a single user. Following
the three rules defined by Jason, what we really care is whether a group
of devices can be isolated from the rest of the world, i.e. no access to
memory/device outside of its security context and no access to its 
security context from devices outside of this group. This can be achieved
as long as every device in the group is either in block-DMA state when 
it's not attached to any security context or attached to an IOASID context 
in IOMMU fd.

As long as group-level isolation is satisfied, how devices within a group 
are further managed is decided by the user (unattached, all attached to 
same IOASID, attached to different IOASIDs) as long as the user 
understands the implication of lacking of isolation within the group. This 
is what a device-centric model comes to play. Misconfiguration just hurts 
the user itself.

If this rationale can be agreed, then I didn't see the point of having VFIO
to mandate all devices in the group must be attached/detached in
lockstep. 

Thanks
Kevin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ