linux-kernel - Re: [PATCH v3 0/8] Introduce support for Dell SMBIOS over WMI

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171005024451.GI25018@fury>
Date:   Wed, 4 Oct 2017 19:44:51 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Mario.Limonciello@...l.com
Cc:     andy.shevchenko@...il.com, linux-kernel@...r.kernel.org,
        platform-driver-x86@...r.kernel.org, luto@...nel.org,
        quasisec@...gle.com, pali.rohar@...il.com
Subject: Re: [PATCH v3 0/8] Introduce support for Dell SMBIOS over WMI

On Sat, Sep 30, 2017 at 07:56:33PM +0000, Mario.Limonciello@...l.com wrote:
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@...radead.org]
> > Sent: Friday, September 29, 2017 9:17 PM
> > To: Limonciello, Mario <Mario_Limonciello@...l.com>
> > Cc: Andy Shevchenko <andy.shevchenko@...il.com>; LKML <linux-
> > kernel@...r.kernel.org>; platform-driver-x86@...r.kernel.org; Andy Lutomirski
> > <luto@...nel.org>; quasisec@...gle.com; pali.rohar@...il.com
> > Subject: Re: [PATCH v3 0/8] Introduce support for Dell SMBIOS over WMI
> > 
> > On Wed, Sep 27, 2017 at 11:02:12PM -0500, Mario Limonciello wrote:

...

> > My other concern is the freeform structure around creating the file
> > operations in each driver for the chardev IOCTL. It seems like we need
> > some kind of defined mapping from METHOD index to IOCTL number, or else
> > some way to advertise what it is?
> > 
> 
> I was originally thinking it would be a good way to do this cleanly too, but my 
> main concern is this one character device may handle multiple methods problem.
> If you map method instance (index) to ioctl number you will most likely run into 
> clashes.  So maybe it's worth not allowing that?
> 
> So I've got another idea.  How about instead of a variety of freeform ioctl per driver,
> provide three ioctl functions for all the character devices that come in through
> the WMI bus to use (say IOC 'W') with either read, write or write/read.  The WMI bus
> should be able to know which driver to pass it on to by the character device used.
> 

This is not something I have any experience with. I see you added it to v4, so
let's see what others have to say there.

-- 
Darren Hart
VMware Open Source Technology Center