linux-kernel - RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer

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: <BYAPR11MB3256014ACBE12F02D6738F0287489@BYAPR11MB3256.namprd11.prod.outlook.com>
Date:   Tue, 20 Apr 2021 15:54:48 +0000
From:   "Moore, Robert" <robert.moore@...el.com>
To:     "Kaneda, Erik" <erik.kaneda@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>
CC:     linux-nvdimm <linux-nvdimm@...ts.01.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Verma, Vishal L" <vishal.l.verma@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "Weiny, Ira" <ira.weiny@...el.com>
Subject: RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer



-----Original Message-----
From: Kaneda, Erik <erik.kaneda@...el.com> 
Sent: Monday, April 19, 2021 3:56 PM
To: Williams, Dan J <dan.j.williams@...el.com>; Andy Shevchenko <andriy.shevchenko@...ux.intel.com>; Moore, Robert <robert.moore@...el.com>; Wysocki, Rafael J <rafael.j.wysocki@...el.com>
Cc: linux-nvdimm <linux-nvdimm@...ts.01.org>; Linux Kernel Mailing List <linux-kernel@...r.kernel.org>; Verma, Vishal L <vishal.l.verma@...el.com>; Jiang, Dave <dave.jiang@...el.com>; Weiny, Ira <ira.weiny@...el.com>
Subject: RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer

+Bob and Rafael

> -----Original Message-----
> From: Dan Williams <dan.j.williams@...el.com>
> Sent: Friday, April 16, 2021 3:09 PM
> To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> Cc: linux-nvdimm <linux-nvdimm@...ts.01.org>; Linux Kernel Mailing 
> List <linux-kernel@...r.kernel.org>; Verma, Vishal L 
> <vishal.l.verma@...el.com>; Jiang, Dave <dave.jiang@...el.com>; Weiny, 
> Ira <ira.weiny@...el.com>; Kaneda, Erik <erik.kaneda@...el.com>
> Subject: Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw 
> buffer
> 
> On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko 
> <andriy.shevchenko@...ux.intel.com> wrote:
> >
> > On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote:
> > > [ add Erik ]
> > >
> > > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko 
> > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote:
> > > > > Strictly speaking the comparison between guid_t and raw buffer 
> > > > > is not correct. Return to plain memcmp() since the data 
> > > > > structures haven't changed to use uuid_t / guid_t the current 
> > > > > state of affairs is inconsistent. Either it should be changed 
> > > > > altogether or left as is.
> > > >
> > > > Dan, please review this one as well. I think here you may agree with me.
> > >
> > > You know, this is all a problem because ACPICA is using a raw buffer.
> >
> > And this is fine. It might be any other representation as well.
> >
> > > Erik, would it be possible to use the guid_t type in ACPICA? That 
> > > would allow NFIT to drop some ugly casts.
> >
> > guid_t is internal kernel type. If we ever decide to deviate from 
> > the current representation it wouldn't be possible in case a 3rd 
> > party is using it 1:1 (via typedef or so).
> 
Hi Dan,

> I'm thinking something like ACPICA defining that space as a union with 
> the correct typing just for Linux.

I'm assuming that you mean using something like guid_t type for ACPI data table fields like NFIT rather than objects returned by ACPI namespace object such as _DSD.

For ACPI data tables, we could to use macros so that different operating systems can provide their own definitions for a guid. For ACPICA, it will expands to a 16-byte array. Linux can have it's own definition that contains a union or their own guid type (guid_t). As long as the OS-supplied definition is 16bytes, I don't think there would be an issue.

Erik,
I don't like to add these kinds of macros, since it is simply another item that needs to be added to port ACPICA to different hosts. (And must be known by the porter.)

Other than that, I suppose we can add such a macro.

Bob, do you have any thoughts on this?
Erik