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: <5B8DA87D05A7694D9FA63FD143655C1B1AFFBE0A@HASMSX106.ger.corp.intel.com>
Date:	Tue, 27 May 2014 23:47:44 +0000
From:	"Winkler, Tomas" <tomas.winkler@...el.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	"arnd@...db.de" <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Usyskin, Alexander" <alexander.usyskin@...el.com>
Subject: RE: [char-misc-next 3/3] mei: add WPT second mei interface



> -----Original Message-----
> From: Greg KH [mailto:gregkh@...uxfoundation.org]
> Sent: Wednesday, May 28, 2014 01:07
> To: Winkler, Tomas
> Cc: arnd@...db.de; linux-kernel@...r.kernel.org; Usyskin, Alexander
> Subject: Re: [char-misc-next 3/3] mei: add WPT second mei interface
> 
> On Tue, May 27, 2014 at 09:42:19PM +0000, Winkler, Tomas wrote:
> > > > +/* PCH devices MEI 2 interface */
> > > > +const struct mei_cfg mei_me_pch_2_cfg = {
> > > > +	MEI_CFG_PCH_HFS,
> > > > +	.mei_id = 1
> > >
> > > That's going to be a recipe for disaster.  Have the MEI core allocate
> > > the id numbers as things are registered, don't have the individual
> > > drivers create their id.
> >
> > I'm don't think can ensure the enumeration order.
> 
> You should not be relying on the order to get anything right.
> 
> > This is per device not per driver configuration structure.
> > Each pci device is actually just  another head to one MEI device but heads are not
> equal the name/id matters
> > Yes I assume it looks odd at the first glance, anyhow we are open to any
> reasonable suggestions
> 
> Just dynamically allocate the numbers like all other subsystems do?
>
> Then userspace can open the device nodes it cares about, it should be
> able to somehow tell what device is what somehow, right?  If not, you
> are doing something wrong with the interface as you can't rely on minor
> numbers.
> 

The only way for user space to distinguish among interfaces is the same way as driver does by looking for device id. 
The assignment of the device name/id is pretty much static in the HW. Now the same device id database from the driver has to be copied 
to the udev rules or equivalent  and kept in sync.   
Most importantly all the legacy user space just opens /dev/mei  so I wanted to leave /dev/mei (not /dev/mei0) to be assigned always to the first mei head and to not break existing user space. 

Can you be a bit more specific on why we cannot depend on minor numbers and default naming rules, what is the scenario that will break? 

Thanks
Tomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ