From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=wv9rRDh7; spf=pass (domain: apple.com, ip: 17.151.62.68, mailfrom: afish@apple.com) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) by groups.io with SMTP; Wed, 24 Apr 2019 09:07:28 -0700 Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x3OFua28058619; Wed, 24 Apr 2019 09:07:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=email.apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20190418; bh=0o3AOulURMbytM12OLj9iuykMw3mzCbvTaPOPKMp7ng=; b=XlBP/N+pmB/0cPEIadflE47roE+7FE/O0ocAN6/Atnr9URnUF98m3g81geSU3dLQ7kCU BPnOm/0sBjbkn74KUMv8MzIM6QM3S6vrMm3pG/MkOfdBda501AwQIJgRRRdTcNuHZfUj MvPYDZQOguV6ttwVeoyyu/vscfHFInGkjmzS9JW6eecf/v40+bFjnRbJFA0sNhXaEFNi XzHrpjC1skw7bsfFJOFNsY9PkjyFI/j1MlBPRl6tRqsOE2Rfipbid1WWeuA4cCjMcCcm 9oDoNXm48+tGFw9X5vHkvp3oFjZWnfrf/sjOrwY3QS3T5VHuP/Jtj7gVqaA2SWwc54j2 Wg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=0o3AOulURMbytM12OLj9iuykMw3mzCbvTaPOPKMp7ng=; b=wv9rRDh7rFr6Xamy+pO8lojo9S8pJW+Xl2iIm9PAfEs2Dci0Ln7nx+rVsNv0yaJ/oxTb GYxxZ0k8j1VhVpzfWW/C8kmaiSI6Dvr+el5hytsRfxsIv0LUuYyfhsTjqXwsG5vWp2eW 7Wsz28tfOl82ypOcEgdvDknrn2nYPAJxokOtq3VNBZpyGbEQ7rSmUWP8DlmrhEZRubz5 Bfly+fU/PqHHCyUki0c/JIr+e9ZHdgP2UKN+8aEsxmHgUo1eynDf/c2oehU0a4UWFI6x KSAIezpw0PmRjiYZCrVcLmwGzHRFN/9FmhpryL07kqn5I81DZg+K5YDu3S2Yu2kfBLPy ug== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2ryyy82ykd-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Apr 2019 09:07:27 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PQH00HHN3G9WV50@ma1-mtap-s02.corp.apple.com>; Wed, 24 Apr 2019 09:07:26 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PQH00F0036GKF00@nwk-mmpp-sz12.apple.com>; Wed, 24 Apr 2019 09:07:22 -0700 (PDT) X-Va-A: X-Va-T-CD: 89fcc3047dd5193a82cac128271a2413 X-Va-E-CD: ca1c8f71d4f711298a413bd10a640c50 X-Va-R-CD: 7ec4ffe94e49a7ec4e2ecfb2b1e1ebba X-Va-CD: 0 X-Va-ID: 1de836ad-dfc4-4bad-bdd4-c146f6fcccf9 X-V-A: X-V-T-CD: 89fcc3047dd5193a82cac128271a2413 X-V-E-CD: ca1c8f71d4f711298a413bd10a640c50 X-V-R-CD: 7ec4ffe94e49a7ec4e2ecfb2b1e1ebba X-V-CD: 0 X-V-ID: 87dcdb5e-e69e-4a35-a155-7f02709a3662 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-24_10:,, signatures=0 Received: from [17.226.41.80] (unknown [17.226.41.80]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PQH006VI3G9HR20@nwk-mmpp-sz12.apple.com>; Wed, 24 Apr 2019 09:07:22 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <2F4FB4C7-8C2F-4B16-B89B-A4FE72BD5318@apple.com> Subject: Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu Date: Wed, 24 Apr 2019 09:07:19 -0700 In-reply-to: <59B8EAB3797CDB4091332F0685A110ED50D6B722@SHSMSX104.ccr.corp.intel.com> Cc: Laszlo Ersek , Mike Kinney To: devel@edk2.groups.io, wei6.xu@intel.com References: <59B8EAB3797CDB4091332F0685A110ED50D6B722@SHSMSX104.ccr.corp.intel.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-24_10:,, signatures=0 Content-type: multipart/alternative; boundary="Boundary_(ID_7wF0mdoJse7t/CoU0OKBlA)" --Boundary_(ID_7wF0mdoJse7t/CoU0OKBlA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT The intent of the protective MBR was to prevent tools 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 the 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 uses this algorithm to validate the Protective MBR. It would be a good idea for the PEI code to do the same thing. https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c // // Verify that the Protective MBR is valid // for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) { if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 && ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION && UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1 ) { break; } } if (Index == 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 is 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 partition of RedHat/Ubuntu in TCB. > FatPei has a check about Partition Record of protective MBR: StartingCHS should 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. > > > --Boundary_(ID_7wF0mdoJse7t/CoU0OKBlA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
The in= tent of the protective MBR was to prevent tools 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 practica= l sense the DXE Partition driver uses this algorithm to validate the Protec= tive MBR. It would be a good idea for the PEI code to do the same thing.&nb= sp;

https://github.com/tianocore/edk2/blob/master/M= deModulePkg/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= _PARTITION && UNPACK_UINT32= (ProtectiveMbr->StartingLBA) =3D=3D 1 ) {<= /td> break; } = } if (Index =3D=3D MAX_MBR_PARTITIONS) { goto Done;= }
I'd also point out that that ATA-6 specification obsoleted CHS addr= essing 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 is about in your example?

T= hanks,

Andrew Fish

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

Hi,
 <= /o:p>
I have a question about protective M= BR. Thanks a lot for your time.
Why is the StartingCHS of protective MBR partition record set t= o 0x000100 in RedHat / Ubuntu? While UEFI spec defines it as 0x000200.
 
Problem Statement:
I met a problem when trying to use Fat= Pei to fetch a file on the GPT partition of RedHat/Ubuntu in TCB.
FatPei has a check about Par= tition Record of protective MBR: StartingCHS should to 0x000200.
But I find the StartingCHS i= n both RedHat and Ubuntu is 0x000100, so that the check fails.
 
According to UEFI spec, StartingCHS should be= 0x000200.  
 
<image001.png>

--Boundary_(ID_7wF0mdoJse7t/CoU0OKBlA)--