Create a special OpensslLib implementation that only exposes the SM3
routines that MbedTlsLib borrows from OpensslLib, to avoid having to
pull in other parts of OpenSSL that are not needed (e.g., via the
library constructor)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
SM3 needs to be tested so we can verify that alternative implementations
(such as the one I will be contributing to BaseCryptLibMbedTls) as well
as the reference implementation produce the expected value.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The CLANG35 and CLANG38 toolchain specifiers have been phased out, and
replaced with CLANGDWARF. Update the MbedTls library definitions
accordingly.
While at it, switch to the gnu99 C dialect, which is a better match with
GCC in C99 mode, which includes GCC specific GNU extensions.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
In Python 3.12 invalid escape sequences in strings moved from
DeprecationWarning to SyntaxWarning
(ref https://docs.python.org/3/whatsnew/changelog.html#python-3-12-0-final
and search for gh-98401). In a future Python version this will become
SyntaxError.
Multiple instances of these SyntaxWarnings are currently printed when
running the BaseTools tests using Python 3.12 (though without actually
failing the affected tests).
This commit updates all lines which were causing this type of warning.
Typical examples which needed fixing are:
- "BaseTools\Source\Python" representing a path: "\S" and "\P" are invalid
escape sequences, therefore left unchanged, therefore the test works
(with a warning in Python 3.12). r"BaseTools\Source\Python" represents
the same string, but with escapes turned off completely thus no warning.
- Where '\t\s' is used as a regex pattern, then chr(9) + '\\s' is sent
to the regex parser (with a warning in Python 3.12) since '\s' is not a
valid Python escape sequence. This works correctly, though arguably for
the wrong reasons. r'\t\s' sends the same as '\\t\\s', as originally
intended and with no warning.
(Note that ' and " are not fundamentally different in Python.)
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
S3 performance table is saved to LockBox. Without LockBox, S3 performance
data will lost.
Add LOCKBOX_SUPPORT to optionally select LockBox libary instance,
default value is FALSE.
Signed-off-by: Zhou Jianfeng <jianfeng.zhou@intel.com>
Currently, FIT Payload data relocation data has
some minor error with Universal Payload
Specification v0.9.1 section 2.4.3.
Signed-off-by: Gua Guo <gua.guo@intel.com>
This patch is to sync RETURN_ERROR macro with the
MdePkg/Include/Base.h
Ref: 1a89d9887f MdePkg:Update Return Error Macro in Base.h
Fixing RETURN_ERROR macro.
It is causing problem in Coverity Static analysis tool
as we are directly converting the UINT value to INTN.
Changing value from UINT to INTN might cause problema
Here we know that the values would not be in loss of data.
To increase the code quality and increase the static tool
analysis score we have to change it
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Currently, TDX exposes MTRR CPUID bit to TDX VM. So based on the CPUID,
the guest software components (OVMF/TDVF and guest kernel) will access
MTRR MSRs. One problem for guest to use of MTRR is the change of MTRR
setting needs to set CR0.CD=1, which will case #VE for TDX.
For Linux kernel, there is a mechanism called SW defined MTRR introduced
by the patch https://lore.kernel.org/all/20230502120931.
20719-4-jgross@suse.com/. If this is integrated for TDX guest, then Linux
kernel will not access any MTRR MSRs.
So we update MtrrLibIsMtrrSupported() to always return false for TD-Guest,
then TDVF will not access MTRR MSRs at all.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Binbin Wu <binbin.wu@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
I intend to help with maintenance of the following Arm modules:
ArmPkg/
ArmPlatformPkg/
ArmVirtPkg/
MdePkg/Include/Library/ArmLib.h
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Adds X64 ACPI SSDT HPET table generator library.
Updates acpi standard table enum with hpet.
Generate ACPI HPET device as per specification.
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4848
This patch is to support VTUTF8 type for Putty function key map.
In Putty, it is required for translating a stream of Unicode characters
for function keys on UTF8 correctly.
Signed-off-by: Phil Noh <Phil.Noh@amd.com>
Clang insists on emitting a movt/movw pair into the function
pro/epilogues to load the stack protector reference value from memory,
and this movt/movw pair may turn out non-consecutively in the
instruction stream.
The resulting symbol reference cannot be fixed up by GenFw, as PE/COFF
always treats movt/movw as a pair, and the ELF-to-PE conversion will
therefore fail.
Just disable the stack protector when using CLANGDWARF.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
As a Tianocore maintainer, I am responsible for the packages that I
maintain, and am therefore expected to respond in a timely manner to
pull requests affecting those packages. With the updated GitHub-based
workflow, this now results in daily GitHub spam inviting me to respond
to each PR as they are created by the respective authors.
However, I strongly feel that with responsibility should come with
delegated authority as well, and this has been stripped away over the
past couple of years. When other maintainers fail to respond (which has
become more common recently), or when there are glitches in the CI, I no
longer have any means to take charge and correct the situation.
The upshot is that I am struggling to do my work as a maintainer,
spending 90% of my time dealing with GitHub CI technicalities, or being
blocked on other work that is completely ignored by the other
maintainers.
This is a waste of my time, and therefore, of my employer's money, so I
feel I can no longer justify my involvement. I am therefore stepping
down as a maintainer.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This patch is to avoid configure SMBASE if SmBase relocation has been
done. If gSmmBaseHobGuid found, means SmBase info has been relocated
and recorded in the SmBase array. No need to do the relocation in
SmmCpuFeaturesInitializeProcessor().
Signed-off-by: Phil Noh <Phil.Noh@amd.com>
ACPI FADT HW register interface fields are
optional but current UPL common entry code made it
as mandatory which caused compatibility issue on
some platforms.
Solution is to move those FADT HW register fields
check code to consumer code so only ASSERT when
those fields are consumed with error.
Currently only AcpiTimerLib and ResetSystemLib
consuming those register fields so if platforms
configured UPL to different library instances the
FADT HW register fields are not consumed thus will
not cause ASSERT.
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Move protocol interface version definition to public protocol header
file. So, driver can decide which version it is supported.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
For reasons that are unclear, the Linaro EDK2 CI is throwing errors when
building ArmCrashDumpDxe with CLANGDWARF, as the resulting build
contains non-adjacet MOVW/MOVT pairs, which cannot be relocated
correctly in PE/COFF.
Let's build it only for AARCH64 - its utility on ARM is doubtful anyway.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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>