public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Gary Lin <glin@suse.com>
Cc: edk2-devel@lists.01.org, Ruiyu Ni <ruiyu.ni@intel.com>,
	Hao Wu <hao.a.wu@intel.com>, Star Zeng <star.zeng@intel.com>
Subject: Re: [PATCH] MdeModulePkg/UefiBootManagerLib: Match the nested partitions
Date: Wed, 16 Jan 2019 10:02:57 +0100	[thread overview]
Message-ID: <3e8fbef5-c21f-d763-f1a6-61d503bee2ee@redhat.com> (raw)
In-Reply-To: <20190116021601.GI3972@GaryWorkstation>

On 01/16/19 03:16, Gary Lin wrote:
> On Tue, Jan 15, 2019 at 12:58:10PM +0100, Laszlo Ersek wrote:
>> On 01/15/19 10:45, Gary Lin wrote:
>>> In some cases, such as MD RAID1 in Linux, the bootloader may be in a
>>> nested EFI system partition partition. For example, sda1 and sdb1 are
>>> combined as md0 and the first partition of md0, md0p1, is an EFI system
>>> partition. Then, the bootloader can be located by the following device
>>> paths:
>>>
>>> PCI()/SATA(sda)/Partition(sda1)/Partition(md0p1)/File(bootloader.efi)
>>> PCI()/SATA(sdb)/Partition(sdb1)/Partition(md0p1)/File(bootloader.efi)
>>
>> How does edk2 recognize the nested partition md0p1 in the first place?
>>
>> I would assume that the "outer" partitions (sda1, sdb1) start with some
>> kind of MD RAID1 header that allows Linux to combine sda1 and sdb1 into
>> md0p1. How does edk2 get past that header?
>>
>> Hmmm... based on
>> <https://raid.wiki.kernel.org/index.php/RAID_superblock_formats>, does
>> Linux use "footers" instead of "headers"?
>>
> See the "Sub-versions of the version-1 superblock" section:
> <https://raid.wiki.kernel.org/index.php/RAID_superblock_formats#Sub-versions_of_the_version-1_superblock>
> 
> For MD 0.9 and 1.0, the metadata is stored in the end of the disk, and
> those partitions, nested or not, are just like the normal partitions, so
> the firmare can see them without the knowledge of MD metadata. MD 1.1
> and 1.2 would be a different story because those two use "headers".
> 
> Anyway, I have tested RAID1 with MD 1.0 and OVMF actually appended md0p1
> in the device path. I only need to iterate the nested partitions in the
> match function to make my boot option work.

Thanks for the explanation! I'll let Ray review the change.
Laszlo

>>>
>>> To make the boot option more resilient, we may create a boot option with
>>> the short-form device path like "Partition(md0p1)/File(bootloader.efi)".
>>>
>>> However, BmMatchPartitionDevicePathNode() only matched the first
>>> partition node and ignored the nested partitions, so the firmware would
>>> refuse to load bootloader.efi since "Partition(md0p1)" doesn't match
>>> either "Partition(sda1)" or "Partition(sda2)".
>>>
>>> This commit modifies BmMatchPartitionDevicePathNode() to iterate all
>>> nested partitions so that the above boot option could work.
>>>
>>> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
>>> Cc: Star Zeng <star.zeng@intel.com>
>>> Cc: Jian J Wang <jian.j.wang@intel.com>
>>> Cc: Hao Wu <hao.a.wu@intel.com>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Gary Lin <glin@suse.com>
>>> ---
>>>  .../Library/UefiBootManagerLib/BmBoot.c       | 37 ++++++++++++-------
>>>  1 file changed, 23 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>>> index 6a23477eb873..8354c2af674b 100644
>>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>>> @@ -1995,21 +1995,30 @@ BmMatchPartitionDevicePathNode (
>>>      return FALSE;
>>>    }
>>>  
>>> -  //
>>> -  // See if the harddrive device path in blockio matches the orig Hard Drive Node
>>> -  //
>>> -  Node = (HARDDRIVE_DEVICE_PATH *) BlockIoDevicePath;
>>> +  do {
>>> +    //
>>> +    // See if the harddrive device path in blockio matches the orig Hard Drive Node
>>> +    //
>>> +    Node = (HARDDRIVE_DEVICE_PATH *) BlockIoDevicePath;
>>>  
>>> -  //
>>> -  // Match Signature and PartitionNumber.
>>> -  // Unused bytes in Signature are initiaized with zeros.
>>> -  //
>>> -  return (BOOLEAN) (
>>> -    (Node->PartitionNumber == HardDriveDevicePath->PartitionNumber) &&
>>> -    (Node->MBRType == HardDriveDevicePath->MBRType) &&
>>> -    (Node->SignatureType == HardDriveDevicePath->SignatureType) &&
>>> -    (CompareMem (Node->Signature, HardDriveDevicePath->Signature, sizeof (Node->Signature)) == 0)
>>> -    );
>>> +    //
>>> +    // Match Signature and PartitionNumber.
>>> +    // Unused bytes in Signature are initiaized with zeros.
>>> +    //
>>> +    if ((Node->PartitionNumber == HardDriveDevicePath->PartitionNumber) &&
>>> +        (Node->MBRType == HardDriveDevicePath->MBRType) &&
>>> +        (Node->SignatureType == HardDriveDevicePath->SignatureType) &&
>>> +        (CompareMem (Node->Signature, HardDriveDevicePath->Signature, sizeof (Node->Signature)) == 0)) {
>>> +      return TRUE;
>>> +    }
>>> +
>>> +    // See if a nested partition exists
>>> +    BlockIoDevicePath = NextDevicePathNode (BlockIoDevicePath);
>>> +  } while (!IsDevicePathEnd (BlockIoDevicePath) &&
>>> +           (DevicePathType (BlockIoDevicePath) == MEDIA_DEVICE_PATH) &&
>>> +           (DevicePathSubType (BlockIoDevicePath) == MEDIA_HARDDRIVE_DP));
>>> +
>>> +  return FALSE;
>>>  }
>>>  
>>>  /**
>>>
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>



  reply	other threads:[~2019-01-16  9:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15  9:45 [PATCH] MdeModulePkg/UefiBootManagerLib: Match the nested partitions Gary Lin
2019-01-15 11:58 ` Laszlo Ersek
2019-01-16  2:16   ` Gary Lin
2019-01-16  9:02     ` Laszlo Ersek [this message]
2019-01-22 16:01 ` Ni, Ray
2019-01-23  2:12   ` Gary Lin
2019-01-23  3:48     ` Ni, Ray
2019-01-23  3:49       ` Ni, Ray
2019-01-23  4:02         ` Gary Lin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3e8fbef5-c21f-d763-f1a6-61d503bee2ee@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox