linux-kernel - Re: [PATCH v2] leds: ledtrig-morse: send out morse code

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, 4 Jul 2018 22:36:55 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Pavel Machek <pavel@....cz>, Willy Tarreau <w@....eu>
Cc:     Andreas Klinger <ak@...klinger.de>, ben.whitten@...il.com,
        geert+renesas@...der.be, pombredanne@...b.com,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        linux-leds@...r.kernel.org
Subject: Re: [PATCH v2] leds: ledtrig-morse: send out morse code

Hi All,

On 07/04/2018 08:19 PM, Pavel Machek wrote:
> Hi!
> 
>> On Wed, Jul 04, 2018 at 08:53:05AM +0200, Pavel Machek wrote:
>>> As I stated before, I don't think morse encoder belongs in kernel.
>>
>> On the opposite, I think that the kernel needs to be a bit more autonomous
>> when it comes to reporting its own issues. Being able to report a panic
>> when userland cannot be accessed for example is the reason why we've seen
>> various features such as blinking keyboard LEDs for this.
> 
> Being able to report panics by blinking would be nice... but proposed
> patch does NOT do that.

Actually we do have already drivers/leds/trigger/ledtrig-panic.c.

>>> LED pattern trigger should be merged, instead.
>>
>> Well, just like we have LED and LED triggers in the kernel, I think having
>> a generic way to use patterns could be nice and in this case Morse could be
>> one such pattern, but if that means it's limited to userland to configure
>> it then it sadly voids all of its benefits.
> 
> Proposed patch is already limited to configuration from userland... so
> it does not have any benefits.

We could turn this piece of code into a lib and make it usable by
both kernel/panic.c (similar to panic_blink) as well by
the ledtrig-morse.c.

> If special "panic blinking" mode is wanted -- I guess that would make
> sense.
> 
> But
> 
> a) trigger may not be right infrastructure for that; triggers need
> quite a lot kernel to be working, as they run in separate threads --
> panic blinking probably should be mdelay / brightness set / mdelay,
> and probably limited to LEDs that can be accessed without sleeping.
> 
> b) we may want trigger to be used for something else (Caps lock? HDD
> activity?)  when not panicked. Thus, again, trigger is not exactly
> suitable. (It might make sense to blink many/all LEDs simultaneously
> to make it super obvious to the user).
> 
> 									Pavel
> 

-- 
Best regards,
Jacek Anaszewski