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:   Mon, 6 Nov 2017 15:47:41 -0800
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     "Wang, Liang-min" <liang-min.wang@...el.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Christoph Hellwig <hch@...radead.org>,
        "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
        "O'riordain, Seosamh" <seosamh.oriordain@...el.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 Mon, Nov 6, 2017 at 3:27 PM, Alex Williamson
<alex.williamson@...hat.com> wrote:
> On Tue, 31 Oct 2017 12:55:20 +0000
> "Wang, Liang-min" <liang-min.wang@...el.com> wrote:
>
>> > -----Original Message-----
>> > From: David Woodhouse [mailto:dwmw2@...radead.org]
>> > Sent: Monday, October 30, 2017 8:39 AM
>> > To: Christoph Hellwig <hch@...radead.org>; Duyck, Alexander H
>> > <alexander.h.duyck@...el.com>
>> > Cc: Wang, Liang-min <liang-min.wang@...el.com>;
>> > alex.williamson@...hat.com; linux-kernel@...r.kernel.org; Kirsher, Jeffrey T
>> > <jeffrey.t.kirsher@...el.com>; kvm@...r.kernel.org; bhelgaas@...gle.com;
>> > linux-pci@...r.kernel.org
>> > Subject: Re: [PATCH] Enable SR-IOV instantiation through /sys file
>> >
>> > On Sat, 2017-10-28 at 23:16 -0700, Christoph Hellwig 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.
>> >
>> > I have them, which is why I'm patching the UIO driver to allow num_vfs
>> > to be set. I don't even want to *use* the UIO driver for any purpose
>> > except to make that appear in sysfs. It's all handled in the device.
>> >
>> > (I think we might be able to just give the PF out to a guest as if it
>> > were just another VF, but I don't think we actually *do* that right
>> > now).
>>
>> Under UEFI secure boot environment, kernel puts restrictions on UIO and its derivatives.
>> So, user-space function/driver based upon UIO is no longer working under UEFI secure
>> boot environment. The next viable option is vfio-pci, hence this patch in parallel with
>> UIO work.
>
> If you want a PF driver that does nothing other than allow SR-IOV to be
> enabled, doesn't that scream pci-stub?  Trying to overlay it onto a
> driver that also allows userspace driver access to that device seems
> like the worst idea.  Thanks,
>
> Alex

So for the case where a user-space agent is running the actual PF how
is it you suggest we go about quarantining the interfaces? What kind
of behavior is it you are expecting to see? Should we look into a way
to clear match_driver for the VF interfaces so the drivers won't load
on them at all, or are you expecting something like vfio-pci to be
selected to auto-load on them since the PF is already running that?

Thanks.

- Alexander

Powered by blists - more mailing lists