summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* MdePkg/Test: Add SafeIntLib and BaseLib Base64 unit testsMichael D Kinney2020-02-0716-3/+5034
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2505 * Add unit tests for SafeIntLib class * Add unit tests for BaseLib Base64 conversion APIs. * Add Test/MdePkgHostTest.dsc -to build host based unit tests * Update MdePkg.dsc to build target based tests for SafeIntLib and BaseLib * Update MdePkg.ci.yaml to build and run host based tests for SafeIntLib and BaseLib Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
* UnitTestFrameworkPkg: Add DSC, DSC INC, and YAML filesMichael D Kinney2020-02-075-0/+257
| | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2505 * DSC in root of package file to perform a package build of the UnitTestFrameworkPkg and build sample unit test for all supported target environments. * DSC file in Test directory to build the sample unit test for the host environment. * UnitTestFrameworkPkgTarget.dsc.inc - DSC include file to !include when building unit tests for target environments. * UnitTestFrameworkPkgHost.dsc.inc - DSC include file to !include when building unit tests for target environments. * YAML file with set of CI checks to perform on UnitTestFrameworkPkg. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
* UnitTestFrameworkPkg/Test: Add unit test samplesMichael D Kinney2020-02-076-0/+461
| | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2505 Add an implementation of a sample unit test that demonstrates the use of the UnitTestLib services and macros and supports being built for execution in a host environment or for execution on a target in PEI, DXE, SMM, or UEFI Shell. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
* UnitTestFrameworkPkg/Library: Add library instancesMichael D Kinney2020-02-0739-0/+4692
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2505 Add the following library instances that are used to build unit tests for host and target environments. * CmockaLib with cmocka submodule to: https://git.cryptomilk.org/projects/cmocka.git * DebugLibPosix - Instance of DebugLib based on POSIX APIs (e.g. printf). * MemoryAllocationLibPosix - Instance of MemoryAllocationLib based on POSIX APIs (e.g. malloc/free). * UnitTestBootLibNull - Null instance of the UnitTestBootLib * UnitTestBootLibUsbClass - UnitTestBootLib instances that supports setting boot next to a USB device. * UnitTestLib - UnitTestLib instance that is designed to work with PEI, DXE, SMM, and UEFI Shell target environments. * UnitTestLibCmocka - UintTestLib instance that uses cmocka APIs and can only be use in a host environment. * UnitTestPersistenceLibNull - Null instance of the UnitTestPersistenceLib * UnitTestPersistenceLibSimpleFileSystem - UnitTestPersistenceLib instance that can safe the unit test framework state to a media device that supports the UEFI Simple File System Protocol. * UnitTestResultReportLibConOut - UnitTestResultReportLib instance that sends report results to the UEFI standard output console. * UnitTestResultReportLibDebugLib - UnitTestResultReportLib instance that sends report results to a DebugLib using DEBUG() macros. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
* UnitTestFrameworkPkg: Add public and private interfacesMichael D Kinney2020-02-077-0/+645
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2505 Add public interfaces for use by unit test implementations. * Include path to cmocka library interfaces. * PcdUnitTestLogLevel to set the unit test logging message level to filter log messages. Add private interfaces that are used by UnitTestLib implementations. * [Private] UnitTestBootLib - Set boot next to continue unit tests across a reboot. * [Private] UnitTestPersistenceLib - Save unit test framework state to a persistent storage device. * [Private] UnitTestResultLib - Output unit test results to a console device. * [Private] UnitTestFrameworkTypes.h - Internal structures used by UnitTestLib implementations to keep track if unit test frameworks, unit test suites, and unit tests along with the serialized storage format to save a unit test framework state to persistent storage. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
* MdePkg/Include/Library: Add UnitTestLib classBret Barkelew2020-02-072-0/+761
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2505 Add UnitTestLib class to MdePkg that provides services and macros to implement unit tests. These services and macros support the following features: * Create a Unit Test Framework * Add a Unit Test Suite to a Unit Test Framework + Support optional step that executes before a Unit Test Suite is started. + Support optional step that executes after a Unit Test Suite is finished. * Add a Unit Test to a Unit Test Suite + Support optional step that executes before a Unit Test is started. + Support optional step that executes after a Unit Test is finished. * Run all unit tests added to a Unit Test Framework * Save Unit Test Framework state to persistent storage * Support assertion checks in a unit test for TRUE, FALSE, EQUAL, MEM_EQUAL, NOT_EFI_ERROR, STATUS_EQUAL, and NOT_NULL. * Support generation of log messages at ERROR, WARN, INFO, and VERBOSE levels. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* BaseTools/Plugin: Add HostBasedUnitTestRunner pluginMichael D Kinney2020-02-072-0/+127
| | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2505 Add plugin to BaseTools to run host based unit tests. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com> Acked-by: Bob Feng <bob.c.feng@intel.com>
* .pytool: Add CI support for host based unit tests with resultsMichael D Kinney2020-02-0714-24/+421
| | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2505 * Add plugin to build and run host based unit tests * Add plugin that performs a DSC complete check DSC files used to build host based tests * Update DscCompleteCheck plugin to ignore module INFs with a MODULE_TYPE of HOST_APPLICATION and library INFs that only support a module type of HOST_APPLICATION. * Fix issues in XML reports from checkers. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
* CryptoPkg/CryptoPkg.dsc: Add build of Crypto libraries/modulesMichael D Kinney2020-02-071-25/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2420 Based on the following package with changes to merge into CryptoPkg. https://github.com/microsoft/mu_plus/tree/dev/201908/SharedCryptoPkg Add Crypto library instances and modules that consume/produce the EDK II Crypto Protocols/PPIs to the CryptoPkg DSC file. The default build of CryptoPkg performs a package verification build. The CRYPTO_SERVICES define is added that supports the following settings. * PACKAGE - Package verification build of all components. Null versions of libraries are used to minimize build times. * ALL - Build PEIM, DXE, and SMM drivers. Protocols and PPIs publish all services. * NONE - Build PEIM, DXE, and SMM drivers. Protocols and PPIs publish no services. Used to verify compiler/linker optimizations are working correctly. * MIN_PEI - Build PEIM with PPI that publishes minimum required services. * MIN_DXE_MIN_SMM - Build DXE and SMM drivers with Protocols that publish minimum required services. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* CryptoPkg/Library: Add BaseCryptLibOnProtocolPpi instancesMichael D Kinney2020-02-078-0/+4741
| | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2420 Based on the following package with changes to merge into CryptoPkg. https://github.com/microsoft/mu_plus/tree/dev/201908/SharedCryptoPkg Add the PeiCryptLib, DxeCryptLib, and SmmCryptLib instances of the BaseCryptLib library classes that are implemented using the services of EDK II Crypto Protocols/PPIs. These library instances all set a dependency expression on the EDK II Crypto Protocols/PPIs, so any modules that use these library instances are not dispatched until the modules that produce the EDK II Crypto Protocols/PPIs are dispatched. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* CryptoPkg/Driver: Add Crypto PEIM, DXE, and SMM modulesMichael D Kinney2020-02-078-0/+4922
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2420 Based on the following package with changes to merge into CryptoPkg. https://github.com/microsoft/mu_plus/tree/dev/201908/SharedCryptoPkg Add the CryptoPei, CryptoDxe, and CryptoSmm modules that produce EDK II Crypto Protocols/PPIs that provide the same services as the BaseCryptLib class. In order to optimize the size of CryptoPei, CryptoDxe, and CryptoSmm modules for a specific platform, the FixedAtBuild PCD gEfiCryptoPkgTokenSpaceGuid.PcdCryptoServiceFamilyEnable is used to determine if a specific service is enabled or disabled. If a service is enabled, then a call is made to the BaseCryptLib service. If the service is disabled, then a DEBUG() message and ASSERT() are performed and a default return value is returned. This provides simple detection of a service that is disabled but is used by another module when DEBUG()/ASSERT() macros are enabled. The use of a FixedAtBuild PCD is required so the compiler and linker know each services enable/disable setting at build time and allows disabled services to be optimized away. CryptoPei supports both pre-mem and post-mem use cases. If CryptoPei is initially dispatched pre-mmem, the the register for shadow service is used so the Crypto PPI can be reinstalled post-mem. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* CryptoPkg: Add EDK II Crypto Protocols/PPIs/PCDsMichael D Kinney2020-02-076-3/+4536
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2420 Based on the following package with changes to merge into CryptoPkg. https://github.com/microsoft/mu_plus/tree/dev/201908/SharedCryptoPkg Add the EDK II Crypto Protocol, EDK II SMM Crypto Protocol and EDK II Crypto PPI that provide the same services as the BaseCryptLib. One additional GetVersion() services is provided to support backward compatible extensions to these new Protocols/PPIs if new services are added to BaseCryptLib in the future. The EDK II Crypto Protocols/PPIs are located in a private directory so they are only available CryptoPkg components. In order to optimize the size of modules that produce the EDK II Crypto Protocols/PPIs define a FixedAtBuild PCD gEfiCryptoPkgTokenSpaceGuid.PcdCryptoServiceFamilyEnable. This PCD is type VOID* and is associated with the structure PCD_CRYPTO_SERVICE_FAMILY_ENABLE. This structure contains bitfields and unions that allow a platform DSC files to enable/disable entire families of services or enable/disable individual services in the produced EDK II Crypto Protocols/PPIs. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* CryptoPkg/BaseCryptLib: Add X509ConstructCertificateStackV().Michael D Kinney2020-02-074-12/+128
| | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2420 Add X509ConstructCertificateStackV() to BaseCryptLib that is identical in behavior to X509ConstructCertificateStack(), but it takes a VA_LIST parameter for the variable argument list. The VA_LIST form of this function is required for BaseCryptLib functions to be wrapped in a Protocol/PPI. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/PiDxeS3BootScriptLib: Fix potential numeric truncation ↵Hao A Wu2020-02-071-1/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (CVE-2019-14563) REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2001 For S3BootScriptLib APIs: S3BootScriptSaveIoWrite S3BootScriptSaveMemWrite S3BootScriptSavePciCfgWrite S3BootScriptSavePciCfg2Write S3BootScriptSaveSmbusExecute S3BootScriptSaveInformation S3BootScriptSaveInformationAsciiString S3BootScriptLabel (happen in S3BootScriptLabelInternal()) possible numeric truncations will happen that may lead to S3 boot script entry with improper size being returned to store the boot script data. This commit will add checks to prevent this kind of issue. Please note that the remaining S3BootScriptLib APIs: S3BootScriptSaveIoReadWrite S3BootScriptSaveMemReadWrite S3BootScriptSavePciCfgReadWrite S3BootScriptSavePciCfg2ReadWrite S3BootScriptSaveStall S3BootScriptSaveDispatch2 S3BootScriptSaveDispatch S3BootScriptSaveMemPoll S3BootScriptSaveIoPoll S3BootScriptSavePciPoll S3BootScriptSavePci2Poll S3BootScriptCloseTable S3BootScriptExecute S3BootScriptMoveLastOpcode S3BootScriptCompare are not affected by such numeric truncation. Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/Capsule: Remove RT restriction in UpdateCapsule service.Siyuan Fu2020-02-074-6/+20
| | | | | | | | | | | | | | | | | | Current UpdateCapsule service will reject all non-reset capsule images and return EFI_OUT_OF_RESOURCE if the system is at runtime. This will block a platform CapsuleLib from implementing ProcessCapsuleImage() with runtime capsule processing capability. This patch removes this restriction. The change is controled by a feature PCD PcdSupportProcessCapsuleAtRuntime, and the default value is FALSE which means not enable this feature. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2501 Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com>
* SecurityPkg/TcgPhysicalPresenceLib: Replace the ASSERT with error codeZhichao Gao2020-02-071-6/+19
| | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2472 Replace the ASSERT with the error code return in the TpmPhysicalPresence and GetTpmCapability. Add missing error checking after call TpmPhysicalPresence in TcgPhysicalPresenceLibProcessRequest. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
* BaseTools/PcdValueCommon: Fix 64-bit host compiler errorSean Brogan2020-02-071-1/+1
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2496 Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools/WindowsVsToolChain: Setup VS2017/VS2019 envSean Brogan2020-02-071-0/+23
| | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2495 Update the WindowsVsToolChain plugin to setup the VS2017 or VS2019 development environment. This is required to build BaseTools and Structured PCD host applications. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools/WindowsVsToolChain: Clean up Python source formattingSean Brogan2020-02-071-19/+26
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2495 Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools/Build: Do not use Common.lib in Structured PCD appKinney, Michael D2020-02-073-23/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2496 Reduce the build and env dependencies for the Structured PCD application by removing the dependency on Common.lib that is only built when BaseTools is built which does not happen if pre-compiled BaseToools are used. Change the makefile for the Structure PCD application to build all files from sources which adds PcdValueCommon.c to the makefile. Also remove PcdValueCommon.c from Common.lib. With the change to the makefile for the Structured PCD application, multiple C files are compiled. Only PcdValueInit.c contains the extra information expected by the error/warning message parser. Only parse the DSC line number into an error message if there is an error/warning in PcdValueInit.c. Errors/warnings in other files should be passed through. This fixes a build failure with no useful log information that was observed when there was a compiler error in PcdValueCommon.c. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: Enhance call stack unwindability for CLANGPDB x64 binarySteven2020-02-071-7/+9
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2487 The call stack unwindability of the COFF X64 binary requires the binary to remain the pdata and xdata sections. Details see the MSVC X64 calling convertion doc in below link: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention Current build options discard or zero the data in pdata and xdata sections which cause the debugger cannot correctly unwind the X64 binary call stack in the runtime. Enhance the build options to force emit the unwind tables and keep the data of pdata and xdata sections correct in the binary. Signed-off-by: Steven Shi <steven.shi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools tools_def.template: Add back -fno-pie option in GCC49 tool chainLiming Gao2020-02-071-2/+2
| | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2502 This option is required to make GCC49 tool chain work with the high version GCC compiler. Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* MdeModulePkg/BaseSerialPortLib16550: Fix Serial Port ReadyAshish Singhal2020-02-061-1/+1
| | | | | | | | | Before writing data to FIFO, wait for the serial port to be ready, to make sure both the transmit FIFO and shift register empty. Code comment was saying the right thing but code was missing a check. Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
* BaseTools: Script for converting .aml to .hexPierre Gondois2020-02-064-0/+176
| | | | | | | | | | | | | | | | | | | | | | | | The "-tc" option of the iasl compiler allows to generate a .hex file containing a C array storing AML bytecode. An online discussion suggested that this "-tc" option was specific to the iasl compiler and it shouldn't be relied on. This conversation is available at: https://edk2.groups.io/g/devel/topic/39786201#49659 A way to address this issue is to implement a compiler independent script that takes an AML file as input, and generates a .hex file. This patch implements a Python script that converts an AML file to a .hex file, containing a C array storing AML bytecode. This scipt has been tested with the AML output from the following compilers supported by the EDKII implementation: * Intel ASL compiler * Microsoft ASL compiler Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools/Scripts/PatchCheck.py: Do not use mailmapPhilippe Mathieu-Daude2020-02-061-2/+4
| | | | | | | | | | | | | | | We check the author/committer name/email are properly displayed since commits 8ffa47fb3ab..c0328cf3803. However if PatchCheck.py uses the mailmap, it will check sanitized names/emails. Use the --no-use-mailmap option so PatchCheck.py will check unsanitized input. Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools/Scripts/PatchCheck.py: Detect emails rewritten by Groups.IoPhilippe Mathieu-Daude2020-02-061-0/+4
| | | | | | | | | | | | | Due to strict DMARC / DKIM / SPF rules, Groups.Io sometimes rewrite the author email. See for example commit df851da3ceff5b6bcf5e12616. Add a check to detect these rewrites with PatchCheck.py. Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools/Scripts: Add log.mailmap to SetupGit.pyPhilippe Mathieu-Daude2020-02-061-0/+1
| | | | | | | | | | | | | We added .mailmap to the repository in commit 4a1aeca3bd02d04e01c2d to display commit mistakes fixed. Use this option by default in our git setup. Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* MdePkg Base.h: Use correct style to check macro _MSC_VER valueLiming Gao2020-02-063-3/+3
| | | | | Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdePkg: Avoid using __clang__ to specify CLANGPDBLiu, Zhiguang2020-02-061-1/+1
| | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2415 Avoid using __clang__ to specify CLANGPDB because this macro is also defined in CLANG38 and this causes CLANG38 build failure. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: append -DNO_MSABI_VA_FUNCS option in CLANGPDB tool chainLiu, Zhiguang2020-02-061-1/+1
| | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2415 Define NO_MSABI_VA_FUNCS to use GCC built-in macros for variable argument lists for CLANGPDB tool chain. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdeModulePkg: Perform test only if not ignore memory testHeng Luo2020-02-061-4/+6
| | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2463 Perform Data and Address line test only if not ignore memory test. Signed-off-by: Heng Luo <heng.luo@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Always get CPUID & PlatformID in MicrocodeDetect()Hao A Wu2020-02-061-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2498 Commit fd30b00707 updated the logic in function MicrocodeDetect() that will directly use the CPUID and PlatformID information from the 'CpuData' field in the CPU_MP_DATA structure, instead of collecting these information for each processor via AsmCpuid() and AsmReadMsr64() calls respectively. At that moment, this approach worked fine for APs. Since: a) When the APs are waken up for the 1st time (1st MpInitLibInitialize() entry at PEI phase), the function InitializeApData() will be called for each AP and the CPUID and PlatformID information will be collected. b) During the 2nd entry of MpInitLibInitialize() at DXE phase, when the APs are waken up again, the function InitializeApData() will not be called, which means the CPUID and PlatformID information will not be collected. However, the below logics in MicrocodeDetect() function: CurrentRevision = GetCurrentMicrocodeSignature (); IsBspCallIn = (ProcessorNumber == (UINTN)CpuMpData->BspNumber) ? TRUE : FALSE; if (CurrentRevision != 0 && !IsBspCallIn) { // // Skip loading microcode if it has been loaded successfully // return; } will ensure that the microcode detection and application will be skipped due to the fact that such process has already been done in the PEI phase. But after commit 396e791059, which removes the above skip loading logic, the CPUID and PlatformID information on APs will be used upon the 2nd entry of the MpInitLibInitialize(). But since the CPUID and PlatformID information has not been collected, it will bring issue to the microcode detection process. This commit will update the logic in MicrocodeDetect() back to always collecting the CPUID and PlatformID information explicitly. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)Laszlo Ersek2020-02-052-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the SMRAM at the default SMBASE is honored everywhere necessary, implement the actual detection. The (simple) steps are described in previous patch "OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macros". Regarding CSM_ENABLE builds: according to the discussion with Jiewen at https://edk2.groups.io/g/devel/message/48082 http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F7C9D2F@shsmsx102.ccr.corp.intel.com if the platform has SMRAM at the default SMBASE, then we have to (a) either punch a hole in the legacy E820 map as well, in LegacyBiosBuildE820() [OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c], (b) or document, or programmatically catch, the incompatibility between the "SMRAM at default SMBASE" and "CSM" features. Because CSM is out of scope for the larger "VCPU hotplug with SMM" feature, option (b) applies. Therefore, if the CSM is enabled in the OVMF build, then PlatformPei will not attempt to detect SMRAM at the default SMBASE, at all. This is approach (4) -- the most flexible one, for end-users -- from: http://mid.mail-archive.com/868dcff2-ecaa-e1c6-f018-abe7087d640c@redhat.com https://edk2.groups.io/g/devel/message/48348 Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200129214412.2361-12-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PcdCsmEnable feature flagLaszlo Ersek2020-02-055-0/+17
| | | | | | | | | | | | | | | | | | | | | In the DXE phase and later, it is possible for a module to dynamically determine whether a CSM is enabled. An example can be seen in commit 855743f71774 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM", 2016-05-25). SEC and PEI phase modules cannot check the Legacy BIOS Protocol however. For their sake, introduce a new feature PCD that simply reflects the CSM_ENABLE build flag. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200129214412.2361-11-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASELaszlo Ersek2020-02-056-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During normal boot, when EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by platform BDS, the SMM IPL locks SMRAM (TSEG) through EFI_SMM_ACCESS2_PROTOCOL.Lock(). See SmmIplReadyToLockEventNotify() in "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c". During S3 resume, S3Resume2Pei locks SMRAM (TSEG) through PEI_SMM_ACCESS_PPI.Lock(), before executing the boot script. See S3ResumeExecuteBootScript() in "UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c". Those are precisely the places where the SMRAM at the default SMBASE should be locked too. Add such an action to SmramAccessLock(). Notes: - The SMRAM at the default SMBASE doesn't support the "closed and unlocked" state (and so it can't be closed without locking it, and it cannot be opened after closing it). - The SMRAM at the default SMBASE isn't (and shouldn't) be exposed with another EFI_SMRAM_DESCRIPTOR in the GetCapabilities() members of EFI_SMM_ACCESS2_PROTOCOL / PEI_SMM_ACCESS_PPI. That's because the SMRAM in question is not "general purpose"; it's only QEMU's solution to protect the initial SMI handler from the OS, when a VCPU is hot-plugged. Consequently, the state of the SMRAM at the default SMBASE is not reflected in the "OpenState" / "LockState" fields of the protocol and PPI. - An alternative to extending SmramAccessLock() would be to register an EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL notify in SmmAccess2Dxe (for locking at normal boot), and an EDKII_S3_SMM_INIT_DONE_GUID PPI notify in SmmAccessPei (for locking at S3 resume). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-10-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASELaszlo Ersek2020-02-053-7/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When OVMF runs in a SEV guest, the initial SMM Save State Map is (1) allocated as EfiBootServicesData type memory in OvmfPkg/PlatformPei, function AmdSevInitialize(), for preventing unintended information sharing with the hypervisor; (2) decrypted in AmdSevDxe; (3) re-encrypted in OvmfPkg/Library/SmmCpuFeaturesLib, function SmmCpuFeaturesSmmRelocationComplete(), which is called by PiSmmCpuDxeSmm right after initial SMBASE relocation; (4) released to DXE at the same location. The SMRAM at the default SMBASE is a superset of the initial Save State Map. The reserved memory allocation in InitializeRamRegions(), from the previous patch, must override the allocating and freeing in (1) and (4), respectively. (Note: the decrypting and re-encrypting in (2) and (3) are unaffected.) In AmdSevInitialize(), only assert the containment of the initial Save State Map, in the larger area already allocated by InitializeRamRegions(). In SmmCpuFeaturesSmmRelocationComplete(), preserve the allocation of the initial Save State Map into OS runtime, as part of the allocation done by InitializeRamRegions(). Only assert containment. These changes only affect the normal boot path (the UEFI memory map is untouched during S3 resume). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-9-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it existsLaszlo Ersek2020-02-051-2/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 128KB SMRAM at the default SMBASE will be used for protecting the initial SMI handler for hot-plugged VCPUs. After platform reset, the SMRAM in question is open (and looks just like RAM). When BDS signals EFI_DXE_MM_READY_TO_LOCK_PROTOCOL (and so TSEG is locked down), we're going to lock the SMRAM at the default SMBASE too. For this, we have to reserve said SMRAM area as early as possible, from components in PEI, DXE, and OS runtime. * QemuInitializeRam() currently produces a single resource descriptor HOB, for exposing the system RAM available under 1GB. This occurs during both normal boot and S3 resume identically (the latter only for the sake of CpuMpPei borrowing low RAM for the AP startup vector). But, the SMRAM at the default SMBASE falls in the middle of the current system RAM HOB. Split the HOB, and cover the SMRAM with a reserved memory HOB in the middle. CpuMpPei (via MpInitLib) skips reserved memory HOBs. * InitializeRamRegions() is responsible for producing memory allocation HOBs, carving out parts of the resource descriptor HOBs produced in QemuInitializeRam(). Allocate the above-introduced reserved memory region in full, similarly to how we treat TSEG, so that DXE and the OS avoid the locked SMRAM (black hole) in this area. (Note that these allocations only occur on the normal boot path, as they matter for the UEFI memory map, which cannot be changed during S3 resume.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-8-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default SMBASELaszlo Ersek2020-02-051-0/+10
| | | | | | | | | | | | | | | | | | | | | | | The permanent PEI RAM that is published on the normal boot path starts strictly above MEMFD_BASE_ADDRESS (8 MB -- see the FDF files), regardless of whether PEI decompression will be necessary on S3 resume due to SMM_REQUIRE. Therefore the normal boot permanent PEI RAM never overlaps with the SMRAM at the default SMBASE (192 KB). The S3 resume permanent PEI RAM is strictly above the normal boot one. Therefore the no-overlap statement holds true on the S3 resume path as well. Assert the no-overlap condition commonly for both boot paths in PublishPeiMemory(). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton)Laszlo Ersek2020-02-054-0/+27
| | | | | | | | | | | | | | | | | Introduce the Q35SmramAtDefaultSmbaseInitialization() function for detecting the "SMRAM at default SMBASE" feature. For now, the function is only a skeleton, so that we can gradually build upon the result while the result is hard-coded as FALSE. The actual detection will occur in a later patch. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: factor out Q35BoardVerification()Laszlo Ersek2020-02-052-12/+24
| | | | | | | | | | | | | | Before adding another SMM-related, and therefore Q35-only, dynamically detectable feature, extract the current board type check from Q35TsegMbytesInitialization() to a standalone function. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macrosLaszlo Ersek2020-02-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Intel datasheet 316966-002 (the "q35 spec"), Table 5-1 "DRAM Controller Register Address Map (D0:F0)" leaves the byte register at config space offset 0x9C unused. On QEMU's Q35 board, for detecting the "SMRAM at default SMBASE" feature, firmware is expected to write MCH_DEFAULT_SMBASE_QUERY (0xFF) to offset MCH_DEFAULT_SMBASE_CTL (0x9C), and read back the register. If the value is MCH_DEFAULT_SMBASE_IN_RAM (0x01), then the feature is available, and the range mentioned below is open (accessible to code running outside of SMM). Then, once firmware writes MCH_DEFAULT_SMBASE_LCK (0x02) to the register, the MCH_DEFAULT_SMBASE_SIZE (128KB) range at 0x3_0000 (SMM_DEFAULT_SMBASE) gets closed and locked down, and the register becomes read-only. The area is reopened, and the register becomes read/write, at platform reset. Add the above-listed macros to "Q35MchIch9.h". (There are some other unused offsets in Table 5-1; for example we had scavenged 0x50 for implementing the extended TSEG feature. 0x9C is the first byte-wide register standing in isolation after 0x50.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defsLaszlo Ersek2020-02-051-50/+50
| | | | | | | | | | | | | | | | | In a subsequent patch, we'll introduce new DRAM controller macros in "Q35MchIch9.h". Their names are too long for the currently available vertical whitespace, so increase the latter first. There is no functional change in this patch ("git show -b" displays nothing). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PcdQ35SmramAtDefaultSmbaseLaszlo Ersek2020-02-054-0/+9
| | | | | | | | | | | | | | | | | | | | | For supporting VCPU hotplug with SMM enabled/required, QEMU offers the (dynamically detectable) feature called "SMRAM at default SMBASE". When the feature is enabled, the firmware can lock down the 128 KB range starting at the default SMBASE; that is, the [0x3_0000, 0x4_FFFF] interval. The goal is to shield the very first SMI handler of the hotplugged VCPU from OS influence. Multiple modules in OVMF will have to inter-operate for locking down this range. Introduce a dynamic PCD that will reflect the feature (to be negotiated by PlatformPei), for coordination between drivers. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* CryptoPkg/BaseCryptLibNull: Add missing HkdfSha256ExtractAndExpand()Michael D Kinney2020-02-042-1/+45
| | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2493 The BaseCryptLib was expanded to add the HkdfSha256ExtractAndExpand() service in the following commit: https://github.com/tianocore/edk2/commit/4b1b7c1913092d73d689d8086dcfa579c0217dc8 When BaseCryptLibNull was added in the commit below, this new service was not included. https://github.com/tianocore/edk2/commit/d95de082da01f4a4cb3ebf87e15972a12d0f8d53 Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* BaseTools/DscBuildData: Fix PCD autogen include file conflictMichael D Kinney2020-02-041-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2494 When using structured PCDs, a C application is auto generated to fill in the structured PCD value. The C application uses the standard include files <stdio.h>, <stdlib.h>, and <string.h>. This C application also supports include paths from package DEC files when a structured PCD declaration provides a <Packages> list. The complete list of include paths are -I options for include paths from package DEC files and the compiler's standard include paths. -I include paths are higher priority than the standard include paths. If the -I included paths from package DEC files contain <stdio.h>, <stdlib.h>, or <string.h> the wrong include files are used to compile the C application for the structured PCD value. Update GenerateByteArrayValue() to skip a package DEC include paths that contain <stdio.h>, <stdlib.h>, or <string.h>. Build failures were observed when adding a structured PCD to CryptoPkg. CryptoPkg contains <stdio.h>, <stdlib.h>, and <string.h> in the path CryptoPkg/Library/Include to support building Open SSL. The Library/Include path is listed as a private include path in CryptoPkg.dec. Without this change, the standard include files designed to support build OpenSLL are used to build the structured PCD C application, and that build fails. Other packages that provide a standard C lib or a gasket for a subset of the standard C lib will run into this same issue if they also define and use a Structured PCD. So this issue is not limited to the CryptoPkg. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* CryptoPkg/BaseHashApiLib: Implement Unified Hash Calculation APIAmol N Sukerkar2020-02-037-2/+553
| | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2151 This commit introduces a Unified Hash API to calculate hash using a hashing algorithm specified by the PCD, PcdHashApiLibPolicy. This library interfaces with the various hashing API, such as, MD4, MD5, SHA1, SHA256, SHA512 and SM3_256 implemented in BaseCryptLib. The user can calculate the desired hash by setting PcdHashApiLibPolicy to appropriate value. This feature is documented in the Bugzilla, https://bugzilla.tianocore.org/show_bug.cgi?id=2151. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Amol N Sukerkar <amol.n.sukerkar@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* CryptoPkg: Add CryptoPkg Token Space GUIDAmol N Sukerkar2020-02-031-1/+5
| | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2151 Added CryptoPkg Token Space GUID to be able to define PCDs. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Amol N Sukerkar <amol.n.sukerkar@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools/Conf/gitattributes: fix "--function-context" for C source codeLaszlo Ersek2020-01-311-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "--function-context" ("-W") option of git-diff displays the entire body of a modified function, not just small modified hunks within the function. It is useful for reviewers when the code changes to the function are small, but they could affect, or depend on, control flow that is far away in the same function. Of course, the size of the displayed context can be controlled with the "-U" option anyway, but such fixed-size contexts are usually either too small, or too large, in the above scenario. It turns out that "--function-context" does not work correctly for C source files in edk2. In particular, labels for the goto instruction (which the edk2 coding style places in the leftmost column) appear to terminate "--function-context". The "git" utility contains built-in hunk header patterns for the C and C++ languages. However, they do not take effect in edk2 because we don't explicitly assign the "cpp" git-diff driver to our C files. The gitattributes(5) manual explains that this is required: > There are a few built-in patterns to make this easier, and > tex is one of them, so you do not have to write the above in > your configuration file (you still need to enable this with > the attribute mechanism, via .gitattributes). The following > built in patterns are available: > > [...] > > * cpp suitable for source code in the C and C++ > languages. The key statement is the one in parentheses. Grab the suffix lists from the [C-Code-File] and [Acpi-Table-Code-File] sections of "BaseTools/Conf/build_rule.template", add "*.h" and "*.H", and mark those as belonging to the "cpp" git-diff driver. This change has a dramatic effect on the following command, for example: $ git show -W 2ef0c27cb84c Cc: Bob Feng <bob.c.feng@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200120094245.9010-1-lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* SecurityPkg/DxeImageVerificationHandler: fix "defer" vs. "deny" policiesLaszlo Ersek2020-01-311-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In DxeImageVerificationHandler(), we should return EFI_SECURITY_VIOLATION for a rejected image only if the platform sets DEFER_EXECUTE_ON_SECURITY_VIOLATION as the policy for the image's source. Otherwise, EFI_ACCESS_DENIED must be returned. Right now, EFI_SECURITY_VIOLATION is returned for all rejected images, which is wrong -- it causes LoadImage() to hold on to rejected images (in untrusted state), for further platform actions. However, if a platform already set DENY_EXECUTE_ON_SECURITY_VIOLATION, the platform will not expect the rejected image to stick around in memory (regardless of its untrusted state). Therefore, adhere to the platform policy in the return value of the DxeImageVerificationHandler() function. Furthermore, according to "32.4.2 Image Execution Information Table" in the UEFI v2.8 spec, and considering that edk2 only supports (AuditMode==0) at the moment: > When AuditMode==0, if the image's signature is not found in the > authorized database, or is found in the forbidden database, the image > will not be started and instead, information about it will be placed in > this table. we have to store an EFI_IMAGE_EXECUTION_INFO record in both the "defer" case and the "deny" case. Thus, the AddImageExeInfo() call is not being made conditional on (Policy == DEFER_EXECUTE_ON_SECURITY_VIOLATION); the documentation is updated instead. Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Fixes: 5db28a6753d307cdfb1cfdeb2f63739a9f959837 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200116190705.18816-12-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> [lersek@redhat.com: push with Mike's R-b due to Chinese New Year Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid <d3fbb76dabed4e1987c512c328c82810@intel.com>]
* SecurityPkg/DxeImageVerificationHandler: fix imgexec info on memalloc failLaszlo Ersek2020-01-311-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It makes no sense to call AddImageExeInfo() with (Signature == NULL) and (SignatureSize > 0). AddImageExeInfo() does not crash in such a case -- it avoids the CopyMem() call --, but it creates an invalid EFI_IMAGE_EXECUTION_INFO record. Namely, the "EFI_IMAGE_EXECUTION_INFO.InfoSize" field includes "SignatureSize", but the actual signature bytes are not filled in. Document and ASSERT() this condition in AddImageExeInfo(). In DxeImageVerificationHandler(), zero out "SignatureListSize" if we set "SignatureList" to NULL due to AllocateZeroPool() failure. (Another approach could be to avoid calling AddImageExeInfo() completely, in case AllocateZeroPool() fails. Unfortunately, the UEFI v2.8 spec does not seem to state clearly whether a signature is mandatory in EFI_IMAGE_EXECUTION_INFO, if the "Action" field is EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED or EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND. For now, the EFI_IMAGE_EXECUTION_INFO addition logic is not changed; we only make sure that the record we add is not malformed.) Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200116190705.18816-11-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> [lersek@redhat.com: push with Mike's R-b due to Chinese New Year Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid <d3fbb76dabed4e1987c512c328c82810@intel.com>]
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-24 09:16:17 +0000