linux-kernel - Re: [RFC PATCH v2 00/10] Add configurable block device LED triggers

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:   Mon, 9 Aug 2021 21:07:25 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Marek Behún <kabel@...nel.org>
Cc:     Ian Pilcher <arequipeno@...il.com>, 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 v2 00/10] Add configurable block device LED triggers

On Monday 09 August 2021 20:56:33 Marek Behún wrote:
> Hello Ian,
> 
> thank you for your proposal. Some comments below:
> 
> On Sun,  8 Aug 2021 22:32:07 -0500
> Ian Pilcher <arequipeno@...il.com> wrote:
> 
> > One thing that has not changed is that associations between block
> > devices and LEDs are still set via an attribute on the device, rather
> > than the LED.  This is much simpler, as the device attribute only has
> > to handle a single value (the name of the associated LED), rather than
> > potentially handling multiple device names.
> 
> It may be simpler, but it is in contrast to how the netdev trigger
> works, which already is in upstream for many years. I really think we
> should try to have similar sysfs ABIs here. (I understand that the
> netdev trigger is currently unable to handle multiple network
> interfaces - but it is possible to extend it so.)
> 
> > I have modeled the interface for the /sys/block/<DEVICE>/led
> > attribute on the sysfs interface used for selecting a trigger.  All
> > available LEDs (all LEDs associated with the blkdev trigger) are
> > shown when the attribute is read, with the currently selected LED
> > enclosed in square brackets ([]).
> 
> I think it is reasonable to be able to set something like this:
>   led0 : blink on activity on any of [sda, sdb, sdc]
>   led1 : blink on activity on sda
>   led2 : blink on activity on sdb
>   led3 : blink on activity on sdc
> 
> If I am reading your code correctly, it looks that only one LED can be
> configured for a block device. Is this true? If so, then the above
> configuration cannot be set.
> 
> Also you are blinking the LED on any request to the block device. I
> would rather expect to be able to set the LED to blink on read and on
> write. (And possibly on other functions, like discard, or critical
> temperature, or error, ...) I would like to know what other people
> think about this.

Hello!

HP EliteBook laptops had dedicated LED for some kind of error and
encryption indication. And there is kernel acpi/wmi driver which can
control this LED. I do not know if recent HP laptops still have these
LEDs, but I would suggest to design API in a way that would allow to use
these dedicated LEDs for their original "vendor" purpose.

I'm mentioning it just because this functionality and design is already
on existing production mainstream laptops, and not something imaginary.

If Linux distributions are still cooperating with laptop vendors and
doing "official" Linux preloads then they may be interested in having
"native" LED functionality support in kernel.