linux-kernel - Re: [RFC PATCH 1/8] docs: Add block device LED trigger documentation

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:   Thu, 29 Jul 2021 13:03:36 -0500
From:   Ian Pilcher <arequipeno@...il.com>
To:     Marek Behún <kabel@...nel.org>
Cc:     linux-block@...r.kernel.org, linux-leds@...r.kernel.org,
        axboe@...nel.dk, pavel@....cz, linux-kernel@...r.kernel.org,
        kernelnewbies@...nelnewbies.org
Subject: Re: [RFC PATCH 1/8] docs: Add block device LED trigger documentation

On 7/29/21 6:59 AM, Marek Behún wrote:
> I don't really see the purpose for having multiple different block
> device LED triggers. 

Is there a different/better way to control per-device LEDs?  (I'm
thinking of something like my NAS, which has 5 drive bays, each with
its own activity LED.)

> Moreover we really do not want userspace to be
> able to add LED triggers with arbitrary names, and as many as the
> userspace wants.

To be slightly flippant, why not?  "Userspace" in this case is the
system/device administrator.  They presumably know what LEDs they have
and what they want to use them for, something which the kernel cannot
know (assuming a "generic" disto kernel).

> There is no sense in making userspace be able to
> create 10000 triggers.

It would certainly be possible to impose a limit on the number of
triggers that could be created.  But then someone has to decide what
that limit should be.  Personally, I lean very much toward giving the
system administrator the freedom to configure their system as they see
fit, even if that means that they can break it.  (Where "break"
basically means that they need to reboot.)

> Also if userspace can create triggers with
> arbitrary names, it could "steal" a name for a real trigger. For
> example if netdev trigger is compiled as a module, and before loading
> someone creates blockdev trigger with name "netdev", the loading of
> netdev trigger will fail.

Would adding a prefix to the LED trigger name address your concern
about arbitrary names and potential conflicts?  I.e. the system
administrator creates a block device LED trigger named "foo", and it
shows up as an LED trigger named "blkdev:foo" (or something like that).

> I would like the blkdev trigger to work in a similar way the netdev
> trigger works:
> - only one trigger, with name "blkdev"
> - when activated on a LED, new sysfs files will be created:
>    * device_name, where user can write sda1, vdb, ...
>    * read (binary value, 1 means blink on read)
>    * write (binary value, 1 means blink on write)
>    * interval (blink interval)
>    Note that device_name could allow multiple names, in theory...
>    Also some other disk states may be included, like error, or something

How would you support multiple, per-device LEDs (the NAS use case above)
in this scheme?

> - also the blinking itself can be done as is done netdev trigger: every
>    50ms the work function would look at blkdev stats, and if current
>    stat (number of bytes read/written) is different from previous, then
>    blink the LED

Is there a reason that you prefer this approach to simply having the
block layer "fire" the trigger?

Thanks for the feedback!

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================