linux-kernel - Re: [PATCH] Allow userspace to request device probing even if defer_all

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]

Message-ID: <CAPeXnHuq9FUR4e4p1cMCuzhD5pE18FFjUbJvaaB2zh-209vH9Q@mail.gmail.com>
Date:   Wed, 4 Jan 2017 14:06:35 -0600
From:   Matthew Garrett <mjg59@...eos.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kernel-hardening@...ts.openwall.com
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
<gregkh@...uxfoundation.org> 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.