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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPeXnHvnVbr_2gCnGK0ibnm4bauMHoEvp3rROnDuSoYgz-aniw@mail.gmail.com>
Date:   Wed, 4 Jan 2017 12:11:49 -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 3:13 AM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>> Add a force_probe sysfs node to each device, which if written will
>> trigger a probe even if defer_all_probes is currently true.
>
> Why not just manually trigger the bind of the device?  I don't
> understand the problem here that is being addressed, nor do I understand
> how this would be used.  More explaination please.

Userspace doesn't know the order that the kernel will use when
attempting to bind drivers, so punting binding out to userspace may
result in different behaviour. The kernel already has the code to do
this, so we should just reuse it.