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=JxlHDneD; spf=pass (domain: apple.com, ip: 17.171.2.60, mailfrom: afish@apple.com) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) by groups.io with SMTP; Wed, 24 Apr 2019 18:59:26 -0700 Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x3P1pXiH009096; Wed, 24 Apr 2019 18:59:25 -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=CEQ8QlfH+YULgSi/RoyCS7M8+lrnVCgpBQ8NW+zPaMg=; b=kYjIbGtAGpzLGTuEklU3TwKhb6JL9upz+ixcG8L4RskUDpAzVYXzbCjvSRZuPZAoJB0I 76Oegsfbt1vrT/IBsffjD6dRh62Q20RpuEYN1upcynZTQecLQ+pfQlEEQtcDuh2TtySo tHbO0GZPXWyahv99Vft7foIIgbPFj8RJYcN1yZWzyxcPQnpcxKBmQ+4zGeGHmcU0BtEB Ffk5SPNd3rlhVEcQ2ZKJR5lFmJ+9KC5BTpKASVsMuFIPMofgYYjJhpPkH746VSIC1PJO phQPdQ8f3qGOc/JMKT+BfHImczGEW3df29YSbiQ1U6l9zk77UJQcl88XQUnQtnv+fz+G gA== 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=CEQ8QlfH+YULgSi/RoyCS7M8+lrnVCgpBQ8NW+zPaMg=; b=JxlHDneD+Vtu6kmnNNgxmDGjrp2kJ0OC0AB3Da1tVs2wto2wGviYoROnU7QyHFqNHmyC yPNQBKqxsO8ZQgZrPTfgntcn1H99oJzCQDNtmbPf4IqBNTSwB7prmBOHQIv+5gAEz4I5 GxxIrJLT8giD9ZD+mBBOinwZS11BeraWqzOEC0Xh8ueECcGwzCB6CMzMQ099sFqSYbnN pPERdwk9Tye5xytkpM4CZMx+zLOYOtzA3tqTyQrLFmJQSAIIxjaYA7OhXL4i1VM/A4te SmcW6N+RrwZFuAOcBPbmftZAJQLOHGhL/CbgPnN70NkNU64VSFIO++NiVDS0nxCZHE0a cQ== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2s1sk1hnyt-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Apr 2019 18:59:25 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PQH00GMTUV1W2A0@mr2-mtap-s02.rno.apple.com>; Wed, 24 Apr 2019 18:59:25 -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 <0PQH00100U7GLI00@nwk-mmpp-sz12.apple.com>; Wed, 24 Apr 2019 18:59:25 -0700 (PDT) X-Va-A: X-Va-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-Va-E-CD: ca1c8f71d4f711298a413bd10a640c50 X-Va-R-CD: 7ec4ffe94e49a7ec4e2ecfb2b1e1ebba X-Va-CD: 0 X-Va-ID: 5bb93170-0414-474d-8d11-963de3f1c81f X-V-A: X-V-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-V-E-CD: ca1c8f71d4f711298a413bd10a640c50 X-V-R-CD: 7ec4ffe94e49a7ec4e2ecfb2b1e1ebba X-V-CD: 0 X-V-ID: 1012d00e-fb16-431a-a5d5-fde7e3a951e2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-25_02:,, signatures=0 Received: from [17.234.93.249] (unknown [17.234.93.249]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PQH00NJBUUZ0M80@nwk-mmpp-sz12.apple.com>; Wed, 24 Apr 2019 18:59:24 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <5085CD9E-05F5-4B76-8643-DB6079361816@apple.com> Subject: Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu Date: Wed, 24 Apr 2019 18:59:20 -0700 In-reply-to: Cc: "devel@edk2.groups.io" , "Xu, Wei6" , Laszlo Ersek , Mike Kinney To: "Zhang, Chao B" References: <59B8EAB3797CDB4091332F0685A110ED50D6B722@SHSMSX104.ccr.corp.intel.com> <2F4FB4C7-8C2F-4B16-B89B-A4FE72BD5318@apple.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-25_02:,, signatures=0 Content-type: multipart/alternative; boundary="Boundary_(ID_RbvpsErivVIxK93C2yGHMg)" --Boundary_(ID_RbvpsErivVIxK93C2yGHMg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Apr 24, 2019, at 6:40 PM, Zhang, Chao B wrot= e: >=20 > 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 an spec compliance issue. > Partition Dxe driver doesn=E2=80=99t apply such check so there is no pro= blem. Partition 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, > My bigger point is what PartitionDxe driver does is likely the defacto sta= ndard in terms of what has been tested. Thus using the same test as the Par= titionDxe driver will give you maximum compatibility.=20 Given this is the recovery path for your ROM I think you would want it to = be as reliable as possible. I would posit the protective MBR being corrupte= d has no impact on being able to mount the GPT partitions on the disk as th= us does not have a lot of value in the PEI path. If the GPT is valid you sh= ould mount it. Don't get me wrong I'm all for spec conformance and I wrote = that part of the spec, but as a customer I'd much rather that the Firmware = update actually complete if at all possible.=20 Thanks, Andrew Fish > =C2=A0 <> > <>From: devel@edk2.groups.io [mailto:deve= l@edk2.groups.io ] On Behalf Of Andrew Fish vi= a 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/Ub= untu > > The intent of the protective MBR was to prevent tools that did not under= stand GPT to not think a GPT disk was blank. 20 years ago that made a lot o= f sense, today it is kind of an obsolete concept. > > The protective MBR was never intended to identify the disk as GPT, but i= t 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.=20 > > From a practical sense the DXE Partition driver uses this algorithm to v= alidate the Protective MBR. It would be a good idea for the PEI code to do = the same thing.=20 > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Dis= k/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_PART= ITION && > 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 addressin= g 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 >=20 >=20 > 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 0x00010= 0 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 par= tition 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 tha= t the check fails. > > According to UEFI spec, StartingCHS should be 0x000200. > > > >=20 --Boundary_(ID_RbvpsErivVIxK93C2yGHMg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Apr 24, 2= 019, at 6:40 PM, Zhang, Chao B <chao.b.zhang@intel.com> wrote:

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 an spec compliance issue.
Partition Dxe driver doesn=E2=80=99t = apply such check so there is no problem.  Partition Pei is in BIOS TCB= , we applied stron= ger check and exposed this issue.
We need carefully document such limi= tation somewhere.
   BTW the whole GPT support in PEI i= s new in Q1 stable tag,
 = ;

My bigger point is what PartitionDxe driver does is likely the defacto sta= ndard in terms of what has been tested. Thus using the same test as the Par= titionDxe driver will give you maximum compatibility. 

Given this is the recovery path for your ROM I think y= ou would want it to be as reliable as possible. I would posit the protectiv= e MBR being corrupted has no impact on being able to mount the GPT partitio= ns on the disk as thus does not have a lot of value in the PEI path. If the= GPT is valid you should mount it. Don't get me wrong I'm all for spec conf= ormance and I wrote that part of the spec, but as a customer I'd much rathe= r that the Firmware update actually complete if at all possible. 

Thanks,

Andrew Fish

 
From: = devel@edk2.groups.io = [mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.IoSent:&n= bsp;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 <michael.d.kinney@intel.com>
Subject: Re: [= edk2-devel] Question about the Protective MBR in RedHat/Ubuntu
 
The intent of the protective MBR was to prevent tools t= hat 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 ha= ve to read a variable number of blocks from the disk to validate the GPT he= ader. 
 
From a practical sense= the DXE Partition driver uses this algorithm to validate the Protective MB= R. 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
= = <= /tr><= tr style=3D"box-sizing: border-box;" class=3D""><= td width=3D"50" nowrap=3D"" valign=3D"top" id=3D"L274" style=3D"width: 37.5= pt; padding: 0cm 7.5pt; box-sizing: border-box; -webkit-user-select: none; = color: rgba(27, 31, 35, 0.298039); cursor: pointer; min-width: 50px;" class= = =3D"">
  }
=
 //
<= /td>
 // Verify that the Protective MBR is vali= d
 //
&= nbsp;for (Index =3D 0; Index < MAX_MBR_PARTITIONS;= Index++) {
    if (ProtectiveMbr->Partition= [Index].BootIndicator =3D=3D 0x00 &&= amp;
        Protective= Mbr->Partition[Index].OSIndicator =3D= = =3D PMBR_GPT_PARTITION &&
    &nb= sp;   UNPACK_UIN= T32 = ;(ProtectiveMbr->Partition[Index].<= span class=3D"pl-smi">StartingLBA) =3D=3D 1
     &nb= sp;  ) {
      break;
    }
  }
&= nbsp;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?
 
Thanks,
 
Andrew Fish


On Apr 24, 2019, at 4:36 AM, Xu, Wei6 <wei6.xu@intel.com> wrote:
 
=
= Hi,
 
I ha= ve a question about protective MBR. Thanks a lot for your time.
Why is the StartingCHS of protective MBR partition recor= d set to 0x000100 in RedHat / Ubuntu? While UEFI spec defines it as 0x00020= 0.
 
Problem Sta= tement:
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 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 fa= ils.
 
Accordi= ng to UEFI spec, StartingCHS should be 0x000200.  
 
<image001.png>
 
=
--Boundary_(ID_RbvpsErivVIxK93C2yGHMg)--