linux-kernel - Re: [PATCH] Enable SR-IOV instantiation through /sys file

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]

Date:   Sun, 29 Oct 2017 14:12:52 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
        "Wang, Liang-min" <liang-min.wang@...el.com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH] Enable SR-IOV instantiation through /sys file

On Sat, Oct 28, 2017 at 11:16 PM, Christoph Hellwig <hch@...radead.org> wrote:
> On Fri, Oct 27, 2017 at 11:20:41PM +0000, Duyck, Alexander H wrote:
>> I don't see this so much as a security problem per-se. It all depends
>> on the hardware setup. If I recall correctly, there are devices where
>> the PF function doesn't really do much other than act as a bit more
>> heavy-weight VF, and the actual logic is handled by a firmware engine
>> on the device.
>
> Can you cite an example?  While those surely could exist in theory,
> I can't think of a practical example.

If I recall the neterion vxge driver fell into that category if I
recall correctly. Basically the hardware is preconfigured for some
number of VFs and their driver just calls pci_enable_sriov and enables
them.

One other thing I forgot about is the fact that we already have
drivers such as igb, ixgbe, and vxge floating around that will leave
SR-IOV enabled if the driver is loaded while VFs are direct assigned
to guests. As a side effect we can sort of already support assigning
vfio-pci to a driver that has SR-IOV enabled.

> Maybe we can start with the practical use case for this patch.  That
> is what device is this intended for?

If I am not mistaken the typical use case for a patch like this is to
support loading something like DPDK on a networking device PF, whlie
the VFs are assigned to virtualized guests and/or containers. It would
move the control of the PF/VFs into use space, but in the grand scheme
of things it isn't much different then when a virtualized guest has a
VF and has no direct control over the configuration of it since the
host is managing that.

So if the root user is enabling SR-IOV and allocating VFs on a device
that is running the vfio-pci driver the assumption is that the root
user must be trusting the application that is running on top of the
vfio-pci driver to behave correctly.