linux-kernel - Re: [PATCH 2/2] dell-wmi-base: Handle Win-key Lock/Unlock events

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]

Message-ID: <20241030202029.3ugz75wiautw6ewt@pali>
Date: Wed, 30 Oct 2024 21:20:29 +0100
From: Pali Rohár <pali@...nel.org>
To: Kurt Borja <kuurtb@...il.com>
Cc: Dell.Client.Kernel@...l.com, hdegoede@...hat.com,
	ilpo.jarvinen@...ux.intel.com, linux-kernel@...r.kernel.org,
	platform-driver-x86@...r.kernel.org, w_armin@....de
Subject: Re: [PATCH 2/2] dell-wmi-base: Handle Win-key Lock/Unlock events

On Wednesday 30 October 2024 17:11:40 Kurt Borja wrote:
> On Wed, Oct 30, 2024 at 07:34:36PM +0100, Pali Rohár wrote:
> > On Wednesday 30 October 2024 15:15:33 Kurt Borja wrote:
> > > Some Alienware devices have a key that locks/unlocks the Win-key. This
> > 
> > Please specify (in comment / commit message) which devices. It would
> > help other developers in future to track for which device is this event
> > needed.
> 
> I will!
> 
> > 
> > > key triggers a WMI event that should be ignored, as it's handled
> > > internally by the firmware.
> > 
> > Can be this handling in FW ignored? So OS can use this key for any other
> > functionality?
> 
> Probably not. FW locks the Win-key regardless of how the event is
> handled.
> 
> > 
> > Anyway, what is that Win-key and its lock?
> 
> Win-key is the LEFTMETA key and the lock key is the RIGHTMETA key.

Ok, thanks for info.

So if the firmware handles and process RIGHTMETA key, it means that the
RIGHTMETA key is not usable for generic purposes on this machine?

> > 
> > > Signed-off-by: Kurt Borja <kuurtb@...il.com>
> > > ---
> > >  drivers/platform/x86/dell/dell-wmi-base.c | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/platform/x86/dell/dell-wmi-base.c b/drivers/platform/x86/dell/dell-wmi-base.c
> > > index 502783a7a..37fc0371a 100644
> > > --- a/drivers/platform/x86/dell/dell-wmi-base.c
> > > +++ b/drivers/platform/x86/dell/dell-wmi-base.c
> > > @@ -80,6 +80,12 @@ static const struct dmi_system_id dell_wmi_smbios_list[] __initconst = {
> > >  static const struct key_entry dell_wmi_keymap_type_0000[] = {
> > >  	{ KE_IGNORE, 0x003a, { KEY_CAPSLOCK } },
> > >  
> > > +	/* Win-key Lock */
> > > +	{ KE_IGNORE, 0xe000, {KEY_RESERVED} },
> > 
> > nit: code style: spaces around KEY_RESERVED.
> 
> I will fix it.
> 
> > 
> > Is not there some better constant for this KEY_*?
> 
> We could assign it KEY_RIGHTMETA.

Just to note that if the key is marked with KE_IGNORE, its value is not
used. But for documentation purposes it is a good idea to have written
there something other than KEY_RESERVED -- if it is possible.

For example it can be useful if somebody in future figure out how to
turn off processing of this key in firmware...

> > 
> > > +
> > > +	/* Win-key Unlock */
> > > +	{ KE_IGNORE, 0xe001, {KEY_RESERVED} },
> > > +
> > >  	/* Key code is followed by brightness level */
> > >  	{ KE_KEY,    0xe005, { KEY_BRIGHTNESSDOWN } },
> > >  	{ KE_KEY,    0xe006, { KEY_BRIGHTNESSUP } },
> > > -- 
> > > 2.47.0
> > >