| 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
| ||
|
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37D2EED26@ORSMSX112.amr.corp.intel.com>
Date: Fri, 22 May 2015 14:58:18 +0000
From: "Moore, Robert" <robert.moore@...el.com>
To: "Williams, Dan J" <dan.j.williams@...el.com>,
Linda Knippers <linda.knippers@...com>
CC: Toshi Kani <toshi.kani@...com>, Jens Axboe <axboe@...nel.dk>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
Neil Brown <neilb@...e.de>,
Greg KH <gregkh@...uxfoundation.org>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux ACPI <linux-acpi@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
"Zheng, Lv" <lv.zheng@...el.com>, Christoph Hellwig <hch@....de>
Subject: RE: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure and
NFIT support
It looks to me that you are correct and I screwed up when I made those strings. The odd thing is that we had discussed this whole issue internally for a few days -- then I went ahead and messed up the strings. I think my brain was going around in circles.
Anyway, here is the latest info, please have a look:
Below is the GUID for volatile memory region directly from the ACPI spec:
{ 0x7305944F, 0xFDDA, 0x44E3, 0xB1, 0x6C, 0x3F, 0x22, 0xD2, 0x52, 0xE5, 0xD0 }
Here is an example of ToUUID using a corrected version of the GUID string. Note that the ordering of the string is identical to the version in the ACPI spec:
11: Name (UUID, ToUUID ("7305944F-FDDA-44E3-B16C-3F22D252E5D0"))
Here is the AML output of the ToUUID macro. Note that the first three fields are reversed, the rest of the string is left as-is (as per the ToUUID definition):
00000024: 08 55 55 49 44 ......... ".UUID"
00000029: 11 13 0A 10 4F 94 05 73 "....O..s"
00000031: DA FD E3 44 B1 6C 3F 22 "...D.l?""
00000039: D2 52 E5 D0 ............ ".R.."
This is the important part:
4F 94 05 73 "....O..s"
00000031: DA FD E3 44 B1 6C 3F 22 "...D.l?""
00000039: D2 52 E5 D0
I believe that this is correct.
Thanks for your help,
Bob
> -----Original Message-----
> From: Dan Williams [mailto:dan.j.williams@...el.com]
> Sent: Thursday, May 21, 2015 2:35 PM
> To: Linda Knippers
> Cc: Toshi Kani; Jens Axboe; linux-nvdimm@...ts.01.org; Neil Brown; Greg
> KH; Wysocki, Rafael J; Moore, Robert; linux-kernel@...r.kernel.org; Linux
> ACPI; Ingo Molnar; Zheng, Lv; Christoph Hellwig
> Subject: Re: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure
> and NFIT support
>
> On Thu, May 21, 2015 at 1:59 PM, Linda Knippers <linda.knippers@...com>
> wrote:
> > On 05/21/2015 03:59 PM, Toshi Kani wrote:
> >> On Thu, 2015-05-21 at 13:44 -0600, Toshi Kani wrote:
> >>> On Thu, 2015-05-21 at 12:06 -0700, Dan Williams wrote:
> >>>> On Thu, May 21, 2015 at 11:01 AM, Toshi Kani <toshi.kani@...com>
> wrote:
> >>>>> On Thu, 2015-05-21 at 17:49 +0000, Moore, Robert wrote:
> >>>>>> What ACPICA has done here is to define these values consistently
> with the ToUUID ASL macro:
> >>>>>>
> >>>>>>
> >>>>>> Byte encoding of UUID/GUID strings into ACPI Buffer objects (use
> ToUUID from ASL):
> >>>>>>
> >>>>>> Input UUID/GUID String format : aabbccdd-eeff-gghh-iijj-
> kkllmmnnoopp
> >>>>>> Expected output ACPI buffer : dd,cc,bb,aa, ff,ee, hh,gg,
> >>>>>> ii,jj, kk,ll,mm,nn,oo,pp
> >>>>>>
> >>>>>
> >>>>> I do not see any issue in this conversion, which is consistent
> >>>>> with ToUUID defined in ACPI spec.
> >>>>>
> >>>>> My point is that the string format of GUID is endian-neutral.
> >>>>> Wiki pages and EFI spec agree on it. EFI 2.5 spec, Table 225
> >>>>> (sorry not Table 212, which is v2.4), is also clear about how
> >>>>> String and Buffer are related with actual values of GUID.
> >>>>
> >>>> I think the critical point from the UEFI spec is the "It should
> >>>> also be noted that TimeLow, TimeMid, TimeHighAndVersion fields in
> >>>> the EFI are encoded as little endian". That would imply the byte
> >>>> encoding of...
> >>>>
> >>>> { 0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67, 0xE8,
> >>>> 0x23, 0x4C }
> >>>>
> >>>> ...should be:
> >>>>
> >>>> { f6,01,f7,92,b4,13,5d,40,91,0b,29,93,67,e8,23,4c }
> >>>
> >>> The above NFIT GUID as data values means:
> >>>
> >>> EFI_GUID(0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67,
> >>> 0xE8, 0x23, 0x4C)
> >>>
> >>>> Which implies the text conversion should be:
> >>>>
> >>>> "92f701f6-13b4-405d-910b-299367e8234c"
> >>>
> >>> Nope.
> >>
> >> Oops! Sorry, I misread your email... The above string is correct,
> >> although I do not think you need such conversion.
> >>
> >>> EFI 2.5 spec, Appendix A "GUID and Time Formats" defines that:
> >>> (NOTE, I simplified the table 225 to fit in this email) == This
> >>> specification also defines a standard text representation of the
> >>> GUID. This format is also sometimes called the “registry format”. It
> >>> consists of 36 characters, as follows:
> >>>
> >>> aabbccdd-eeff-gghh-iijj-kkllmmnnoopp
> >>> :
> >>>
> >>> Table 225. Text representation relationships
> >>> String Offset In Buffer EFI_GUID
> >>> aa 3 Data1[24:31]
> >>> bb 2 Data1[16:23]
> >>> cc 1 Data1[8:15]
> >>> dd 0 Data1[0:7]
> >>> :
> >>> ===
> >>>
> >>> Therefore:
> >>>
> >>> aa = Data1[21:31] = 92
> >>> bb = Data1[16:23] = F7
> >>> cc = Data1[8:15] = 01
> >>> dd = Data1[0:7] = F6
> >>>
> >>>> ...not
> >>>>
> >>>>> +#define UUID_CONTROL_REGION "f601f792-b413-5d40-910b-
> 299367e8234c"
> >>>
> >>> Hence, the above string is correct.
> >>
> >> Misread again... Right, the above string is NOT correct.
> >>
> >> I think we are on the same page that the GUID strings in this patch
> >> need to be changed.
> >>
> >> { 0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67, 0xE8,
> >> 0x23, 0x4C }
> >>
> >> should be defined as:
> >>
> >> "92f701f6-13b4-405d-910b-299367e8234c"
> >
> > I've lost track of the right answer but should we be discussing it in
> > the context of this patch too?
> >
> > http://www.spinics.net/lists/linux-acpi/msg57825.html
> > [PATCH 18/19] ACPICA: ACPI 6.0: Add support for NFIT table.
> >
> > Dan's version of the file has lots of other UUIDs too, beyond NFIT.
>
> Yeah, it's not clear whether those other GUIDs are actually GUIDs or these
> byte-swapped "EFI GUID"s. At least for NFIT it seems that the intent was
> EFI GUID ordering due to the note about needing to match the "Disk Type
> GUID" format from the EFI spec.
>
> I circle back with the ACPICA folks.
Powered by blists - more mailing lists