linux-kernel - Re: [PATCH v3 7/9] vfio: Use driver_override to avert binding to compromising drivers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Jul 2017 11:46:27 +0200
From:   Greg KH <greg@...ah.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Russell King - ARM Linux <linux@...linux.org.uk>,
        kvm@...r.kernel.org, eric.auger@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 7/9] vfio: Use driver_override to avert binding to
 compromising drivers

On Mon, Jul 10, 2017 at 03:34:12PM -0600, Alex Williamson wrote:
> On Mon, 26 Jun 2017 10:08:55 +0100
> Russell King - ARM Linux <linux@...linux.org.uk> wrote:
> 
> > On Tue, Jun 20, 2017 at 09:48:31AM -0600, Alex Williamson wrote:
> > > If a device is bound to a non-vfio, non-whitelisted driver while a
> > > group is in use, then the integrity of the group is compromised and
> > > will result in hitting a BUG_ON.  This code tries to avoid this case
> > > by mangling driver_override to force a no-match for the driver.  The
> > > driver-core will either follow-up with a DRIVER_NOT_BOUND (preferred)
> > > or BOUND_DRIVER, at which point we can remove the driver_override
> > > mangling.  
> > 
> > Rather than mangling the driver override string to prevent driver binding,
> > I wonder if it would make more sense to allow the BUS_NOTIFY_BIND_DRIVER
> > notifier to fail the device probe?
> 
> Well, it seemed like a good idea, but I don't think we're getting any
> traction here, the thread has gone cold:
> 
> https://lkml.org/lkml/2017/6/27/1002
> 
> Greg, any further comments?

I still think your drivers should be fixed, adding
yet-another-odd-interaction with the driver core is ripe for added
complexity...

And, as there's no real patch for me to do anything with (hint, I can't
apply RFC patches), I don't know what I can do here...

thanks,

greg k-h