Update BGRT image buffer to be stored in EfiBootSerivesData according to ACPI5.0 spec

Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14659 6f19259b-4bc3-4df7-8a09-765794883524
Add “VendorKeys” variable for indicating out of band key modification.
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Dong Guo <guo.dong@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14660 6f19259b-4bc3-4df7-8a09-765794883524
Update the chaining requirements with regards to the Platform Key.
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Dong Guo <guo.dong@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14661 6f19259b-4bc3-4df7-8a09-765794883524
Return EFI_WRITE_PROTECTED when setting KEKDefault, PKDefault, dbDefault, dbxDefault and dbtDefault variable.
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Dong Guo <guo.dong@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14662 6f19259b-4bc3-4df7-8a09-765794883524
Forcing the python27.dll to be executable

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14663 6f19259b-4bc3-4df7-8a09-765794883524
StdLib: Fix pointer arithmetic issues in the strncasecmp function.

The original Linux code tried to be too fancy so the internal pointers got out of sync.
Rewrote the function to at least be more clear.
Regardless, it now works properly.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel <daryl.mcdaniel@intel.com>
Reviewed by: matthew.stanbro@intel.com
Reviewed by: erik.c.bjorge@intel.com


git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14664 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: QemuBootOrder: expand relative device paths in UEFI boot options

The prefix matching logic in Match()
[OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options
to specify full (absolute) device paths. However, partial (relative)
device paths starting with a HD() node are valid for booting. By not
recognizing them, QemuBootOrder.c misses (and deletes) valid boot options
that would otherwise match the user's preference.

Just like BdsLibBootViaBootOption() expands such paths with the
BdsExpandPartitionPartialDevicePathToFull() function for booting, do the
same in QemuBootOrder.c for prefix matching.

This moves the very first call to
BdsExpandPartitionPartialDevicePathToFull() to an earlier point. The
following call tree explains it:

BdsEntry()                                          [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
  PlatformBdsPolicyBehavior()                       [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
    SetBootOrderFromQemu()                          [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c]
      Match()                                       [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c]
        BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
  BdsBootDeviceSelect()                             [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
    BdsLibBootViaBootOption()                       [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
      BdsExpandPartitionPartialDevicePathToFull()   [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]

This should be fine, for two reasons:

- the new, earlier call is still under BdsEntry(),

- BdsExpandPartitionPartialDevicePathToFull() expects to be called
  repeatedly, even with the same set of HD() device paths. This function
  implements its own caching for device paths, likely for performance
  reasons.

  That fits this patch well because whatever device paths we expand under
  PlatformBdsPolicyBehavior() can be quickly looked up in
  BdsBootDeviceSelect(), so no work (ie.
  BdsLibConnectAllDriversToAllControllers()) should be wasted.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OvmfPkg: QemuBootOrder: collect active UEFI boot options in advance

In preparation for the next patch, collect active UEFI boot options in
advance into a new array. Rebase the current inner loop (the matching
loop) to this array.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
[jordan.l.justen@intel.com: initialize *ActiveOption for GCC IA32 warning]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
OvmfPkg: QemuBootOrder: mark UEFI boot options selected by fw_cfg

This will allow us to identify those UEFI boot options (while keeping
their relative order) that have *not* been selected by fw_cfg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OvmfPkg: QemuBootOrder: keep some boot options that have not been selected

Some of the active boot options that have not been selected over fw_cfg
should be preserved at the end of the boot order. For now we're adding
back everything that starts with neither PciRoot() nor HD(). This includes
the UEFI shell, memory-mapped from the firmware image.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>