linux-kernel - RE: [PATCH 3/3] platform/x86: dell-wmi: add keys to bios_to_linux

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: <f7ab352f27954bbb88bafb41d6b17fe1@AUSX13MPC105.AMER.DELL.COM>
Date:   Mon, 8 Jun 2020 20:58:38 +0000
From:   <Mario.Limonciello@...l.com>
To:     <pali@...nel.org>
CC:     <y.linux@...itcher.com>, <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <mjg59@...f.ucam.org>
Subject: RE: [PATCH 3/3] platform/x86: dell-wmi: add keys to
 bios_to_linux_keycode

> -----Original Message-----
> From: platform-driver-x86-owner@...r.kernel.org <platform-driver-x86-
> owner@...r.kernel.org> On Behalf Of Pali Rohár
> Sent: Monday, June 8, 2020 3:48 PM
> To: Limonciello, Mario
> Cc: y.linux@...itcher.com; linux-kernel@...r.kernel.org; platform-driver-
> x86@...r.kernel.org; mjg59@...f.ucam.org
> Subject: Re: [PATCH 3/3] platform/x86: dell-wmi: add keys to
> bios_to_linux_keycode
> 
> 
> [EXTERNAL EMAIL]
> 
> On Monday 08 June 2020 15:46:44 Mario.Limonciello@...l.com wrote:
> > I would actually question if there is value to lines in dell-wmi.c like
> this:
> >
> > pr_info("Unknown WMI event type 0x%x\n", (int)buffer_entry[1]);
> >
> > and
> >
> > pr_info("Unknown key with type 0x%04x and code 0x%04x pressed\n", type,
> code);
> >
> > In both of those cases the information doesn't actually help the user, by
> default it's
> > ignored by the driver anyway.  It just notifies the user it's something
> the driver doesn't
> > comprehend.  I would think these are better suited to downgrade to debug.
> And if
> > a key combination isn't doing something expected the user can use dyndbg
> to turn it
> > back on and can be debugged what should be populated or "explicitly"
> ignored.
> 
> My motivation for these messages was to provide information to user that
> kernel received event, but was not able to process it as it do not
> understand it.
> 
> It could help in situation when user press special key and nothing is
> delivered to userspace. But he could see that something happened in log.
> 

But does a user know what to do with this information?  From time to time
coming to kernel mailing list, but that's it.

I think same person who would know to come to kernel mailing list for a key
not working can likely also hand turning on dyndbg to get the info.

> Similar message is also printed by PS/2 keyboard driver atkbd.c:
> 
> 	case ATKBD_KEY_UNKNOWN:
> 		dev_warn(&serio->dev,
> 			 "Unknown key %s (%s set %d, code %#x on %s).\n",
> 			 atkbd->release ? "released" : "pressed",
> 			 atkbd->translated ? "translated" : "raw",
> 			 atkbd->set, code, serio->phys);
> 		dev_warn(&serio->dev,
> 			 "Use 'setkeycodes %s%02x <keycode>' to make it known.\n",
> 			 code & 0x80 ? "e0" : "", code & 0x7f);
> 		input_sync(dev);
> 		break;

I think the difference here is that user can actually do something from userland
to do with `setkeycodes` for PS2.