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  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:   Wed, 4 Jan 2017 14:06:35 -0600
From:   Matthew Garrett <>
To:     Greg Kroah-Hartman <>
Cc:     Kees Cook <>,
        Linux Kernel Mailing List <>,
Subject: Re: [PATCH] Allow userspace to request device probing even if
 defer_all_probes is true

On Wed, Jan 4, 2017 at 2:03 PM, Greg Kroah-Hartman
<> wrote:
> On Wed, Jan 04, 2017 at 01:53:45PM -0600, Matthew Garrett wrote:
>> If you have two loaded drivers that could bind to the device then the
>> order you attempt to bind them in will matter.
> If you have that, you are screwed no matter what.  The driver model
> never guarantees any order in which a driver and device is matched up,
> sorry, and if that's the goal of this patch somehow, then I'll strongly
> object to it.

It's not? The reason for implementing it this way is to avoid
duplicating functionality the kernel already has, especially when it's
impossible to precisely duplicate that behaviour in userspace.

>> If you plug in a device while defer_all_probes is true, it won't be
>> bound - that's the point. But if you have a USB keyboard and unplug it
>> and plug it, you'd then end up with no keyboard. So you want userspace
>> to be able to make an appropriate policy decision around which devices
>> should be bound, and you need a mechanism to allow userspace to
>> trigger that binding.
> Use the in-place mechanism for that, userspace gets notification that
> the device was plugged in, it can authorize it or not.  That's what
> systems have been doing for a while now, and is what that api was
> created for.

That doesn't work - the USB authorisation code doesn't give you enough
information to make that decision before driver binding occurs.

> I'm getting the impression that somehow these two different patches are
> a series and related to each other which is even more confusing...

Yes, this is only relevant with the other patch.

Powered by blists - more mailing lists