linux-kernel - RE: Plan for /dev/ioasid RFC v2

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: <BN9PR11MB5433DCBE6DE1EC27CFB9D3738C039@BN9PR11MB5433.namprd11.prod.outlook.com>
Date:   Mon, 28 Jun 2021 02:03:56 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     "Alex Williamson (alex.williamson@...hat.com)" 
        <alex.williamson@...hat.com>, 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

Hi, Jason,

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Friday, June 25, 2021 10:36 PM
> 
> The only thing that needs to be done to get the 1:1 step is to broadly
> define how the other two cases will work so we don't get into trouble
> and set some way to exclude the problematic cases from even getting to
> iommu_fd in the first place.
> 
> For instance if we go ahead and create /dev/vfio/device nodes we could
> do this only if the group was 1:1, otherwise the group cdev has to be
> used, along with its API.
> 

I may misunderstand your position in last reply.

The bottom line is that iommu fd uAPI and helper functions should be
device-centric (no group fd carried). This is what this sketch tries to 
achieve.

However I'm getting confused on your position on vfio uAPIs. 

At some point I feel you are OK to keep vfio group fd:

    "For others, I don't think this is *strictly* necessary, we can
     probably still get to the device_fd using the group_fd and fit in
     /dev/ioasid. It does make the rest of this more readable though."
https://lore.kernel.org/linux-iommu/PH0PR12MB54811863B392C644E5365446DC3E9@PH0PR12MB5481.namprd12.prod.outlook.com/T/#m1b1d2b4d6413e3b32ba972a97c2c6a16bf491796

But you are also obviously against faking group for mdev. 

Combining with the last paragraph above, are you actually suggesting 
that 1:1 group (including mdev) should use a new device-centric vfio 
uAPI (without group fd) while existing group-centric vfio uAPI is only 
kept for 1:N group (with slight semantics change in my sketch to match 
device-centric iommu fd API)?

If yes, some assumptions in this sketch might be changed. For example,
with /dev/vfio/device node I'm not sure how the user can pass {iommu_fd,
device_cookie} to establish the security context when opening the node 
(not via an indirect group ioctl). Then it implies that we may have to allow 
the user open a device before it is put into a security context, thus the 
safe guard may have to be enabled on mmap() for 1:1 group. This is a
different sequence from the existing group-centric model.

Anyway, appreciate if you can elaborate your thoughts so we can further
think about them. 

Thanks
Kevin