linux-kernel - RE: Dell Vostro 3360 multimedia keys

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: <d9fb91f31d704030b1b16aca8d36ecea@ausx13mpc120.AMER.DELL.COM>
Date:   Mon, 27 Nov 2017 19:21:57 +0000
From:   <Mario.Limonciello@...l.com>
To:     <oleksandr@...alenko.name>
CC:     <pali.rohar@...il.com>, <platform-driver-x86@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <mjg59@...f.ucam.org>,
        <dvhart@...radead.org>, <andy@...radead.org>,
        <dmitry.torokhov@...il.com>
Subject: RE: Dell Vostro 3360 multimedia keys

> -----Original Message-----
> From: platform-driver-x86-owner@...r.kernel.org [mailto:platform-driver-x86-
> owner@...r.kernel.org] On Behalf Of Oleksandr Natalenko
> Sent: Monday, November 27, 2017 12:32 PM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: pali.rohar@...il.com; platform-driver-x86@...r.kernel.org; linux-
> kernel@...r.kernel.org; mjg59@...f.ucam.org; dvhart@...radead.org;
> andy@...radead.org; dmitry.torokhov@...il.com
> Subject: Re: Dell Vostro 3360 multimedia keys
> 
> Hello.
> 
> On pondělí 27. listopadu 2017 17:56:07 CET Mario.Limonciello@...l.com wrote:
> > > /* snip */
> > > Looks like that Dell Vostro 3360 have this meaning for multimedia keys:
> > >
> > > first key: Mobility Center
> > > second key: Dell Support Center
> > > third key: Dell Instant Launch Manager
> > >
> > > (same as other Vostro laptops)
> >
> >
> > As I can tell the "Instant Launch" key is supposed to be emitted
> > both via WMI and scan code both.
> >
> > Can you please check SMBIOS table 0xb1 offset 0x08?  This is the misc
> > BIOS flags table.  It's been used for a few other drivers for other
> > purposes
> > too.  I expect that bit 1 should be set.  This should indicate
> > that the system supports instant launch manager button.  You can use that
> > to key off of for deviating behavior.
> 
> Is this correct:
> 
> [~]$ sudo dmidecode -t 0xb1
> # dmidecode 3.1
> Getting SMBIOS data from sysfs.
> SMBIOS 2.7 present.
> 
> Handle 0x003C, DMI type 177, 12 bytes
> OEM-specific Type
>         Header and Data:
>                 B1 0C 3C 00 1A 0E 00 00 01 00 00 00
> 
> ?
> 

Looks right to me.  For producing a patch for your system you can see an example of 
how b1 is parsed in this other driver:
https://github.com/torvalds/linux/blob/master/drivers/platform/x86/dell-smbios-wmi.c#L231

There are actually 4 flags words (the table is length 12), but the example structure above
only references the first since it's all that matters for that driver (to test if WMI bit is active).
This is the first bit in flags2.  Flags0, flags1, flags2, and flags3 will each be u16.

> >
> > As for why these two keys (first and second) seem to emit the same code,
> > keep in mind that these were machines from around the era of Windows Vista.
> > Microsoft had allowed applications to register tiles in the "mobility
> > center".
> > Dell had an application at that time (Quickset) that would receive the WMI
> > events and register tiles in the mobility center.  So the application could
> > then
> > know to open up mobility center applet when it needed to from WMI
> > request or to launch another application if it needed to.
> >
> > This has all obviously changed with newer versions of Windows.
> >
> > I would recommend to have a separate function in dell-wmi driver for when
> > you see instant launch key in misc flags table and to allow looking at
> > extended buffer for these behaviors.
> >
> >
> > >
> > > But do not know what KEY_* are used on other Vostro laptops for those
> > > keys. It would be great to use same KEY_*...
> >
> >
> > These first two aren't intended to be generally mapped (as I described
> > above).
> > I think for Linux you can map them if you desire by my above
> > description.
> > /* snip */