[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180616073334.GA13880@amd>
Date: Sat, 16 Jun 2018 09:33:34 +0200
From: Pavel Machek <pavel@....cz>
To: Henrique de Moraes Holschuh <hmh@....eng.br>
Cc: Pali Rohár <pali.rohar@...il.com>,
Henrique de Moraes Holschuh <ibm-acpi@....eng.br>,
ibm-acpi-devel@...ts.sourceforge.net,
platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ThinkPad T480s & LED_MUTE, LED_MICMUTE
Hi!
On Fri 2018-06-15 20:36:28, Henrique de Moraes Holschuh wrote:
> On Fri, 15 Jun 2018, Pali Rohár wrote:
> > This means that kernel should not export any led class device. Or when
> > exported, then "set" operation should always fail.
>
> "not export" is right.
>
> > > 2. Otherwise implement it in-kernel, so that userspace cannot unmute
> > > when the human has activated the "mute" switch, and the LED cannot be
> > > controlled by userspace to lie (report mute when it is not mute).
> >
> > This looks like a good candidate to use led "trigger" interface. Create
> > a mute trigger and attach it to that led device.
>
> Maybe, as long as done in-kernel and not possible to mess with from
> userspace.
Question is if we want flexibility or security.
If we want security, going through LED subsystem makes no sense, just
control the LED as hardware would, or let hardware do it.
For full flexibility, just export the LED and use normal mechanisms we
have (such as triggers). root should be allowed to configure the LEDs,
and he can change the kernel, too, so...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists