RiscVVirt.dsc.inc includes NetworkPkg/NetworkLibs.dsc.inc. However
RiscVVirt.dsc.inc is only ever included by RiscVVirtQemu.dsc, which
has already included NetworkPkg/Network.dsc.inc, a general include
file which brings in all the required includes for Network features
at once, including NetworkPkg/NetworkLibs.dsc.inc.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
DxeRngLib iterates over a list of secure algorithms before trying
to use the default algorithm provided by the Rng protocol. Add
gEfiRngAlgorithmArmRndr to this list. The algorithm represented by
this GUID is a secure DRBG of an unknown type, implemented by the
aarch64 RNDR instruction.
On AARCH64 platform, use the RNDR instruction as the first option
if it is available.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Use PcdEnforceSecureRngAlgorithms to allow using the Rng protocol
with the default algorithm. All previous call to the Rng protocol
are requesting a secure Rng algorithm.
Not specifying the Rng algorithm GUID to use is considered unsecure.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Add a library constructor which:
- locate the RNG prototocol and keep a reference to it in order to avoid
locating it multiple times (for each random number generation)
- check which secure algorithm is available on the platform.
This avoids to try each secure algorithm until finding one
available for each random number generation call.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The PcdEnforceSecureRngAlgorithms Pcd enforces the use of RNG
algorithms defined by the UEFI spec. To re-use the Pcd in other
packages and have a generic mean to control the usage of unsecure
algorithms, move the Pcd to the MdePkg.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
When the boot file download operation is interrupted for some reason,
HttpBootDxe will use HTTP Range header to try resume the download
operation reusing the bytes downloaded so far.
Signed-off-by: Leandro Gustavo Biss Becker <lbecker@positivo.com.br>
Added HTTP header definitions for the following headers:
"Content-Range", "Last-Modified" and "If-Unmodified-Since"
Signed-off-by: Leandro Gustavo Biss Becker <lbecker@positivo.com.br>
Check that the next map entry is valid before dereferencing to merge the
guard pages. If the final entry is at the end of a page with no valid page
following it, then this can cause an access violation.
Signed-off-by: Kenneth Lautner <kenlautner3@gmail.com>
Now that the new stack check lib implementation is being used
everywhere, remove the old one.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This patch updates the GenC logic to generate a random stack cookie value
for the stack check libraries. These random values improve security
for modules which cannot update the global intrinsics.
If the stack cookie value is randomized in the AutoGen.h file each
build, the build system will determine the module/library must be
rebuilt causing effectively a clean build every time. This also makes
binary reproducibility impossible.
This patch updates the early build scripts to create 32 and 64-bit JSON
files in the build output directory which each contain 100 randomized
stack cookie values for each bitwidth. If the JSON files are already
present, then they are not recreated which allows them to be stored and
moved to other builds for binary reproducibility. Because they are in
the build directory, a clean build will cause the values to be
regenerated.
The logic which creates AutoGen.h will read these JSON files and use a
hash of the module GUID (the hash seed is fixed in Basetools) to index
into the array of stack cookie values for the module bitwidth. This
model is necessary because there isn't thread-consistent data so we
cannot use a locking mechanism to ensure only one thread is writing to
the stack cookie files at a time. With this model, the build threads
only need to read from the files.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Add StackCheckLib for Target and Host based unit tests. Host
based unit tests are treated specially, because MSVC built
host based unit tests use the MSVC C runtime lib to provide
the stack cookie definitions, but GCC built host based unit
tests use our implementation, as we do not link against a
C runtime lib that provides the definitions.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
SecCore and SecCoreNative require StackCheckLib and so the NULL
instance is linked against them here.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
StackCheckLib contains the required functionality for initializing
the stack cookie value, checking the value, and triggering an interrupt
when a mismatch occurs. The stack cookie is a random value placed on the
stack between the stack variables and the return address so that
continuously writing past the stack variables will cause the stack cookie
to be overwritten. Before the function returns, the stack cookie value
will be checked and if there is a mismatch then StackCheckLib handles the
failure.
Because UEFI doesn't use the C runtime libraries provided by MSVC, the
stack check code is written in assembly within this library. GCC and
Clang compilers have built-in support for stack cookie checking, so this
library only handles failures.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Add Null libs for Stack Check and Stack Check Failure Hook Lib that
allow a platform to opt out of stack checks and the stack check failure
hook lib.
StackCheckLib allows implementation (or in this case null implementation)
of stack checks on binaries. There is a Host Application specific version
of this null lib because MSVC host applications must not be linked against
our lib (so the file here is a no-op but that doesn't cause the build
system to fail the build for not building a file for MSVC) as it links
against the MSVC C runtime lib that provides the stack cookie definitions.
GCC host applications do not link against such a C runtime lib and must
be linked against our version.
StackCheckFailureHookLib lets a platform do custom functionality when a
stack check failure occurs (such as log it to a platform defined
mechanism). The null lib simply returns.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This patch adds a PCD allowing a platform to specify
the interrupt vector to trigger on a stack check
failure. On x86, this is an offset into the IDT.
On ARM/AARCH64, this triggers a software interrupt
that can be decoded to indicate this was a stack
check failure.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Previously, the UnitTestFrameworkPkgHost.dsc.inc included the entire
UnitTestFrameworkPkgTarget.dsc.inc file. This is unnecessary for
most configurations, so copy the relevant common components to a
separate file.
This is required for stack cookies so that we can have stack
cookies on target based test apps but not on host base test apps.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
PxeBcDhcp6GoogleTest's MultipleDnsEntries test started to fail
with stack cookies added for host applications. Debugging this
showed that the test was attempting to copy two UINT16s to a
UINT8 Data[1] array allocated on the stack. This was moved to
a heap based allocation for a UINT32 to accommodate the proper
size. After this fix, the unit test passed with stack cookies
enabled.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Cache maintenance operations by set/way are not broadcast, and operate
on individual architected caches, making them suitable only for
en/disabling cache levels, which is the job of secure firmware, to be
carried out while the CPU in question is not taking part in the
cache coherency protocol.
Managing the clean/dirty state of a memory range can only be done using
cache maintenance by virtual address.
So drop the set/way handling from ArmLib for ARM and AARCH64, as there
is no context where it can be used correctly from EDK2.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cache maintenance on the D-cache hierarchy as a whole is not supported
by the ARM architecture, so drop the routines from ArmLib that pretend
to implement it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
https://bugzilla.tianocore.org/show_bug.cgi?id=48297f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
This problem also applies in the ArmVirtPkg
platforms which are modified here, but is currently
masked by another issue, namely that these platforms
incorrectly still include some network packages when
most are disabled. (A fix for this was previously applied,
for OvmfPkg Intel platforms only, by
d933ec1 followed by
7f17a15 .)
This commit was created at the same time as the
commits resolving this issue in NetworkPkg and
OvmfPkg. It makes conditional the Pcd references
in ArmVirtPkg platforms which will become references to
undefined Pcds as and when the other issue mentioned
above is fixed.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=48297f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
The problem applies in Intel OvmfPkg platforms.
Additionally, it applies in various other OvmfPkg
platforms, but is masked buy another issue; namely
that these platforms incorrectly still include some
network packages when most are disabled.
(A fix for that issue has previously been
made, in OvmfPkg Intel platforms only, by
d933ec1 followed by
7f17a15 .)
This commit conditionally removes the undefined Pcd references
in all OvmfPkg platforms which are now affected by this
issue, and in all those which would be affected as and
when the other issue mentioned above is fixed.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=48297f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
This commit conditionally removes the undefined Pcd reference in
NetworkPkg which is part of this issue.
Similar changes are needed in separate commits for
OvmfPkg (and for ArmVirtPkg, since the issue also
exists there, although masked by another issue).
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
As per the emailed RFC in
https://edk2.groups.io/g/devel/topic/rfc_move/107675828,
this patch moves CompilerIntrinsicsLib from ArmPkg to
MdePkg as this library provides compiler intrinsics, which
are industry standard.
This aligns with the goal of integrating ArmPkg into existing
packages: https://bugzilla.tianocore.org/show_bug.cgi?id=4121.
The newly placed CompilerIntrinsicsLib is added to MdeLibs.dsc.inc
as every DSC that builds ARM/AARCH64 needs this library added. The
old location is removed from every DSC in edk2 in this commit also
to not break bisectability with minimal hoop jumping.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
AsmMacroIoLib.h and AsmMacroIoLibV8.h are used by the
CompilerIntrinsicsLib, which is moving to MdePkg. These
functions provide standard definitions for ARM/AARCH64
assembly code, respectively, and so are moved to the arch
directories in MdePkg to avoid MdePkg having a
dependency on ArmPkg.
Now that the files are in Arm/ and AArch64/ directories,
the filenames are changed to AsmMacroLib.h as we can
distinguish the architecture from the path.
AsmMacroIoLib.inc is unused and so is removed.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
AArch64/ashlti3.S was using AsmMacroIoLib.h which is the ARM version
of these definitions. AsmMacroIoLibV8.h is the AARCH64 version of
these defintions. This patch moves that file to use the proper arch
file.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Mike Beaton
Pierre Gondois
Chun-Yi Lee
Leandro Becker
Ken Lautner
Oliver Smith-Denny
Taylor Beebe
Oliver Smith-Denny
Bret Barkelew
Ard Biesheuvel