linux-kernel - RE: [PATCH v1] mei: Don't encourage to use kernel internal types in user code

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] [day] [month] [year] [list]

Message-ID: <c42fc7597d7c4d0a9867c41a94b0844b@intel.com>
Date:   Mon, 2 Mar 2020 18:05:38 +0000
From:   "Winkler, Tomas" <tomas.winkler@...el.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Christoph Hellwig" <hch@....de>
Subject: RE: [PATCH v1] mei: Don't encourage to use kernel internal types in
 user code

> 
> +Cc: Christoph.
> 
> On Sat, Feb 29, 2020 at 04:28:11PM +0000, Winkler, Tomas wrote:
> > > uuid_le is internal kernel type which shall not be exposed to the
> > > user in the first place.
> > Why, these types are exported via include/uapi/linux/uuid.h
> 
> Which is wrong from the day 1.
I'm not sure why, this is API between kernel and the user space. 

> The uuid_t type is being provided by libuuid in the user space, there is no
> (more) kernel exported equivalent. Same should be done to the uuid_le.

There are many uuid libraries, which  is the one that provides the uuid type
between kernel and the user space? 

> 
> We already discussed this couple of years ago.
I do not recall be part of this conversation, please share the link. 

> 
> > In order to mitigate the (wrong) distribution of the use of that type,
> > > switch MEI AMT sample to plain unsigned char array.
> >
> > There was a change to guid_t from uuild_le, anyhow there is much more
> > code  except this sample that uses those types.
> 
> I guess you misunderstood the point. The types are for kernel use and keeping
> them exported in a condition like it's now (quoter baked due to drop of uuid_be
> part completely and uuid_le partially) is wrong.
Is wrong how... ?  What is broken in the concept ? Please give me an example of what is going to wrong, here. 
Just saying that something is wrong is not convincing. 

> There is *no* ABI change. And basically libuuid or another one should provide
> type and infrastructure for this.
But API is already out there, do you plan to remove it? 
  
> > Nack so far.
> 
> If you would like to bear the legacy type, why not to move this UUID UAPI parts
> directly to MEI?
I can but do you know all the software that includes <linux/uuid.h> ?
Thanks
Tomas