linux-kernel - Re: [PATCH 1/9] sysfs: add sysfs_remove_bin_file

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:   Wed, 6 Oct 2021 22:58:59 -0700
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     openbmc@...ts.ozlabs.org, Jeremy Kerr <jk@...econstruct.com.au>,
        Joel Stanley <joel@....id.au>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/9] sysfs: add sysfs_remove_bin_file_self() function

On Wed, Oct 06, 2021 at 10:23:33PM PDT, Greg Kroah-Hartman wrote:
>On Wed, Oct 06, 2021 at 05:09:46PM -0700, Zev Weiss wrote:
>> This is simply the bin_attribute analog to sysfs_remove_file_self().
>
>No, no binary sysfs file should be triggering a remove.
>
>binary sysfs files are "pass-through-only" from userspace to hardware,
>the kernel should not be even knowing what is read/written to them.
>
>What do you think this is needed for?
>

So, I initially set out to be able to activate/deactivate specific DT 
nodes at runtime by using the device-tree "reserved" status as defined 
in the spec (but not currently used anywhere in the kernel) to mean 
essentially "create a device for this but don't bind a driver to it" 
(leaving it to userspace to invoke bind/unbind or similar), and added 
initial support for the specific driver I'm concerned with at the moment 
(aspeed-smc) -- that was the previous patch series linked in the cover 
letter of this one.

In the discussion of that series, Rob suggested as an alternate 
approach:

> Another possibility is making 'status' writeable from userspace. It is
> just a sysfs file.

That seemed sort of appealing to me, and this seemed like the most 
obvious way to go about implementing it.  Given that DT properties are 
binary attributes, I gather you'd consider that a non-starter though?

Zev