[edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[wei6.xu]

[-- Attachment #1.1: Type: text/plain, Size: 623 bytes --]

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.

[cid:image001.png@01D4FACC.71570DF0]

[-- Attachment #1.2: Type: text/html, Size: 3124 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 78036 bytes --]

Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

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 <wei6.xu@intel.com> 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.  
>  
> <image001.png>
> 


[-- Attachment #2: Type: text/html, Size: 18878 bytes --]

Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[chao.b.zhang]

[-- Attachment #1: Type: text/plain, Size: 2958 bytes --]

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't apply such check 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 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 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 <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 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 <wei6.xu@intel.com<mailto:wei6.xu@intel.com>> 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.

<image001.png>



[-- Attachment #2: Type: text/html, Size: 20437 bytes --]

Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 4112 bytes --]



> On Apr 24, 2019, 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’t apply such check 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 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 standard in terms of what has been tested. Thus using the same test as the PartitionDxe driver will give you maximum compatibility. 

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 corrupted has no impact on being able to mount the GPT partitions 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 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. 

Thanks,

Andrew Fish

>   <>
>  <>From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> [mailto: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 <mailto:devel@edk2.groups.io>; Xu, Wei6 <wei6.xu@intel.com <mailto:wei6.xu@intel.com>>
> Cc: Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>; Kinney, Michael D <michael.d.kinney@intel.com <mailto: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 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 <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 <wei6.xu@intel.com <mailto:wei6.xu@intel.com>> 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.
>
> <image001.png>
>
> 


[-- Attachment #2: Type: text/html, Size: 28758 bytes --]

Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[Laszlo Ersek]

On 04/24/19 13:36, 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.
> 
> [cid:image001.png@01D4FACC.71570DF0]
> 

Anaconda (the RHEL & Fedora installer) uses GNU Parted for creating GPT
partitions. This utility creates the protective MBR as well.

GNU Parted used to have a bug in setting the sector in "StartingCHS" --
in C/H/S, sectors are 1-based, not 0-based.

The problem was fixed in upstream parted commit df6770d213b6
("libparted: Fix starting CHS in protective MBR", 2016-12-22):

  http://git.savannah.gnu.org/cgit/parted.git/commit/?id=df6770d213b6

As far as I can determine, this fix has been included in Fedora 27 and
later. (The oldest supported Fedora release at this point is Fedora 28,
so I think we can consider "Fedora" fixed.) The fix is also included in
RHEL-8.0.

RHEL-7.7 however lacks the fix (as of build "parted-3.1-31.el7"). I've
now filed a Red Hat Bugzilla for you:

  https://bugzilla.redhat.com/show_bug.cgi?id=1702778

Please register in the Red Hat Bugzilla instance, subscribe to the bug,
and assist with testing the fix, if the BZ assignee requests that.

Thank you for reporting this issue,
Laszlo