3743e71a06
https://bugzilla.tianocore.org/show_bug.cgi?id=1617 This driver implements a common checker, verifier and reporter which is independent of hardware based root-of-trust. Usually the hardware based root-of-trust will not verify all BIOS but part of it. For example, Boot Guard will only verify IBB segment. The IBB needs to verify other part of BIOS, i.e. other FVs to transfer control to from IBB. This driver plays the role in IBB to verify FVs not covered by hardware root-of-trust to make sure integrity of the chain of trust. To be hardware/platform independent, PPI gEdkiiPeiFirmwareVolumeInfoStoredHashFvPpiGuid is introduced for platform to pass digest information to this driver. This PPI should include all information needed to verify required FVs in required boot mode. struct _EDKII_PEI_FIRMWARE_VOLUME_INFO_STORED_HASH_FV_PPI { FV_HASH_INFO HashInfo; UINTN FvNumber; HASHED_FV_INFO FvInfo[1]; }; To avoid TOCTOU issue, all FVs to be verified will be copied to memory before hash calculation. That also means this driver has to be run after permanent memory has been discovered. For a measured boot, this driver will install gEdkiiPeiFirmwareVolumeInfoPrehashedFvPpiGuid to report digest of each FV to TCG driver. For a verified boot, this driver will verify the final hash value (calculated from the concatenation of each FV's hash) for indicated FVs against the hash got from platform/hardware. If pass, it will build EFI_HOB_TYPE_FV (consumed by DXE core) and/or install gEfiPeiFirmwareVolumeInfoPpiGuid (consumed by PEI core), and then report status code PcdStatusCodeFvVerificationPass. If fail, it just report status code PcdStatusCodeFvVerificationFail and go to dead loop if status report returns. The platform can register customized handler to process pass and fail cases differently. Currently, this driver only supports hash (sha256/384/512) verification for the performance consideration. Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: "Hernandez Beltran, Jorge" <jorge.hernandez.beltran@intel.com> Cc: Harry Han <harry.han@intel.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com> |
||
---|---|---|
ArmPkg | ||
ArmPlatformPkg | ||
ArmVirtPkg | ||
BaseTools | ||
Conf | ||
CryptoPkg | ||
DynamicTablesPkg | ||
EmbeddedPkg | ||
EmulatorPkg | ||
FatPkg | ||
FmpDevicePkg | ||
IntelFrameworkModulePkg | ||
IntelFrameworkPkg | ||
IntelFsp2Pkg | ||
IntelFsp2WrapperPkg | ||
MdeModulePkg | ||
MdePkg | ||
NetworkPkg | ||
OvmfPkg | ||
PcAtChipsetPkg | ||
SecurityPkg | ||
ShellPkg | ||
SignedCapsulePkg | ||
SourceLevelDebugPkg | ||
StandaloneMmPkg | ||
UefiCpuPkg | ||
UefiPayloadPkg | ||
.gitignore | ||
.gitmodules | ||
BuildNotes2.txt | ||
License-History.txt | ||
License.txt | ||
Maintainers.txt | ||
Readme.md | ||
edksetup.bat | ||
edksetup.sh |
Readme.md
EDK II Project
A modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications from www.uefi.org.
The majority of the content in the EDK II open source project uses a BSD-2-Clause Plus Patent License. The EDK II open source project contains the following components that are covered by additional licenses:
- BaseTools/Source/C/BrotliCompress
- MdeModulePkg/Library/BrotliCustomDecompressLib
- BaseTools/Source/C/LzmaCompress
- MdeModulePkg/Library/LzmaCustomDecompressLib
- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/Sdk
- BaseTools/Source/C/VfrCompile/Pccts
- MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma
- OvmfPkg
- CryptoPkg/Library/OpensslLib/openssl
- ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3
The EDK II Project is composed of packages. The maintainers for each package are listed in Maintainers.txt.
Resources
- TianoCore
- EDK II
- Getting Started with EDK II
- Mailing Lists
- TianoCore Bugzilla
- How To Contribute
- Release Planning
- UDK2017
- UDK2018
- edk2-stable201811
Code Contributions
To make a contribution to a TianoCore project, follow these steps.
-
Create a change description in the format specified below to use in the source control commit log.
-
Your commit message must include your
Signed-off-by
signature -
Submit your code to the TianoCore project using the process that the project documents on its web page. If the process is not documented, then submit the code on development email list for the project.
-
It is preferred that contributions are submitted using the same copyright license as the base project. When that is not possible, then contributions using the following licenses can be accepted:
- BSD (2-clause): http://opensource.org/licenses/BSD-2-Clause
- BSD (3-clause): http://opensource.org/licenses/BSD-3-Clause
- MIT: http://opensource.org/licenses/MIT
- Python-2.0: http://opensource.org/licenses/Python-2.0
- Zlib: http://opensource.org/licenses/Zlib
For documentation:
- FreeBSD Documentation License https://www.freebsd.org/copyright/freebsd-doc-license.html
Contributions of code put into the public domain can also be accepted.
Contributions using other licenses might be accepted, but further review will be required.
Developer Certificate of Origin
Your change description should use the standard format for a
commit message, and must include your Signed-off-by
signature.
In order to keep track of who did what, all patches contributed must include a statement that to the best of the contributor's knowledge they have the right to contribute it under the specified license.
The test for this is as specified in the Developer's Certificate of Origin (DCO) 1.1. The contributor certifies compliance by adding a line saying
Signed-off-by: Developer Name developer@example.org
where Developer Name
is the contributor's real name, and the email
address is one the developer is reachable through at the time of
contributing.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Sample Change Description / Commit Message
From: Contributor Name <contributor@example.com>
Subject: [Repository/Branch PATCH] Pkg-Module: Brief-single-line-summary
Full-commit-message
Signed-off-by: Contributor Name <contributor@example.com>
Notes for sample patch email
- The first line of commit message is taken from the email's subject
line following
[Repository/Branch PATCH]
. The remaining portion of the commit message is the email's content. git format-patch
is one way to create this format
Definitions for sample patch email
Repository
is the identifier of the repository the patch applies. This identifier should only be provided for repositories other thanedk2
. For exampleedk2-BuildSpecification
orstaging
.Branch
is the identifier of the branch the patch applies. This identifier should only be provided for branches other thanedk2/master
. For exampleedk2/UDK2015
,edk2-BuildSpecification/release/1.27
, orstaging/edk2-test
.Module
is a short identifier for the affected code or documentation. For exampleMdePkg
,MdeModulePkg/UsbBusDxe
,Introduction
, orEDK II INF File Format
.Brief-single-line-summary
is a short summary of the change.- The entire first line should be less than ~70 characters.
Full-commit-message
a verbose multiple line comment describing the change. Each line should be less than ~70 characters.Signed-off-by
is the contributor's signature identifying them by their real/legal name and their email address.