From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.20, mailfrom: chao.b.zhang@intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by groups.io with SMTP; Wed, 24 Apr 2019 18:40:06 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2019 18:40:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,391,1549958400"; d="scan'208,217";a="134158824" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga007.jf.intel.com with ESMTP; 24 Apr 2019 18:40:05 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Apr 2019 18:40:05 -0700 Received: from shsmsx107.ccr.corp.intel.com (10.239.4.96) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Apr 2019 18:40:04 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.206]) by SHSMSX107.ccr.corp.intel.com ([169.254.9.153]) with mapi id 14.03.0415.000; Thu, 25 Apr 2019 09:40:03 +0800 From: chao.b.zhang@intel.com To: "devel@edk2.groups.io" , "afish@apple.com" , "Xu, Wei6" CC: Laszlo Ersek , "Kinney, Michael D" Subject: Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu Thread-Topic: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu Thread-Index: AdT6jzSICHuIDmzQTfyZ3FC2WNnHpf//yxCA//7cAlA= Date: Thu, 25 Apr 2019 01:40:01 +0000 Message-ID: References: <59B8EAB3797CDB4091332F0685A110ED50D6B722@SHSMSX104.ccr.corp.intel.com> <2F4FB4C7-8C2F-4B16-B89B-A4FE72BD5318@apple.com> In-Reply-To: <2F4FB4C7-8C2F-4B16-B89B-A4FE72BD5318@apple.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2Q1NDg3ZDktZjcyOC00YmY1LWI4MjUtODVhNzI0NGVhY2IzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRHNJTmp4eWxQYXB1ajhsbFwvSjBFcWtpWktkYmNZbktUMllweW93K3pFT3BXNFp1S3AwUmQ3Q2FLTFhBQjBxSEMifQ== dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: chao.b.zhang@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_FF72C7E4248F3C4E9BDF19D4918E90F24DEA208Eshsmsx102ccrcor_" --_000_FF72C7E4248F3C4E9BDF19D4918E90F24DEA208Eshsmsx102ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andrew: Tks for your explanation. The middle octet of StartingCHS (0x000200) is= for Sector. Based on CHS to LBA conversion rule. It should be 0x02. I th= ink it is an spec compliance issue. Partition Dxe driver doesn't apply such check so there is no problem. Par= tition Pei is in BIOS TCB, we applied stronger check and exposed this issue= . We need carefully document such limitation somewhere. BTW the whole GPT support in PEI is new in Q1 stable tag, From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andr= ew Fish via Groups.Io Sent: Thursday, April 25, 2019 12:07 AM To: devel@edk2.groups.io; Xu, Wei6 Cc: Laszlo Ersek ; Kinney, Michael D Subject: Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubun= tu The intent of the protective MBR was to prevent tools that did not underst= and GPT to not think a GPT disk was blank. 20 years ago that made a lot of = sense, today it is kind of an obsolete concept. The protective MBR was never intended to identify the disk as GPT, but it = seems it got used as a short cut to not have to read a variable number of b= locks from the disk to validate the GPT header. >>From a practical sense the DXE Partition driver uses this algorithm to val= idate the Protective MBR. It would be a good idea for the PEI code to do th= e same thing. https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Disk/= PartitionDxe/Gpt.c // // Verify that the Protective MBR is valid // for (Index =3D 0; Index < MAX_MBR_PARTITIONS; Index++) { if (ProtectiveMbr->Partition[Index].BootIndicator =3D=3D 0x00 && ProtectiveMbr->Partition[Index].OSIndicator =3D=3D PMBR_GPT_PARTIT= ION && UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) =3D=3D= 1 ) { break; } } if (Index =3D=3D MAX_MBR_PARTITIONS) { goto Done; } I'd also point out that that ATA-6 specification obsoleted CHS addressing = in 2002 and I think the 0x200 has to do with the sector size of 512 bytes, = which is also kind of an obsolete concept. So I'm not sure what the 0x100 i= s about in your example? Thanks, Andrew Fish On Apr 24, 2019, at 4:36 AM, Xu, Wei6 > wrote: Hi, I have a question about protective MBR. Thanks a lot for your time. Why is the StartingCHS of protective MBR partition record set to 0x000100 = in RedHat / Ubuntu? While UEFI spec defines it as 0x000200. Problem Statement: I met a problem when trying to use FatPei to fetch a file on the GPT parti= tion of RedHat/Ubuntu in TCB. FatPei has a check about Partition Record of protective MBR: StartingCHS s= hould to 0x000200. But I find the StartingCHS in both RedHat and Ubuntu is 0x000100, so that = the check fails. According to UEFI spec, StartingCHS should be 0x000200. --_000_FF72C7E4248F3C4E9BDF19D4918E90F24DEA208Eshsmsx102ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andrew:

   Tks for your explanation. The middle octet of StartingCHS (0x000200) is for Sector. Based on= CHS to LBA conversion rule. It should be 0x02.   I think it is a= n spec compliance issue.

Partition Dxe driver doesn’t apply such chec= k so there is no problem.  Partition Pei is in BIOS TCB, we applied stronger check and exposed this issue.

We need carefully document such limitation somewhe= re.

   BTW the whole GPT support in PEI= is new in Q1 stable tag,

 

&nb= sp;

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.Io
Sent: Thursday, April 25, 2019 12:07 AM
To: devel@edk2.groups.io; Xu, Wei6 <wei6.xu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>; Kinney, Michael D <m= ichael.d.kinney@intel.com>
Subject: Re: [edk2-devel] Question about the Protective MBR in RedH= at/Ubuntu

 

The intent of the protective MBR was to prevent too= ls that did not understand GPT to not think a GPT disk was blank. 20 years = ago that made a lot of sense, today it is kind of an obsolete concept.=

 

The protective MBR was never intended to identify t= he disk as GPT, but it seems it got used as a short cut to not have to read= a variable number of blocks from the disk to validate the GPT header. = ;

 

From a practical sense the DXE Partition driver use= s this algorithm to validate the Protective MBR. It would be a good idea fo= r the PEI code to do the same thing. 

 

 //

 // V= erify that the Protective MBR is valid

 //

 for<= /span> (Index =3D 0; Index < MAX_MBR_PARTITIONS; I= ndex++) {

    if (ProtectiveMbr->Partition[Index].BootIndicator =3D=3D 0x00 &&

     =    ProtectiveMbr->Partition[Inde= x].OSIndicator =3D=3D PMBR_GPT_PARTITION &= ;&

      = ;  UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) =3D=3D 1

     =    ) {

      = ;break;

    }

  }

 if (Index =3D=3D MAX_MBR_PARTITIONS) {

    goto Done;

  }

 

I'd also point out that that ATA-6 specification ob= soleted CHS addressing in 2002 and I think the 0x200 has to do with the sec= tor size of 512 bytes, which is also kind of an obsolete concept. So I'm no= t sure what the 0x100 is about in your example?

 

Thanks,

 

Andrew Fish



On Apr 24, 2019, at 4:36 AM, Xu, Wei6 <wei6.xu@intel.com> wrote:<= /p>

 

Hi,

 

I have a question about protective MBR. Thanks a l= ot for your time.

Why is the StartingCHS of protective MBR partition= record set to 0x000100 in RedHat / Ubuntu? While UEFI spec defines it as 0= x000200.

 

Problem Statement:

I met a problem when trying to use FatPei to fetch= a file on the GPT partition of RedHat/Ubuntu in TCB.

FatPei has a check about Partition Record of prote= ctive MBR: StartingCHS should to 0x000200.

But I find the StartingCHS in both RedHat and Ubun= tu is 0x000100, so that the check fails.

 

According to UEFI spec, StartingCHS should be 0x00= 0200.  

 

<image001.png>

 

--_000_FF72C7E4248F3C4E9BDF19D4918E90F24DEA208Eshsmsx102ccrcor_--