netdev - Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support

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] [day] [month] [year] [list]

Date:   Tue, 13 Mar 2018 12:17:34 -0400
From:   Don Dutile <ddutile@...hat.com>
To:     David Woodhouse <dwmw2@...radead.org>,
        Alexander Duyck <alexander.duyck@...il.com>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
        linux-pci@...r.kernel.org, virtio-dev@...ts.oasis-open.org,
        kvm@...r.kernel.org, Netdev <netdev@...r.kernel.org>,
        "Daly, Dan" <dan.daly@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-nvme@...ts.infradead.org,
        Keith Busch <keith.busch@...el.com>, netanel@...zon.com,
        Maximilian Heyne <mheyne@...zon.de>,
        "Wang, Liang-min" <liang-min.wang@...el.com>,
        "Rustad, Mark D" <mark.d.rustad@...el.com>,
        Christoph Hellwig <hch@....de>
Subject: Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support

On 03/13/2018 11:04 AM, David Woodhouse wrote:
> On Tue, 2018-03-13 at 07:51 -0700, Alexander Duyck wrote:
> 
>> Actually the suggestion I had from Don Dutile was that we should be
>> looking at creating a pci-stub like driver specifically for those type
>> of devices, but without the ability to arbitrarily assign devices.
>> Basically we have to white-list it in one device at a time for those
>> kind of things.
> 
> It's still not clear what the point of that would be.
> 
A PF-stub to do device-assignment(-like) ops preserves the current security model,
and allows one to add pci-quirks at a device-level as well -- when the usual ACS
structs aren't properly added for a device, which happens quite frequently -- which
retains that common workaround as well.
Yet-another-method for VF assignment w/o even a simple PF driver stub
created multiple failure cases/configs when we were hashing the multiple options
a few weeks ago.
It's just simpler to implement a PF stub w/VF enablement ... b/c it's simple...

>> If you have the device ID of the thing you wanted to have work with
>> pci-stub before I could look at putting together a quick driver and
>> adding it to this set.
> 
> 1d0f:0053 would be an example.
>