The existing HttpBootUninstallCallback was passing the wrong handle (the
PrivateData root controller handle, not the correct child IPv4 or IPv6
NIC controller handle; cf HttpBootInstallCallback for matching logic) and
was also passing the address of a pointer to the interface to be removed
rather than the pointer itself, so always failed with EFI_NOT_FOUND.
This resulted in the prior behaviour that if multiple HTTP boot attempts
were made, on the second and subsequent attempts the instance of this
protocol installed by the first attempt would be re-used. As long as only
one driver using the protocol is installed, this ends up producing the
same results as if the protocol had been uninstalled then reinstalled
correctly.
After this commit, the protocol is installed at the start of an HTTP boot
attempt and uninstalled it at the end of it (assuming nothing else has
accessed the protocol in a way which blocks the uninstall).
It might seem attractive to add an ASSERT to confirm when debugging
that the uninstall succeeds as expected, but this is recommended against
because uninstallation of protocol interfaces is allowed to fail under
the UEFI model:
https://edk2.groups.io/g/devel/message/117469.
An ASSERT could therefore arise from a sequence of events which is
perfectly valid - or at least is out of the control of this driver.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
DT has a way to provide reserved images in a simpler tabular
manner. UPL should be able to support that.
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
Devicetree defines a short hand way of defining reserved memory
ranges. Add APIs to access such nodes
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
In order to properly enable multisegment RB, we need
to grab ecam data from the FDT for each bridge.
Current UNIVERSAL_PAYLOAD_PCI_ROOT_BRIDGES struct from
MdeModulePkg does not include definition for ecam. In
order to maintain backward compatibility and also avoid
diverging too much from core, we are going to define a
new HOB for UPL segment information and pass it to
GetPciSegmentInfo function. Ths function then grabs specifically
ecam info from the segment hob along with other rb specific
information to create final RB info required by multi segment
PCI driver.
Additionally we would like to support legacy implementations which
rely on ACPIBoard HOB to fill up segment info. So if UplSegmentInfo Hob
is not found we try and look for other hob.
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
We need to let UEFI know that there are cetain memory types
which are special purpose (CXL/HBM) etc and we may want to
avoid using them for UEFI purposes. Hence UPL needs to know
about such memory types.
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
We do not need to go deep into verifying all ACPI tables
at this stage. TODO: Just a simple ACPI header signature
check should be good enough. For now just commenting out
asserts that mandate one to have various tables which is
not applicable to all platforms.
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
As per specification we are going to accept only one argument
at the entry point which is FDT pointer. Grab that and call
the entry point.
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
Option node provides info that is to be consumed by during
metadata creation for other nodes like root bridge; pci-enum-done
etc. Handle that dependency by storing option values in a variable
and then apply it during post processing. Ideally such cross node
dependency should be avoided in design. Scope for futher improvements.
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
Let APs wait until the BSP has completed the register updates to remove
the CPU. This makes sure all APs stay in SMM mode until the CPU
hot-unplug operation is complete, which in turn makes sure the ACPI lock
is released only after the CPU hot-unplug operation is complete.
Some background: The CPU hotplug SMI is triggered from an ACPI function
which is protected by an ACPI lock. The ACPI function is in the ACPI
tables generated by qemu.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently TDVF gets cpu count information via fw_cfg, but
this information can also be retrieved by calling of TdCall.TdInfo.
And TdCall is responded by tdx-module which is trust.
So, from the security perspective we shall use TdCall.Tdinfo instead
of fw_cfg.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
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>
Mike Beaton
Dhaval
Gerd Hoffmann
Ceping Sun
Pierre Gondois
Chun-Yi Lee
Leandro Becker
Ken Lautner
Oliver Smith-Denny
Taylor Beebe
Oliver Smith-Denny