linux-kernel - Re: [PATCH 4/5] driver core: inhibit automatic driver binding on reserved devices

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:   Fri, 22 Oct 2021 08:46:56 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Zev Weiss <zev@...ilderbeest.net>
Cc:     Frank Rowand <frowand.list@...il.com>,
        Rob Herring <robh+dt@...nel.org>, openbmc@...ts.ozlabs.org,
        Jeremy Kerr <jk@...econstruct.com.au>,
        Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Dave Jiang <dave.jiang@...el.com>,
        Vinod Koul <vkoul@...nel.org>,
        Kirti Wankhede <kwankhede@...dia.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Saravana Kannan <saravanak@...gle.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Bhaskar Chowdhury <unixbhaskar@...il.com>,
        Jianxiong Gao <jxgao@...gle.com>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        Rajat Jain <rajatja@...gle.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        dmaengine@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH 4/5] driver core: inhibit automatic driver binding on
 reserved devices

On Thu, Oct 21, 2021 at 07:00:31PM -0700, Zev Weiss wrote:
> Devices whose fwnodes are marked as reserved are instantiated, but
> will not have a driver bound to them unless userspace explicitly
> requests it by writing to a 'bind' sysfs file.  This is to enable
> devices that may require special (userspace-mediated) preparation
> before a driver can safely probe them.
> 
> Signed-off-by: Zev Weiss <zev@...ilderbeest.net>
> ---
>  drivers/base/bus.c            |  2 +-
>  drivers/base/dd.c             | 13 ++++++++-----
>  drivers/dma/idxd/compat.c     |  3 +--
>  drivers/vfio/mdev/mdev_core.c |  2 +-
>  include/linux/device.h        | 14 +++++++++++++-
>  5 files changed, 24 insertions(+), 10 deletions(-)

Ugh, no, I don't really want to add yet-another-state to the driver core
like this.  Why are these devices even in the kernel with a driver that
wants to bind to them registered if the driver somehow should NOT be
bound to it?  Shouldn't all of that logic be in the crazy driver itself
as that is a very rare and odd thing to do that the driver core should
not care about at all.

And why does a device need userspace interaction at all?  Again, why
would the driver not know about this and handle it all directly?

thanks,

greg k-h