Zhang, Shenglei [Wed, 20 May 2020 03:08:47 +0000 (11:08 +0800)]
NetworkPkg/DxeNetLib: Change the order of conditions in IF statement
The condition, NET_HEADSPACE(&(Nbuf->BlockOp[Index])) < Len, is
meaningless if Index = 0. So checking 'Index != 0' should be
performed first in the if statement.
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Laszlo Ersek [Fri, 8 May 2020 12:16:51 +0000 (14:16 +0200)]
OvmfPkg/PlatformPei: increase memory type info defaults
Any new OVMF binary (containing commit d42fdd6f8384, and built with
SMM_REQUIRE) is likely to reboot during its first boot, regardless of
whether the variable store is logically empty, or it contains a
MemoryTypeInformation variable from an earlier OVMF binary.
This "reboot on first boot after OVMF upgrade" occurs despite having
eliminated BS Code/Data tracking in earlier parts of this series. Meaning
that we've outgrown the bins of those memory types too that matter for SMM
security.
Eliminating said reboot will make an upgrade to edk2-stable202005 more
comfortable for users. Increase the defaults empirically. (The total
doesn't exceed 3MB by much.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Laszlo Ersek [Fri, 8 May 2020 12:16:50 +0000 (14:16 +0200)]
OvmfPkg/PlatformPei: extract memory type info defaults to PCDs
Some OvmfPkg modules already depend on "EmbeddedPkg.dec"; thus, replace
the open-coded memory type info defaults in the source code with the
EmbeddedPkg PCDs that stand for the same purpose. Consequently, platform
builders can override these values with the "--pcd" option of "build",
without source code updates.
While at it, sort the memory type names alphabetically.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Laszlo Ersek [Fri, 8 May 2020 12:16:49 +0000 (14:16 +0200)]
OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logic
The previous patch has no effect -- i.e., it cannot stop the tracking of
BS Code/Data in MemTypeInfo -- if the virtual machine already has a
MemoryTypeInformation UEFI variable.
In that case, our current logic allows the DXE IPL PEIM to translate the
UEFI variable to the HOB, and that translation is verbatim. If the
variable already contains records for BS Code/Data, the issues listed in
the previous patch persist for the virtual machine.
For this reason, *always* install PlatformPei's own MemTypeInfo HOB. This
prevents the DXE IPL PEIM's variable-to-HOB translation.
In PlatformPei, consume the records in the MemoryTypeInformation UEFI
variable as hints:
- Ignore all memory types for which we wouldn't by default install records
in the HOB. This hides BS Code/Data from any existent
MemoryTypeInformation variable.
- For the memory types that our defaults cover, enable the records in the
UEFI variable to increase (and *only* to increase) the page counts.
This lets the MemoryTypeInformation UEFI variable function as designed,
but it eliminates a reboot when such a new OVMF binary is deployed (a)
that has higher memory consumption than tracked by the virtual machine's
UEFI variable previously, *but* (b) whose defaults also reflect those
higher page counts.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Laszlo Ersek [Fri, 8 May 2020 12:16:48 +0000 (14:16 +0200)]
OvmfPkg/PlatformPei: don't track BS Code/Data in default MemTypeInfo HOB
In commit d42fdd6f8384 ("OvmfPkg: improve SMM comms security with adaptive
MemoryTypeInformation", 2020-03-12), we enabled the boot-to-boot tracking
of the usages of various UEFI memory types.
Both whitepapers listed in that commit recommend that BS Code/Data type
memory *not* be tracked. This recommendation was confirmed by Jiewen in
the following two messages as well:
While tracking BS Code/Data type memory has one benefit (it de-fragments
the UEFI memory map), the downsides outweigh it. Spikes in BS Data type
memory usage are not uncommon in particular, and they may have the
following consequences:
- such reboots during normal boot that look "spurious" to the end user,
and have no SMM security benefit,
- a large BS Data record in MemoryTypeInformation may cause issues when
the DXE Core tries to prime the according bin(s), but the system's RAM
size has been reduced meanwhile.
Removing the BS Code/Data entries from MemoryTypeInformation leads to a
bit more fragmentation in the UEFI memory map, but that should be
harmless.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Intel SDM introduces 6-levels for describing the CPU topology:
* Package
* Module
* Tile
* Die
* Core
* Thread
A PI spec ECR was submitted to enhance CPU_MP PPI/Protocol to
support returning such information through GetProcessorInfo().
An accordingly change was implemented and pushed to edk2-staging.
Now the PI spec has been published.
The patch is cherry-picked from edk2-staging to edk2.
Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Robert Phelps [Mon, 11 May 2020 20:24:13 +0000 (04:24 +0800)]
MdePkg: Update structures for MpServices Protocol
Added EXTENDED_PROCESSOR_INFORMATION structure and supporting
structures and definitions. The intent is to support updated
topology layout for CPUs. (PI 1.7a Mantis 2071)
Signed-off-by: Robert Phelps <robert@ami.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
The binary is totally changed, so update the Crypto Version to 7:
1. Retire below deprecated function:
MD4, ARC4, TDES, AES ECB MODE, HMAC MD5, HMAC SHA1
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Convert file ending of the crypto created openssl config file -
opensslconf.h from '\n' to '\r\n' to make align the line ending and
pass the patch check.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
HMAC SHA1 is not secure any longer.
Remove the HMAC SHA1 support from edk2.
Change the HMAC SHA1 field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
HMAC MD5 is not secure any longer.
Remove the HMAC MD5 support from edk2.
Change the HMAC MD5 field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Add the unrequired aes_ecb files in process_files.pl and run it
thru perl.
It would remove the unrequired aes_ecb files from OpensslLib inf.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Aes Ecb mode is not secure any longer.
Remove the Aes Ecb mode support from edk2.
Change the Aes Ecb mode field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
This patch is create by adding the setting "no_des" of
process_files.pl and running it thru perl.
It would remove the TDES from OpensslLib.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
TDES is not secure any longer.
Remove the Tdes support from edk2.
Change the Tdes field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
This patch is create by adding the setting "no_rc4" of
process_files.pl and running it thru perl.
It would remove the ARC4 from OpensslLib.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
ARC4 is not secure any longer.
Remove the ARC4 support from edk2.
Change the ARC4 field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
This patch is create by adding the setting "no_md4" of
process_files.pl and running it thru perl.
It would remove the MD4 from OpensslLib.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
MD4 is not secure any longer.
Remove the MD4 support from edk2.
Change the MD4 field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Add a internal worker function to indicate the deprecated functions.
It would print out debug messages and asserts to inform the consumer
they are using a deprecated function.
Change the Name of BaseCryptLibServciceNotEnabled to correct spelling
BaseCryptLibServiceNotEnabled.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Remove the orginal Fmp Capsule Dependency implement, and use new
FmpDependencyLib, FmpDependencyCheckLib and FmpDependencyDeviceLib
APIs instead.
A platform can perform the dependency check in a platform specific
manner by implementing its own FmpDependencyCheckLib.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* This library class provides platform specific services to support
dependency check during updating firmware image. Platform can perform
dependency check in platform specific manner by implementing its own
FmpDependencyCheckLib.
* Add FmpDependencyCheck instance to provide a sample of dependency
check. The sample instance only checks the dependency from capsule
image. The dependency from other FMP instances isn't checked here.
* Add NULL instance as an option to skip the dependency check.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* Add unit tests for EvaluateDependency API in FmpDependencyLib.
* Add Test/FmpDeviceHostPkgTest.dsc to build host based unit test.
* Update FmpDevicePkg.dsc to build target based unit test.
* Update FmpDevicePkg.ci.yaml to build and run host based test.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Oleksiy Yakovlev [Wed, 13 May 2020 19:52:46 +0000 (03:52 +0800)]
MdePkg: Bootable NVDIMM namespaces
Provided a mechanism for UEFI FW to identify and hand off bootable
NVDIMM namespaces to the OS by standardizing the EFI device path.
EFI device path for physical NVDIMM devices changed from an ACPI
_ADR device to an ACPI NVDIMM device for correctness.
(UEFI 2.8 mantis 1858)
Oleksiy Yakovlev [Wed, 13 May 2020 19:52:45 +0000 (03:52 +0800)]
BaseTools: Bootable NVDIMM namespaces
Provided a mechanism for UEFI FW to identify and hand off bootable
NVDIMM namespaces to the OS by standardizing the EFI device path.
EFI device path for physical NVDIMM devices changed from an ACPI
_ADR device to an ACPI NVDIMM device for correctness.
(UEFI 2.8 mantis 1858)
The assert comes from InitializeHiiPackage() after an attempt to
retrieve HII package list from ImageHandle.
Xcode still doesn't support HII resource section and
LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d93a
("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"),
disable initrd command if built with Xcode toolchain
Fixes: ec41733cfd10 ("OvmfPkg: add the 'initrd' dynamic shell command") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Shenglei Zhang [Sat, 9 May 2020 06:33:36 +0000 (14:33 +0800)]
MdeModulePkg/RegularExpressionDxe: Optimize the code infrastructure
OnigurumaIntrinsics.c is now not used. So the implement of function
'memcpy' is now not., which causes build failure with CLANG9 and
XCODE. I remove OnigurumaIntrinsics.c and move the necessary function
implement to OnigurumaUefiPort.c/h.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
To enhance FSP silicon initialization flexibility an optional
Multi-Phase API is introduced and FSP header needs update for
new API offset. Also new SecCore module created for
FspMultiPhaseSiInit API
New ARCH_UPD introduced for enhancing FSP debug message
flexibility now bootloader can pass its own debug handler
function pointer and FSP will call the function to handle
debug message.
To support calling bootloader functions, a FspGlobalData field
added to indicate if FSP needs to switch stack when FSP running
on separate stack from bootloader.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
StandaloneMmPkg: switch to MM communicate 2 protocol
Update the reference to MM communicate to refer to the MM communicate 2
protocol instead. This makes no difference for the MM side of the
implementation, but is more accurate nonetheless, since the original MM
protocol does not work in combination with standalone MM.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg/MmCommunicationDxe: expose MM Communicate 2 protocol
Implement the new MmCommunication2 protocol which supports the use
of standalone MM at runtime inside an address space that has been
virtually remapped by the OS.
Note that the implementation of the old MM Communicate protocol is
removed: it never worked correctly so there is no point in keeping it.
MdeModulePkg/SmmIpl: expose MM communicate 2 protocol
The MM communicate 2 protocol was introduced to factor out the mismatch
between traditional MM, which requires the physical address of the MM
buffer to be passed, and standalone MM, which copies the MM communicate
buffer data into a separate buffer, requiring the virtual address. For
this reason, MM communicate 2 carries both addresses, allowing the
implementation to decide which address it needs.
This hides this implementation detail from the callers of the protocol,
which simply passes both addresses without having to reason about what the
implementation of the protocol actually needs.
Note that the old version of the protocol is retained, in order to support
existing implementations that don't require this flexibility.
Now that an XCODE5 specific CpuExceptionHandlerLib library is in place,
revert the changes made to the ExceptionHandlerAsm.nasm in commit 2db0ccc2d7fe ("UefiCpuPkg: Update CpuExceptionHandlerLib pass XCODE5 tool
chain") so that binary patching of flash code is not performed.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Acked-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <810f67d8604c054c09d17a22f0bcfaeb41ee8e3b.1588856809.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
During the SEC phase, use the XCODE5 CpuExceptionHandlerLib library in
place of the standard library when building with the XCODE5 toolchain.
The SEC XCODE5 version of the library performs binary patching and should
only be used when building with the XCODE5 toolchain.
Commit 2db0ccc2d7fe ("UefiCpuPkg: Update CpuExceptionHandlerLib pass
XCODE5 tool chain") introduced binary patching into the exception handling
support. CPU exception handling is allowed during SEC and this results in
binary patching of flash, which should not be done.
Separate the changes from commit 2db0ccc2d7fe into an XCODE5 toolchain
specific file, Xcode5ExceptionHandlerAsm.nasm, and create a new SEC INF
file for the XCODE5 version of CpuExceptionHandlerLib.
Since binary patching is allowed when running outside of flash, switch
the Dxe, Pei and Smm versions of the CpuExceptionHandlerLib over to use
the Xcode5ExceptionHandlerAsm.nasm file to retain current functionality.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <9075570487616c731033a5738f6a444a15d71b74.1588856809.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Rebecca Cran [Fri, 1 May 2020 20:00:44 +0000 (04:00 +0800)]
BaseTools: add repo name option to SetupGit.py
Allow users who didn't clone one of the TianoCore repos from a
canonical URL to specify the name of the repo (edk2, edk2-platforms
or edk2-non-osi) when running SetupGit.py to allow them to configure
their repo properly.
The new option is:
-n repo, --name repo set the repo name to configure for, if not
detected automatically
Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Krzysztof Koch [Wed, 25 Mar 2020 09:39:24 +0000 (17:39 +0800)]
ShellPkg: acpiview: Check if SBBR mandatory ACPI tables are installed
For Arm-based platforms, count the instances of installed tables for
each ACPI table listed as 'mandatory' in any Server Base Boot
Requirements (SBBR) specification.
Validate that the all the mandatory SBBR tables present. Report an error
for each missing table.
This new feature is optional and can be enabled with the -r command line
parameter.
Reference(s):
- Arm Server Base Boot Requirements 1.2, September 2019
- Arm Server Base Boot Requirements 1.1, May 2018
- Arm Server Base Boot Requirements 1.0, March 2016
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Krzysztof Koch [Wed, 25 Mar 2020 09:39:23 +0000 (17:39 +0800)]
ShellPkg: acpiview: Add library for SBBR ACPI requirements validation
For Arm-based platforms, define and implement an interface for Server
Base Boot Requirements (SBBR) compliance checks. The library is
responsible for validating that all mandatory ACPI tables are installed
on the platform.
Internally, the library maintains a data structure which tracks
instance counts for ACPI tables which are labeled as 'mandatory' in any
SBBR specification version. The provided interface allows:
- resetting all instance counts to 0
- incremementing the instance count for a table with a given signature
- validating the instance counts against the requirements in SBBR
The ACPI table requirements for each SBBR spec version are represented
internally as a list of table signatures.
Every missing mandatory table (for the input SBBR version) is reported
to the user as a separate error. If all requirements are met, an info
message is displayed.
Reference(s):
- Arm Server Base Boot Requirements 1.2, September 2019
- Arm Server Base Boot Requirements 1.1, May 2018
- Arm Server Base Boot Requirements 1.0, March 2016
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Krzysztof Koch [Wed, 25 Mar 2020 09:39:22 +0000 (17:39 +0800)]
ShellPkg: acpiview: Add -r parameter for table requirements validation
Define a new command line parameter '-r' to enable checking if all
mandatory ACPI tables listed in a specification are present.
The -r parameter takes an integer value to specify which specification
the validation should be performed against.
The parameter is used to set two Acpiview variables. An interface to
access these variables is implemented in this patch.
The new functionality is aimed at Arm-based platforms, however,
there are no restriction on extending it to other architectures.
For the 32-bit and 64-bit Arm architectures, the possible values for
the -r parameter are:
0: Arm Server Base Boot Requirements 1.0, March 2016
1: Arm Server Base Boot Requirements 1.1, May 2018
2: Arm Server Base Boot Requirements 1.2, September 2019
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Microsoft signtool supports creation of attached P7's with any OID payload
via the "/p7co" parameter. It is necessary to check the data before get
the string.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Zero the allocated buffer in case GetImageInfo `continue` in the middle of
a loop. This will cause unexpected GetImageInfo failure not clearing the
corresponding entry and lead to GP faults when dereferencing this entry.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
This patch fixes a file permission issue introduced by accident.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Eric Dong <eric.dong@intel.com>
Nikita Leshenko [Mon, 4 May 2020 21:06:07 +0000 (00:06 +0300)]
OvmfPkg/MptScsiDxe: Reset device on ExitBootServices()
This causes the device to forget about the reply frame. We allocated the
reply frame in EfiBootServicesData type memory, and code executing after
ExitBootServices() is permitted to overwrite it.
Nikita Leshenko [Mon, 4 May 2020 21:06:06 +0000 (00:06 +0300)]
OvmfPkg/MptScsiDxe: Implement the PassThru method
Machines should be able to boot after this commit. Tested with different
Linux distributions (Ubuntu, CentOS) and different Windows
versions (Windows 7, Windows 10, Server 2016).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-12-nikita.leshchenko@oracle.com>
[lersek@redhat.com: MPT_SCSI_DMA_ADDR_HIGH: drop redundant space char]
Nikita Leshenko [Mon, 4 May 2020 21:06:05 +0000 (00:06 +0300)]
OvmfPkg/MptScsiDxe: Initialize hardware
Reset and send the IO controller initialization request. The reply is
read back to complete the doorbell function but it isn't useful to us
because it doesn't contain relevant data or status codes.
See "LSI53C1030 PCI-X to Dual Channel Ultra320 SCSI Multifunction
Controller" technical manual for more information.
Nikita Leshenko [Mon, 4 May 2020 21:06:01 +0000 (00:06 +0300)]
OvmfPkg/MptScsiDxe: Report targets and one LUN
The controller supports up to 8 targets in practice (Not reported by the
controller, but based on the implementation of the virtual device),
report them in GetNextTarget and GetNextTargetLun. The firmware will
then try to communicate with them and create a block device for each one
that responds.
Support for multiple LUNs will be implemented in another series.
Nikita Leshenko [Mon, 4 May 2020 21:05:59 +0000 (00:05 +0300)]
OvmfPkg/MptScsiDxe: Probe PCI devices and look for MptScsi
The MptScsiControllerSupported function is called on handles passed in
by the ConnectController() boot service and if the handle is the
lsi53c1030 controller the function would return success. A successful
return value will attach our driver to the device.
The PL180 SD host controller driver is only used on emulated ARM
platforms, uses an obsolete version of the MMC host protocol and
does not adhere to the UEFI driver model.
It has been moved into edk2-platforms alongside the only platforms
that use it, so we can drop it from the EDK2 core repository.
EmbeddedPkg: remove ISP 1716 USB host controller driver
The ISP 1716 USB host controller driver does not implement the UEFI
driver model, and is not a suitable example for new drivers to be
based on. Also, it is currently only used on a limited set of ARM
development platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
EmbeddedPkg: remove SiI3132 SATA controller driver
The SiI3132 SATA controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
The Lan9118 network controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
The Lan91x network controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
The Synopsys DesignWare eMMC host controller driver does not implement
that SD/MMC host controller protocol that the UEFI spec defines, but an
obsolete EDK2-specific one that predates it. It also does not implement
the UEFI driver model.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
On bhyve, the ACPI timer is located at a fixed IO address; it need
not be programmed into, nor fetched from, the PMBA -- power
management base address -- register of the PCI host bridge.
projects / mirror_edk2.git / log