Root cause:
1. Before DisableReadonlyPageWriteProtect() is called, the return
address (#1) is pushed in shadow stack.
2. CET is disabled.
3. DisableReadonlyPageWriteProtect() returns to #1.
4. Page table is modified.
5. EnableReadonlyPageWriteProtect() is called, but the return
address (#2) is not pushed in shadow stack.
6. CET is enabled.
7. EnableReadonlyPageWriteProtect() returns to #2.
#CP exception happens because the actual return address (#2)
doesn't match the return address stored in shadow stack (#1).
Analysis:
Shadow stack will stop update after CET disable (DisableCet() in
DisableReadOnlyPageWriteProtect), but normal smi stack will be
continue updated with the function called and return
(DisableReadOnlyPageWriteProtect & EnableReadOnlyPageWriteProtect),
thus leading stack mismatch after CET re-enabled (EnableCet() in
EnableReadOnlyPageWriteProtect).
According SDM Vol 3, 6.15-Control Protection Exception:
Normal smi stack and shadow stack must be matched when CET enable,
otherwise CP Exception will happen, which is caused by a near RET
instruction.
CET is disabled in DisableCet(), while can be enabled in
EnableCet(). This way won't cause the problem because they are
implemented in a way that return address of DisableCet() is
poped out from shadow stack (Incsspq performs a pop to increases
the shadow stack) and EnableCet() doesn't use "RET" but "JMP" to
return to caller. So calling EnableCet() and DisableCet() doesn't
have the same issue as calling DisableReadonlyPageWriteProtect()
and EnableReadonlyPageWriteProtect().
With above root cause & analysis, define below 2 macros instead of
functions for WP & CET operation:
WRITE_UNPROTECT_RO_PAGES (Wp, Cet)
WRITE_PROTECT_RO_PAGES (Wp, Cet)
Because DisableCet() & EnableCet() must be in the same function
to avoid shadow stack and normal SMI stack mismatch.
Note: WRITE_UNPROTECT_RO_PAGES () must be called pair with
WRITE_PROTECT_RO_PAGES () in same function.
Change-Id: I4e126697efcd8dbfb4887da034d8691bfca969e3
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
We would like any proposed change in the edk2 codebase to be
assignable to a human maintainer/reviewer. If there is a feature
for which there is no longer any support, we should find a way
to remove it from the head of the repository. For critical
features, we must find community members that are willing to
own it.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Updates the CodeQL queries opted into by edk2 to a set of queries from
the standard CodeQL query package `codeql/cpp-queries`.
After testing a large number of queries the included set here were
found to be the most useful with the least number of false positives.
Some queries had a number of issues that led to them being placed on
the exclusion list so that they are not considered in the future
without the notes there being taken into account.
General details about queries available in the pack are available here:
https://codeql.github.com/codeql-query-help/cpp/
The issues found by these queries will need to be fixed over time. In
the meantime, the results will show to those that have permission in
the repo's GitHub Code Scanning area. The build will not fail due to
CodeQL issues (since they are not all fixed) but that can be enabled in
the future.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Since a large number of CodeQL queries are being enabled to identify
issues that the community can collectively resolve, audit mode needs to
be enabled to prevent the build from failing.
In the future, this global audit mode can be disabled and individual
packages can enable/disable audit mode in their package CI YAML file
using the instructions in the CodeQL plugin readme.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Adds a workflow to run CodeQL against all packages built in
.pytool/CISettings.py. The following is done:
1. Determine which packages to build against. Those that support
are managed by .pytool/CISettings.py will be selected.
For each package:
2. Determine how to interact with the package. Such as whether
`stuart_ci_setup` or `stuart_setup` should be used.
3. Perform supported Stuart steps for setup and update.
4. Discover the CodeQL plugin directory in the repo.
5. Attempt to load the CodeQL CLI specific to the host OS from a
GitHub cache.
6. Perform the build.
7. Clean up some files after build to improve robustness.
8. Upload the CodeQL results (generated SARIF file) to GitHub Code
Scanning. The results will be associated with the trigger of the
workflow.
After each step that can upload logs such as the setup, update, and
build steps the logs are uploaded as an artifact to the workflow run.
This allows easy debugging in case there's an error in the step.
The SARIF file is also uploaded to the workflow run so it can be
downloaded and analyzed.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Adds a CodeQL plugin that supports CodeQL in the build system.
1. CodeQlBuildPlugin - Generates a CodeQL database for a given build.
2. CodeQlAnalyzePlugin - Analyzes a CodeQL database and interprets
results.
3. External dependencies - Assist with downloading the CodeQL CLI and
making it available to the CodeQL plugins.
4. CodeQlQueries.qls - A C/C++ CodeQL query set run against the code.
5. Readme.md - A comprehensive readme file to help:
- Platform integrators understand how to configure the plugin
- Developers understand how to modify the plugin
- Users understand how to use the plugin
Read Readme.md for additional details.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
CodeQL currently runs via the codeql-analysis.yml GitHub workflow
which uses the `github/codeql-action/init@v2` action (pre-build)
and the `github/codeql-action/analyze@v2` action (post-build) to
setup the CodeQL environment and extract results.
This infrastructure is removed in preparation for a new design that
will directly run the CodeQL CLI as part of the build. This will
allow CodeQL to be run locally as part of the normal build process
with results that match 1:1 with CI builds.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Automatically set the nxcompat flag in the DLL Characteristics field of
the Optional Header of the PE32+ image. For this flag to be set
automatically, the section alignment must be evenly divisible
by 4K (EFI_PAGE_SIZE) and no section must be executable and writable.
Adds a command line flag to GenFw, --nonxcompat, to ensure the
IMAGE_DLLCHARACTERISTICS_NX_COMPAT bit is not set, even if all
requirements are met. Updates the manual for GenFw to include the new
flag.
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: Joey Vagedes <joeyvagedes@gmail.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Add the bit masks for DLL Characteristics, used within the optional
header of a PE, to the PeImage.h header file.
Update the Visual Studio, Microsoft Portable Executable and Common
Object File Format Specification, and the PE/COFF Specification to the
latest version.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Allow .rtf files created by applications such as Notepad to be committed
as-is without further manual editing by skipping the requirements for
CRLF, no tabs and no trailing whitespace.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Laszlo Ersek <lersek@redhat.com>
If the system does not have ACPI setup use the configuration table
to get the performance info.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Install the performance table into the UEFI configuration table.
This will allow the shell application to get this if the system
is not using ACPI.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
According to the markdown language syntax, headings should be after
number signs (#). The number of number signs correspond to the heading
level.
But current PatchFvUserManual.md doesn't insert a space between the
number signs and the heading title, resulting the markdown file is not
rendered well in markdown viewers.
The patch doesn't change any content but only adds spaces to ensure
the headings are correctly recognized.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Duggapu Chinni B <chinni.b.duggapu@intel.com>
Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ted Kuo <ted.kuo@intel.com>
Reviewed-by: Ashraf Ali S <ashraf.ali.s@intel.com>
Cc: Susovan Mohapatra <susovan.mohapatra@intel.com>
When FSP runs in API mode, it saves the IDTR in its own stack then
switches to bootloader's stack before it returns from FspMemoryInit.
Next time when the bootloader calls TempRamExit, FSP switches to
its own stack and restores IDTR from its stack saved earlier.
However, due to a bug in BaseFspSwitchStackLib, the IDTR saved on
FSP's stack might be corrupted that results the following TempRamExit
call fails inside FSP due to PeiServices pointer cannot be retrieved
from IDT.base - 8.
The bug is the assembly code doesn't reserve 32 bytes before calling
the C routine in 64bit. According to the x86-64 calling convention,
caller is responsible for allocating 32 bytes of "shadow space" on the
stack right before calling the function (regardless of the actual
number of parameters used).
When FSP is built in optimization-off mode, the C routine makes use
of the 32-byte "shadow space" which is not reserved by the assembly
caller. That causes the IDTR saved on the stack is corrupted by the
C routine.
The patch fixes so by reserving the 32 bytes before calling C routine.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Duggapu Chinni B <chinni.b.duggapu@intel.com>
Cc: Ray Han Lim Ng <ray.han.lim.ng@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ted Kuo <ted.kuo@intel.com>
Reviewed-by: Ashraf Ali S <ashraf.ali.s@intel.com>
Cc: Susovan Mohapatra <susovan.mohapatra@intel.com>
The patch "f81ee47513e5 DynamicTablesPkg: Add an ET info
object parser" updates the Configuration Manager object
parser to add support for parsing CM_ARM_ET_INFO object.
However, the GicC info structure also has an ET Reference
token that points to the CM_ARM_ET_INFO object. Therefore,
update the GICC info object parser to add an entry to parse
the ET reference token. Without this change an assert
stating that the RemainingSize != 0 will be triggered.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: levi.yun <yeoreum.yun@arm.com>
There are two definitions for below functions in RedfishCrtLib.h. Create
this change to remote duplicated functions.
Function list: strcmp(), strncmp(), strncpy(), strcpy(), strcat(),
strlen(), strchr(), strcasecmp(), strstr(), memcmp(), memset(),
memcpy(), memchr(), memcmp() and memmove().
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Adds a GitHub workflow that uses the actions/stale GitHub action to
automatically leave notifications on and close PRs that have had no
activity for a long time.
Note: Modifications to a PR reset the staleness counter. This
includes pushing to the PR, adding a label to the PR,
commenting on the PR, etc.
If a PR has been marked "stale", simply leaving a comment will
reset the counter.
Configuration choices:
1. Do not attempt to close edk2 GitHub issues.
2. Mark edk2 PRs as stale if no activity in the last 60 days. Close
PRs marked stale if no further activity in 7 days.
3. Do not exempt PRs with a "push" label.
4. Run the check once daily. Allow manual runs from those that have
permission to run GitHub workflows.
5. Add the label "stale" to the PR when it enters the stale state.
Rationale:
1. We do not use issues often enough. The limited usage of GitHub
issues in Tianocore org GitHub projects are in another repo not
impacted by this workflow and expected to track long term tasks.
2. This is the default value. In non-edk2 projects, I've seen these
times work fairly well to identify PRs that have fallen stale.
3. Adding a "push" label resets the stale timer. If a PR has had a
"push" label for 60+ days and has not been fixed for submission,
then it is has very likely been abandoned.
4. This is sufficient to update PRs on the day granularity the
configuration settings are applied against.
5. The label makes it easy to filter stale PRs in the PR list and
write automation around PRs that are stale. It's also an obvious
visual identifier that a PR needs attention in the PR list.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Message-Id: <20231031014120.917-1-mikuback@linux.microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Since the code is most regularly tested in CI, distro/versioning
details are updated to match the latest CI configuration.
CI has moved from Ubuntu 18.04 to Ubuntu 22.04 since the time of the
file's creation, but the code is actually built in a Fedora container
so Fedora is mentioned as the primary build/test environment.
Updates the following information:
- Build OS: Fedora 37 Linux
- Supported Configuration: Additional DSCs added
- Python: 3.12.x
- Packaging Tool: dnf instead of apt
- Container Details: Added
- Primary Build Example: QemuBuild.py instead of PlatformBuild.py
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Message-Id: <20231030230902.849-1-mikuback@linux.microsoft.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: don't specify the number of supported firmware builds]
Adds the varpolicy EFI shell command to all DSC files that
currently include other dynamic shell commands from ShellPkg.
This command allows variable policies to be dumped in the EFI
shell for convenient auditing and debug.
Use the command in the EFI shell as follows:
- `"varpolicy"` dumps platform variables
- `"varpolicy -?"` shows help text
- `"varpolicy -b"` pages output as expected
- `"varpolicy -s"` shows accurate variable statistic information
- `"varpolicy -p"` shows accurate UEFI variable policy information
- `"varpolicy-v -b"` dumps all information including variable data hex dump
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Julien Grall <julien@xen.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Message-Id: <20231030203112.736-5-mikuback@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Adds the varpolicy EFI shell command to all DSC files that
currently include other dynamic shell commands from ShellPkg.
This command allows variable policies to be dumped in the EFI
shell for convenient auditing and debug.
Use the command in QEMU EFI shell as follows:
- `"varpolicy"` dumps platform variables
- `"varpolicy -?"` shows help text
- `"varpolicy -b"` pages output as expected
- `"varpolicy -s"` shows accurate variable statistic information
- `"varpolicy -p"` shows accurate UEFI variable policy information
- `"varpolicy-v -b"` dumps all information including variable data hex dump
Cc: Anatol Belski <anbelski@linux.microsoft.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jianyong Wu <jianyong.wu@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Message-Id: <20231030203112.736-4-mikuback@linux.microsoft.com>
Adds a new module (dynamic shell command) to ShellPkg that lists
variable policy information for all UEFI variables on the system.
Some other UEFI variable related functionality is also included to
give a greater sense of platform UEFI variable state. This command
is intended to help make variable policies more transparent and
easier to understand and configure on a platform.
Like all dynamic shell commands, a platform only needs to include
`VariablePolicyDynamicCommand.inf` in their flash image to have
the command registered in their UEFI shell.
Include the following lines in platform DSC (in DXE components section):
```
ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDynamicCommand.inf {
<PcdsFixedAtBuild>
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
}
```
Include the following line in platform FDF:
```
INF ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDynamicCommand.inf
```
A standalone UEFI application can also be built that uses the same
underlying functional code as the dynamic shell command.
The path to use in the DSC and FDF for the app:
```
ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyApp.inf
```
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20231030203112.736-3-mikuback@linux.microsoft.com>
Introduces two new APIs to EDKII_VARIABLE_POLICY_PROTOCOL:
1. GetVariablePolicyInfo()
2. GetLockOnVariableStateVariablePolicyInfo()
These allow a caller to retrieve policy information associated with
a UEFI variable given the variable name and vendor GUID.
GetVariablePolicyInfo() - Returns the variable policy applied to the
UEFI variable. If the variable policy is applied toward an individual
UEFI variable, that name can optionally be returned.
GetLockOnVariableStateVariablePolicyInfo() - Returns the Lock on
Variable State policy applied to the UEFI variable. If the Lock on
Variable State policy is applied to a specific variable name, that
name can optionally be returned.
These functions can be useful for a variety of purposes such as
auditing, testing, and functional flows.
Also fixed some variable name typos in code touched by the changes.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Message-Id: <20231030203112.736-2-mikuback@linux.microsoft.com>
Add PCD to control if modules with start addresses in PE/COFF > 0x100000
attempt to load at specified address.
If a module has an address in this range and there is untested memory
DxeCore will attempt to promote all memory to tested which bypasses any
memory testing that would occur later in boot.
There are several existing AARCH64 option roms that have base addresses
of 0x180000000.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
Message-Id: <bd36c9c24158590db2226ede05cb8c2f50c93a37.1684194452.git.jbrasen@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The CpcToken has been incorrectly referenced in the
CreateTopologyFromGicC() and always points to the
CPC token in the first GICC Info object.
Therefore, fix this by correctly indexing into the
GicCInfo object array.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
The Coresight Embedded Trace Extension (ETE) feature
can be detected by the platform firmware by examining
the debug feature register ID_AA64DFR0_EL1.TraceVer
field.
The platform configuration manager can then describe
the ETE by creating CM_ARM_ET_INFO object(s) and
referencing these in CM_ARM_GICC_INFO.EtToken.
The 'Table 3: Compatible IDs for architected
CoreSight components' in the 'ACPI for CoreSight
1.2 Platform Design Document' specifies the HID
value for Coresight ETE and CoreSight Embedded
Trace Macrocell (ETM) v4.x as ARMH C500.
Therefore, update the SsdtCpuTopologyGenerator
to add an ETE device to the CPU node in the AML
CPU hierarchy so that an OS can utilise this
information.
Note: Although ETE and ETM share the same HID,
ETE has a system register interfaces, unlike
ETM which requires memory mapped registers.
Since this patch aims to support ETE, the AML
description does not describe any memory mapped
registers. However, support for ETM can be
added in the future.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
An Embedded Trace (ET) info object is used to provide
information about an Embedded Trace Extension (ETE) or
an Embedded Trace Module (ETM) available on a platform.
The CM_ARM_ET_INFO object has already been added to the
Arm namespace objects list by a previous patch.
Therefore, update the CM Object parser to add support
for parsing the CM_ARM_ET_INFO object.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Add an Embedded Trace (ET) info object that can be
used to provide information about Embedded Trace
Extension (ETE) or Embedded Trace Module (ETM)
available on a platform.
Although ETE and ETM share the same HID,
ETE has a system register interfaces, unlike
ETM which requires memory mapped registers.
Since this patch aims to support ETE it does
not describe any memory mapped registers.
However, required support for ETM can be added
in the future.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
ACPI 6.5 introduces a new filed to the MADT GICC
structure to specify the TRBE interrupt. The TRBE
interrupt is a Processor Private interrupt (PPI)
and is used to specify a platform-specific
interrupt to signal TRBE events.
Therefore, update the MADT GICC structure parser
to parse the new TRBE interrupt field. Also, add
validations to check that the TRBE interrupt is
within the PPI interrupt range.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
The ACPI 6.5 specification updates the minor revision
of the FADT table to 5. Therefore, update the FADT
generator to setup the minor revision for ACPI 6.5.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
The ACPI 6.5 specification updates the MADT table to add
a new field to GICC for specifying the TRBE interrupt and
also adds support for Online Capable flag to the GICC flags.
The Online Capable flags should be passed transparently
through as specified in the CM_ARM_GICC_INFO.Flags field
and only require the MADT table revision to be setup to
6 to reflect the ACPI 6.5 specification.
The TRBE field needs to be appropriately setup in the
GICC structure.
Therefore, update the MADT generator to reflect the
above updates required for supporting ACPI 6.5
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
ACPI 6.5 introduces a new filed to the MADT GICC structure
to specify the Trace Buffer Extension (TRBE) interrupt. The
TRBE interrupt is a Processor Private interrupt (PPI) and is
used to specify a platform-specific interrupt to signal TRBE
events.
This field has already been added to the CM_ARM_GICC_INFO
structure in a previous patch.
Therefore, update the Configuration Manager Object Parser to
reflect the addition of the TRBE interrupt field.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
ACPI 6.5 introduces a new filed to the MADT GICC structure
to specify the Trace Buffer Extension (TRBE) interrupt. The
TRBE interrupt is a Processor Private interrupt (PPI) and is
used to specify a platform-specific interrupt to signal TRBE
events.
Therefore, update the CM_ARM_GICC_INFO to reflect the addition
of the TRBE interrupt field.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
The ASWG ECR 2303 introduces a new field 'TRBE
interrupt' to GICC structure in ACPI 6.5.
The Trace Buffer Extension (TRBE) interrupt is a
Processor Private interrupt (PPI) and is used to
specify a platform-specific interrupt to signal
TRBE events.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Bugzilla: 3706 'Code First - MADT GICC new flags'
On ARM systems physical CPU hotplug is not supported.
All CPUs are considered present and this is true
throughout the system uptime.
The ECR 2285 introduces a new 'online-capable' flag
in the GICC structure flags in ACPI 6.5, to signal
firmware policy (CPU is not enabled but it can be
enabled and onlined). This enables OSPM to support
virtual CPU hotplug (on virtual platforms for
instance).
This ECR also updates the MADT table revision to 6
to reflect the ACPI 6.5 changes. Therefore, update
the MADT table revision to match the value as
specified in ACPI 6.5.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
For the RELEASE target, all ArmVirtPkg DSCs inherit BaseDebugLibNull from
"ArmVirt.dsc.inc"; keep that.
For NOOPT and DEBUG:
- switch the lib class resolution pair (BaseDebugLibSerialPort +
FdtPL011SerialPortLib) that is set as the default for all module types
in "ArmVirt.dsc.inc" to DebugLibFdtPL011UartRam;
- switch the lib class resolution pair (BaseDebugLibSerialPort +
EarlyFdtPL011SerialPortLib) that is set as an override for SEC,
PEI_CORE, PEIM modules in "ArmVirt.dsc.inc" to
DebugLibFdtPL011UartFlash;
- switch the lib class resolution pair (DxeRuntimeDebugLibSerialPort +
FdtPL011SerialPortLib) that is set as an override for DXE_RUNTIME_DRIVER
modules in "ArmVirt.dsc.inc" to DxeRuntimeDebugLibFdtPL011Uart;
- mask all of the above DebugLib class resolution changes in
"ArmVirtKvmTool.dsc", because "ArmVirtKvmTool.dsc" uses
BaseSerialPortLib16550 rather than PL011 UARTs,
- mask all of the above DebugLib class resolution changes in
"ArmVirtXen.dsc" too, because "ArmVirtXen.dsc" uses
XenConsoleSerialPortLib rather than PL011 UARTs.
I regression-tested this change for "ArmVirtKvmTool.dsc" and
"ArmVirtXen.dsc" by building them for both DEBUG and RELEASE, both before
the patch and after, and comparing the edk2 build report files (focusing
on lib class resolutions). There are no changes.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-10-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce three new DebugLib instances, forked from
MdePkg/Library/BaseDebugLibSerialPort. All three instances rely on
PL011UartLib rather than SerialPortLib so that they can customize the
PL011 UART that the debug messages are written to. All three instances
direct the debug output to the first such PL011 UART that *differs* from
the one specified in the Device Tree's /chosen node's "stdout-path"
property.
From these, DxeRuntimeDebugLibFdtPL011Uart is identical to
DebugLibFdtPL011UartRam, with the addition that UART access is permanently
disabled when the containing DXE_RUNTIME_DRIVER module is notified about
exiting boot services.
The contexts in which these DebugLib instances run are identical to those
in which the corresponding SerialPortLib instances run. The particular
original dependency chain is
DxeRuntimeDebugLibSerialPort (DXE_RUNTIME_DRIVER)
FdtPL011SerialPortLib
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
and the new dependency chain is
DxeRuntimeDebugLibFdtPL011Uart (DXE_RUNTIME_DRIVER)
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
The ArmVirtPkg DSC files will be switched to the new library instances in
a separate patch.
This patch is worth viewing with "git show --find-copies-harder".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-9-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce three new DebugLib instances, forked from
MdePkg/Library/BaseDebugLibSerialPort. All three instances rely on
PL011UartLib rather than SerialPortLib so that they can customize the
PL011 UART that the debug messages are written to. All three instances
direct the debug output to the first such PL011 UART that *differs* from
the one specified in the Device Tree's /chosen node's "stdout-path"
property.
From these, DebugLibFdtPL011UartRam mirrors FdtPL011SerialPortLib: it
relies on the EarlyPL011BaseAddress GUID HOB, and initializes the UART --
a UART different from FdtPL011SerialPortLib's -- only once in the lifetime
of the containing module. Suitable for module types that can only execute
from RAM (i.e., all types different from SEC, PEI_CORE, PEIM), except
DXE_RUNTIME_DRIVER.
(Note that OVMF uses a similar set of dedicated DebugLib instances
(PlatformDebugLibIoPort) for logging to the (x86-only) isa-debugcon device
from various firmware phases.)
The contexts in which these DebugLib instances run are identical to those
in which the corresponding SerialPortLib instances run. The particular
original dependency chain is
BaseDebugLibSerialPort (not SEC, PEI_CORE, PEIM, DXE_RUNTIME_DRIVER)
FdtPL011SerialPortLib
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
and the new dependency chain is
DebugLibFdtPL011UartRam (not SEC, PEI_CORE, PEIM, DXE_RUNTIME_DRIVER)
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
Note that FdtPL011SerialPortLib remains in use (just not via
BaseDebugLibSerialPort); for instance by MdeModulePkg/Universal/SerialDxe,
which produces the SerialIo protocol, underlying the UEFI console.
The ArmVirtPkg DSC files will be switched to the new library instances in
a separate patch.
This patch is worth viewing with "git show --find-copies-harder".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-8-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce three new DebugLib instances, forked from
MdePkg/Library/BaseDebugLibSerialPort. All three instances rely on
PL011UartLib rather than SerialPortLib so that they can customize the
PL011 UART that the debug messages are written to. All three instances
direct the debug output to the first such PL011 UART that *differs* from
the one specified in the Device Tree's /chosen node's "stdout-path"
property.
From these, DebugLibFdtPL011UartFlash mirrors EarlyFdtPL011SerialPortLib:
it parses the initial Device Tree, and initializes the UART -- a UART
different from EarlyFdtPL011SerialPortLib's -- for every message written.
Suitable for SEC, PEI_CORE, PEIM.
(Note that OVMF uses a similar set of dedicated DebugLib instances
(PlatformDebugLibIoPort) for logging to the (x86-only) isa-debugcon device
from various firmware phases.)
The contexts in which these DebugLib instances run are identical to those
in which the corresponding SerialPortLib instances run. The particular
original dependency chain is
BaseDebugLibSerialPort (SEC, PEI_CORE, PEIM)
EarlyFdtPL011SerialPortLib
PcdDeviceTreeInitialBaseAddress
FdtSerialPortAddressLib
PL011UartLib
and the new dependency chain is
DebugLibFdtPL011UartFlash (SEC, PEI_CORE, PEIM)
PcdDeviceTreeInitialBaseAddress
FdtSerialPortAddressLib
PL011UartLib
Note that EarlyFdtPL011SerialPortLib remains in use (just not via
BaseDebugLibSerialPort), namely for direct SerialPortLib calls from SEC,
PEI_CORE, PEIM. See for example commit 56035d1c8b
("ArmPlatformPkg/PrePeiCore: Print the firmware version early in boot",
2022-10-25).
The ArmVirtPkg DSC files will be switched to the new library instances in
a separate patch.
This patch is worth viewing with "git show --find-copies-harder".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-7-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
PlatformPeiLib produces the EarlyPL011BaseAddress GUID HOB, and
FdtPL011SerialPortLib consumes it. Extend the HOB such that it also carry
the base address of the PL011 UART meant for DebugLib usage -- namely the
first UART that is *not* designated by the /chosen node's "stdout-path"
property. Implement this policy in PlatformPeiLib.
Note that as far as the SerialPortLib+console UART is concerned, this
patch makes no difference. That selection remains consistent with the
pre-patch state, and therefore consistent with EarlyFdtPL011SerialPortLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-6-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Convert both EarlyFdtPL011SerialPortLib and PlatformPeiLib at the same
time to clients of FdtSerialPortAddressLib (so that both "early" and
"late" serial output continue going to a common serial port). If the
device tree specifies just one serial port, this conversion makes no
difference, but if there are multiple ports, the output is written to the
port identified by /chosen "stdout-path".
In this patch, DebugLib output is not separated yet from the UEFI console.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-5-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
I strongly dislike when *small* local variable declaration changes are
muddled by whitespace changes. When that happens, a reviewer can choose
from two suboptimal options: display the patch with "git show -b", which
creates confusion in *other* parts of the patch, or display the patch with
just "git show", which then produces an unjustifiedly large hunk for the
sequence of declarations.
For avoiding that in subsequent patches, adjust some whitespace in this
patch in isolation. Functionally this is a no-op; "git show -b" produces
empty output.
Note that uncrustify is (of course) unhappy with this patch, but that's
fine -- this patch is in the middle of a series, and by the end of the
series (which is where uncrustify is run in CI) the whitespace is going to
be tight.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce a new library class + instance for:
- collecting serial port base addresses from the device tree,
- collecting the /chosen stdout-path serial port base address from the
device tree.
The logic is loosely based on the following functions:
- SerialPortGetBaseAddress()
[ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c]
- PlatformPeim() [ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c]
- GetSerialConsolePortAddress()
[ArmVirtPkg/Library/Fdt16550SerialPortHookLib/EarlyFdt16550SerialPortHookLib.c]
which are going to be converted to clients of the new library later.
Copyright notices from those other files are preserved.
The new library fixes the following warts, found by reading the existent
code:
- Neither of the three functions check whether the "reg" property exists.
(This may be implicitly checked when they compare the property size to
16.)
- GetSerialConsolePortAddress() uses ScanMem8() for locating a colon (":")
node path separator in "stdout-path", when AsciiStrStr() could work just
as fine. While ScanMem8() is likely faster, "stdout-path" is presumably
very short, and ScanMem8() introduces an extra lib class dependency
(namely BaseMemoryLib).
- If ScanMem8() fails to locate a colon in "stdout-path", then
GetSerialConsolePortAddress() re-measures the length of the whole
"stdout-path" property. This is conceptually (if not performance-wise)
disturbing, because we know the whole size of the "stdout-path" property
from the property lookup just before, so we only need to subtract the
NUL-terminator for learning the length.
- GetSerialConsolePortAddress() does not check if the first (or only) node
path inside the "stdout-path" property is empty. (Not a big deal, the
subsequent alias resolution should simply fail.)
- GetSerialConsolePortAddress() does not verify if the node path retrieved
(and potentially alias-resolved) from "stdout-path" can be located in
the device tree; it assumes it.
- Code is duplicated (of course) between SerialPortGetBaseAddress() and
PlatformPeim(), but more surprisingly, all three functions embed the
same code for verifying the "status" property of the serial port node,
and for checking and reading its "reg" property.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-2-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Aim:
- To solve the assertion that checks if CpuMpData->FinishedCount
equals (CpuMpData->CpuCount - 1). The assertion arises from a timing
discrepancy between the BSP's completion of startup signal checks and
the APs' incrementation of the FinishedCount.
- This patch also ensures that "finished" reporting from the APs is as
later as possible.
More specifially:
In the SwitchApContext() function, the BSP trigers
the startup signal and check whether the APs have received it. After
completing this check, the BSP then verifies if the FinishedCount is
equal to CpuCount-1.
On the AP side, upon receiving the startup signal, they invoke
SwitchContextPerAp() and increase the FinishedCount to indicate their
activation. However, even when all APs have received the startup signal,
they might not have finished incrementing the FinishedCount. This timing
gap results in the triggering of the assertion.
Solution:
Instead of assertion, use while loop to waits until all the APs have
incremented the FinishedCount.
Fixes: 964a4f032d
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <20231025114216.2824-1-yuanhao.xie@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
- Add new interfaces to return HTTP headers back to caller.
New interfaces are: getUriFromServiceEx(), patchUriFromServiceEx(),
postUriFromServiceEx() and putUriFromServiceEx().
- Fix compile error in payload.c
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Add two new interface: RedfishServiceInPayload() and RedfishPutToUri()
for Redfish HTTP protocol implementation. Fix several typos and add
missing JsonLib in INF file.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
The PLDM protocol uses Request bit to help differentiate between PLDM
request and response messages.
Currently the Pldm.h header only have a flag for the request message.
Add a flag for the response message as well.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Correct MCTP_TRANSPORT_HEADER structure field 'SourceEndpointIdId' to
'SourceEndpointId'.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Checking the max cpuid leaf is not enough to figure whenever
CPUID_V2_EXTENDED_TOPOLOGY is supported. Intel SDM says:
Software must detect the presence of CPUID leaf 1FH by verifying
(a) the highest leaf index supported by CPUID is >= 1FH, and
(b) CPUID.1FH:EBX[15:0] reports a non-zero value.
The same is true for CPUID leaf 0BH.
This patch adds the EBX check to GetProcessorLocation2ByApicId(). The
patch also fixes the existing check in GetProcessorLocationByApicId() to
be in line with the spec by looking at bits 15:0. The comments are
updated with a quote from the Intel SDM.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2241388
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20231017112807.1244254-1-kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:
(1) calls LibRtcInitialize(),
(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own similarly-named functions -- where those
functions wrap the corresponding RealTimeClockLib APIs,
(3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
interface.
Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
II-9.7.2.7.
However, this means that LibRtcInitialize() (of any RealTimeClockLib
instance) should not itself (a) set the GetTime(), SetTime(),
GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
overwritten in step (2) anyway, and step (3) will uselessly install a
second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
protocol database. (The protocol only serves to notify the DXE Foundation
about said runtime services being available.)
Clean up ArmPlatformPkg/PL031RealTimeClockLib accordingly (it only has
code that's redundant for step (3); it does not try to set "gRT" fields).
(Note that the lib instance INF file already does not list
gEfiRealTimeClockArchProtocolGuid.)
Tested with ArmVirtQemu.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231020121748.44862-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
[lersek@redhat.com: shorten patch subject line]
Reference: https://github.com/tianocore/edk2/pull/4892
BmExpandPartitionDevicePath is called to expand "short-form" device paths
which are commonly used with OS boot options. To expand a device path, it
calls EfiBootManagerConnectAll to connect all the possible BlockIo
devices in the system to search for a matching partition. However, this
is sometimes unnecessary on certain platforms (such as OVMF/QEMU) because
the boot devices are previously explicity connected
(See: ConnectDevicesFromQemu). EfiBootManagerConnectAll calls are
extremely costly in terms of boot time and resources and should be avoided
whenever feasible.
(
OVMF call tree:
PlatformBootManagerAfterConsole() [OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c]
PlatformBdsConnectSequence() [OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c]
ConnectDevicesFromQemu() [OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c]
...
EfiBootManagerRefreshAllBootOption() [MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c]
...
SetBootOrderFromQemu() [OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c]
Match() [OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c]
EfiBootManagerGetLoadOptionBuffer() [MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c]
BmGetNextLoadOptionBuffer() [MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c]
BmGetNextLoadOptionDevicePath() [MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c]
BmExpandPartitionDevicePath() [MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c]
)
Therefore optimize BmExpandPartitionDevicePath to first search the
existing BlockIo handles for a match. If a match is not found, then
fallback to the original code to call EfiBootManagerConnectAll and search
again. Thus, this optimization should be extremely low-risk given the
fallback to previous behavior.
NOTE: The existing optimization in the code to use a "HDDP" variable to
save the last matched device paths does not cover the first time a boot
option is expanded (i.e. before the "HDDP" is created) nor when the device
configuration has changed (resulting in the boot device moving to a
different location in the PCI Bus/Dev hierarchy). This new optimization
covers both of these cases on requisite platforms which explicity connect
boot devices.
In our testing on OVMF/QEMU VMs with dozens of configured vnic devices,
these extraneous calls to EfiBootManagerConnectAll from
BmExpandPartitionDevicePath were found to cause many seconds (or even
minutes) of additional VM boot time in some cases - due to the vnics
being unnecessarily connected.
Cc: Zhichao Gao zhichao.gao@intel.com
Cc: Ray Ni ray.ni@intel.com
Signed-off-by: Aaron Young <aaron.young@oracle.com>
Message-Id: <20231010150644.37857-1-Aaron.Young@oracle.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
[lersek@redhat.com: add OVMF call tree to commit message]
- It is expected that caller receives EFI_NO_MAPPING status
when call issues Configure() to unconfigured network interface.
Remove this false alarm in GetSubnetInfo() function.
- Fix typos
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Add debug prints to show HII option name when assert happens.
This helps developer to debug assert issue easily while Redfish
failed to convert HII value to Redfish value.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Adds a PrEval entry to the package's ci.yaml file which is used to
verify if the package uses a particular library instance when that
library instance file (INF) is updated.
When a library instance file (INF) is updated, PrEval will review each
package's DSC as described in the ci.yaml file to determine if the
package uses said library instance. If the package does use the library
instance, it will be built and tested to ensure the package is not
broken from the change.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Adds a PrEval entry to the package's ci.yaml file which is used to
verify if the package uses a particular library instance when that
library instance file (INF) is updated.
When a library instance file (INF) is updated, PrEval will review each
package's DSC as described in the ci.yaml file to determine if the
package uses said library instance. If the package does use the library
instance, it will be built and tested to ensure the package is not
broken from the change.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Adds a PrEval entry to the package's ci.yaml file which is used to
verify if the package uses a particular library instance when that
library instance file (INF) is updated.
When a library instance file (INF) is updated, PrEval will review each
package's DSC as described in the ci.yaml file to determine if the
package uses said library instance. If the package does use the library
instance, it will be built and tested to ensure the package is not
broken from the change.
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Adds a PrEval entry to the package's ci.yaml file which is used to
verify if the package uses a particular library instance when that
library instance file (INF) is updated.
When a library instance file (INF) is updated, PrEval will review each
package's DSC as described in the ci.yaml file to determine if the
package uses said library instance. If the package does use the library
instance, it will be built and tested to ensure the package is not
broken from the change.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Abner Chang <abner.chang@amd.com
Adds a PrEval entry to the package's ci.yaml file which is used to
verify if the package uses a particular library instance when that
library instance file (INF) is updated.
When a library instance file (INF) is updated, PrEval will review each
package's DSC as described in the ci.yaml file to determine if the
package uses said library instance. If the package does use the library
instance, it will be built and tested to ensure the package is not
broken from the change.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Adds a PrEval entry to the package's ci.yaml file which is used to
verify if the package uses a particular library instance when that
library instance file (INF) is updated.
When a library instance file (INF) is updated, PrEval will review each
package's DSC as described in the ci.yaml file to determine if the
package uses said library instance. If the package does use the library
instance, it will be built and tested to ensure the package is not
broken from the change.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Daniel Schaefer <git@danielschaefer.me>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Adds a PrEval entry to the package's ci.yaml file which is used to
verify if the package uses a particular library instance when that
library instance file (INF) is updated.
When a library instance file (INF) is updated, PrEval will review each
package's DSC as described in the ci.yaml file to determine if the
package uses said library instance. If the package does use the library
instance, it will be built and tested to ensure the package is not
broken from the change.
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Adds a PrEval entry to the package's ci.yaml file which is used to
verify if the package uses a particular library instance when that
library instance file (INF) is updated.
When a library instance file (INF) is updated, PrEval will review each
package's DSC as described in the ci.yaml file to determine if the
package uses said library instance. If the package does use the library
instance, it will be built and tested to ensure the package is not
broken from the change.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Yi Li <yi1.li@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Yi Li <yi1.li@intel.com>
Adds a PrEval entry to the package's ci.yaml file which is used to
verify if the package uses a particular library instance when that
library instance file (INF) is updated.
When a library instance file (INF) is updated, PrEval will review each
package's DSC as described in the ci.yaml file to determine if the
package uses said library instance. If the package does use the library
instance, it will be built and tested to ensure the package is not
broken from the change.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
AmlCodeGenRdQWordMemory's and AmlCodeGenRdDWordMemory's Cacheable
and MemoryRangeType parameters treat specific values as having
specific meanings as defined by the spec. This change adds enums to map
those meanings to their corresponding values.
Signed-off-by: Jeshua Smith <jeshuas@nvidia.com>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch enhances error handling and reporting in the CM ObjectParser.
Specifically:
1. ObjectIDs used as array indexes are checked for being out of bounds,
and if so an error message is printed before the assert.
2. An error message is printed for unsupported NameSpaceIDs.
3. Adds support for unimplemented parsers by allowing IDs to list a
NULL parser, resulting in an unimplemented message being printed.
Signed-off-by: Jeshua Smith <jeshuas@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This fixes two bugs and adds some enhancements to the handling of
characters and strings in objects being printed by the CM ObjectParser.
Bug fixes:
1. PrintOemID() currently attempts to print characters with "%C",
but the correct syntax is (lowercase) "%c". This bug results in
"CCCCCC" being printed instead of the actual ASCII characters.
2. PrintString() is being passed a pointer to data in objects, but in
some cases this data is the actual string to print and other cases
it is a pointer to the string to print. This adds a PrintStringPtr
function and uses the correct functions depending on the situation.
Enhancements:
1. Some objects contain ASCII characters, which are currently printed
as their hex values. This adds functions to print out ASCII
character fields as text rather than hex, and uses those functions in
several cases where the object data is defined to be ASCII.
2. The PrintOemID() function is replaced with the new identical but more
generecically-named PrintChar6() function.
Signed-off-by: Jeshua Smith <jeshuas@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Referring to a file relative to a regular file makes no sense (or at least
it cannot be implemented consistently with how a file is referred to
relative to a directory). VirtioFsSimpleFileOpen() has enforced this
strictly since the beginning, and a few months ago I reported USWG Mantis
ticket #2367 [1] too, for clearing up the related confusion in the UEFI
spec.
Unfortunately, the shim boot loader contains such a bug [2] [3]. I don't
believe the shim bug is ever going to be fixed. We can however relax the
check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
opened relative to a regular file is absolute, then the base file is going
to be ignored anyway, so we can let the caller's bug slide. This happens
to make shim work.
Why this matters: UEFI-bootable Linux installer ISOs tend to come with
shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes you
want to build upstream shim/grub binaries, but boot the same ISO
otherwise. The fastest way for overriding the ESP for this purpose is to
copy its original contents to a virtio filesystem, then overwrite the shim
and grub binaries from the host side. Note that this is different from
direct-booting a kernel (via fw_cfg); the point is to check whether the
just-built shim and grub are able to boot the rest of the ISO.
[1] https://mantis.uefi.org/mantis/view.php?id=2367
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1966973
[3] https://github.com/rhboot/shim/issues/382
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231018172434.91280-1-lersek@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
The RealTimeClockLib class header in edk2 mistakenly declares a function
called LibRtcVirtualNotifyEvent(). No component ever calls this function
crossing module boundaries; all RealTimeClockLib instances in edk2 and
edk2-platforms are supposed to register (and do register) their
SetVirtualAddressMap() notification functions.
At this point, the word "LibRtcVirtualNotifyEvent" no longer occurs in any
of edk2, edk2-platforms, even edk2-non-osi, except the library class
header proper. Remove the LibRtcVirtualNotifyEvent() function declaration.
Build-tested only (with "EmbeddedPkg.dsc").
Cc: Abner Chang <abner.chang@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231012091057.108728-6-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The RealTimeClockLib class header in edk2 mistakenly declares a function
called LibRtcVirtualNotifyEvent(). No component ever calls this function
crossing module boundaries; all RealTimeClockLib instances in edk2 and
edk2-platforms are supposed to register (and do register) their
SetVirtualAddressMap() notification functions.
In particular, VirtualRealTimeClockLib *itself* doesn't even use
LibRtcVirtualNotifyEvent() -- the function is defined with an empty body,
clearly in an understandable, but misguided, attempt, to conform to the
(bogus) library interface. Remove the function.
Build-tested only (with "RiscVVirtQemu.dsc").
Cc: Abner Chang <abner.chang@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231012091057.108728-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The RealTimeClockLib class header in edk2 mistakenly declares a function
called LibRtcVirtualNotifyEvent(). No component ever calls this function
crossing module boundaries; all RealTimeClockLib instances in edk2 and
edk2-platforms are supposed to register (and do register) their
SetVirtualAddressMap() notification functions.
In particular, TemplateRealTimeClockLib *itself* doesn't even use
LibRtcVirtualNotifyEvent() -- the function is defined with an empty body,
clearly in an understandable, but misguided, attempt, to conform to the
(bogus) library interface. Remove the function.
Build-tested only (with "EmbeddedPkg.dsc").
Cc: Abner Chang <abner.chang@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231012091057.108728-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The RealTimeClockLib class header in edk2 mistakenly declares a function
called LibRtcVirtualNotifyEvent(). No component ever calls this function
crossing module boundaries; all RealTimeClockLib instances in edk2 and
edk2-platforms are supposed to register (and do register) their
SetVirtualAddressMap() notification functions.
Rename LibRtcVirtualNotifyEvent() to VirtualNotifyEvent(), and make it
static, in preparation for removing the LibRtcVirtualNotifyEvent()
declaration from the lib class header later.
Build- and boot-tested with ArmVirtQemu.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231012091057.108728-3-lersek@redhat.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
PcatRealTimeClockRuntimeDxe seems to have copied the interface name
LibRtcVirtualNotifyEvent() from EmbeddedPkg's RealTimeClockLib class.
That's not right, for two reasons:
- PcatRealTimeClockRuntimeDxe doesn't consume "EmbeddedPkg.dec" in the
first place,
- in EmbeddedPkg, the RealTimeClockLib class API
LibRtcVirtualNotifyEvent() is about to be eliminated (it's a bogus API).
Rename the LibRtcVirtualNotifyEvent() function to VirtualNotifyEvent(),
and make it static.
Tested with booting OVMF.
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231012091057.108728-2-lersek@redhat.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Introduce PCD PcdRedfishSendReceiveTimeout to RedfishDiscoverDxe
driver. The SendReceiveTimeout is hard-code value in Redfish discover
driver. With this PCD, platform owner can configure timeout value
easily.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Add EFI_NOT_READY return if the CPU can not be enabled because the
processor is already on.
This can occur in normal use if the CPU is still being turned off from
a previous call when this is called again.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Introduce a PCD to control the maximum SATP mode that MMU allowed
to use. This PCD helps RISC-V platform set bare or minimum SATP mode
during bring up to debug memory map issue.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Dhaval Sharma <dhaval@rivosinc.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
This patch fixes wrong condition because of UINT16 value to integer
promotion. NumberMcFilters is UINT16 value, so when bitwise shift operator
applied to small integer type, the operation is preceded by integral
promotion. This is described in MISRA-C:2004 guideline as Rule 10.5:
"If the bitwise operators ~ and << are applied to an operand of underlying
type unsigned char or unsigned short, the result shall be immediately cast
to the underlying type of the operand."
A simple fix for this issue would be the following:
if ((UINT16)(UsbEthFunDescriptor.NumberMcFilters << 1) == 0)
But this patch proposes to use bitwise AND operation with a proper bit mask
rather than shifting to prevent similar mistakes in future.
Cc: Richard Ho <richardho@ami.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Old implementation of RefreshMemoryAttributesFromMtrr directly
retrieves the MTRR register content and applies the MTRR cache type
to GCD database following the precedence order defined by SDM.
The code can updated to simply get all the memory cache types for all
memory through newly introduced API With the new introduced API
MtrrGetMemoryAttributesInMtrrSettings.
Benefits:
1. Remove the duplicated logic in CpuDxe driver that handles MTRR
details.
2. Let the MtrrLib to handle the case when fixed MTRR is absent.
(Old logic cannot handle the case.)
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
MtrrGetMemoryAttributesInMtrrSettings parses the MTRR settings
either from hardware or from the parameter and returns an
array containing the memory cache types of all memory addresses.
This API could elinimate the needs of following APIs:
1. MtrrGetMemoryAttributeInVariableMtr
2. MtrrGetFixedMtrr
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update APIs related to set memory attributes to handle the fixed MTRR
is not always supported.
There are 3 APIs in MtrrLib that can set memory attributes:
1. MtrrSetMemoryAttributesInMtrrSettings
2. MtrrSetMemoryAttributeInMtrrSettings
3. MtrrSetMemoryAttribute
The general idea applied in MtrrSetMemoryAttributesInMtrrSettings is:
1. MtrrLibPreMtrrChange saves the old MTRR default type which
contains bit to enable fixed MTRR.
2. Main logic in MtrrSetMemoryAttributesInMtrrSettings applies
memory attribute settings for below 1MB to variable MTRRs
if fixed MTRR is not supported.
3. MtrrLibPostMtrrChange unconditionally sets E bit in MTRR default
type MSR but only set FE bit when fixed MTRRs are modified.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The patch fixes the following issues in the original implementation:
1. MtrrSetting contains random value if MTRR is not supported.
2. Unconditionally access fixed MTRR on CPU that may not support
fixed MTRR.
3. The maximum number of Variable MTRR entries are initialized, while
the portion exceeding the maximum number remains uninitialized.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update UnitTestMtrrGetDefaultMemoryType for the case the when Fixed
MTRRs are not supported.
The original implementation returns FALSE when either fixed MTRR isn't
supported or the number of variable MTRRs is 0. The correct behavior
should return FALSE only when both fixed MTRR isn't supported and the
number of variable MTRRs is 0.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update UnitTestGetFirmwareVariableMtrrCount for the case the when
Fixed MTRRs are not supported.
The original implementation returns FALSE when either fixed MTRR isn't
supported or the number of variable MTRRs is 0. The correct behavior
should return FALSE only when both fixed MTRR isn't supported and the
number of variable MTRRs is 0.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The previous implementation returns FALSE if either fixed MTRR is
unsupported or the number of variable MTRRs is 0. The correct behavior
is to return FALSE only when both fixed MTRR is unsupported and the
number of variable MTRRs is 0.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Trying to configure the TLS ciphers can lead to TLS handshake failures
because TlsCipherMappingTable is not in line with the ciphers actually
supported by OpensslLib.
Fix that by removing TlsCipherMappingTable altogether. Use
SSL_get_ciphers() instead to get the stack of ciphers supported by
openssl. Name and ID of the ciphers can be queried using the
SSL_CIPHER_get_name() and SSL_CIPHER_get_protocol_id() functions,
which allows us to map IDs to names without a hard-code table.
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2541
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20231004092003.3809321-1-kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Yi Li <yi1.li@intel.com>
FdtPL011SerialPortLib claims that it's usable from the DXE_CORE. That's
not correct: the DXE_CORE calls DEBUG() and ASSERT() before it calls
ProcessLibraryConstructorList(). Via the BaseDebugLibSerialPort instance,
those DEBUG() and ASSERT() calls result in SerialPortWrite() calls, before
ProcessLibraryConstructorList() called either our constructor
FdtPL011SerialPortLibInitialize(), or BaseDebugLibSerialPortConstructor().
(And even if the DXE_CORE called the latter function early enough, it
would just invoke our SerialPortInitialize() function -- which does
nothing.)
This means that the earliest DXE_CORE debug messages are lost.
Rename FdtPL011SerialPortLibInitialize() to SerialPortInitialize(), so
that the same initialization occur through the constructor and the public
SerialPortInitialize() library API.
Turn SerialPortInitialize() calls after the first one into no-ops.
Our SerialPortLib APIs already use (mSerialBaseAddress != 0) to track
initialization. Rework those checks to actually initialize the library if
that hasn't happened yet.
The following new lines appear in the log:
> CoreInitializeMemoryServices:
> BaseAddress - 0x48000000 Length - 0xF8000000 MinimalMemorySizeNeeded - 0x38C8000
> InstallProtocolInterface: [EfiLoadedImageProtocol] 46EFC3E0
> ProtectUefiImageCommon - 0x46EFC3E0
> - 0x0000000046EB2000 - 0x0000000000068000
(0x46EB2000 is the load address of the DXE Core.)
Reported-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The ARM implementation of InternalLongJump always returned the value
Value - but it is not supposed to ever return 0. Add the test to prevent
that, and return 1 if Value is 0 - as is already present in AArch64.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Both in SetJump and in InternalLongJump, 32-bit w register views were
used for the UINTN return value. In SetJump, this did not cause errors;
it was only counterintuitive. But in InternalLongJump, it meant the top
32 bits of Value were stripped off.
Change all of these to use the 64-bit x register views.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reanimated-by: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2948
XhciDxe uses the timer functionality provided by the
boot services table to detect timeout conditions. This
breaks the driver's ExitBootServices call back, as
CoreExitBootServices halts the timer before signaling
the ExitBootServices event. If the host controller
fails to halt in the call back, the timeout condition
will never occur and the boot gets stuck in an indefinite
spin loop. Use the free running timer provided by
TimerLib to calculate timeouts, avoiding the potential
hang.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Patrick Henz <patrick.henz@hpe.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Use AmlCodeGenRdQWordIo() to generate the I/O range in _CRS instead of
AmlCodeGenRdDWordIo() to cater to the scenarios where 64-bit addresses
can be used to generate I/O packets over the PCIe bus.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add helper functions to generate AML Resource Data describing I/O
ranges of four words long. API AmlCodeGenRdQWordIo () is exposed.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add API to add a String to a package created with NamedPackage API.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add support to add Return objects via AML that pass a single integer
argument to the named method.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The function UsbHcGetPciAddressForHostMem has
ASSERT ((Block != NULL)); and
and the function UsbHcFreeMem has
ASSERT (Block != NULL);
statement after for loop, but these are applicable only in DEBUG mode.
In RELEASE mode, if for whatever reasons there is no match inside for
loop and the loop exits because of Block != NULL; condition, then there
is no "Block" NULL pointer check afterwards and the code proceeds to do
dereferencing "Block" which will lead to CRASH.
Hence, for safety add NULL pointer checks always.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4211
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Co-authored-by: Veeresh Sangolli <veeresh.sangolli@dellteam.com>
Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
JsonObjectGetValue() cannot find corresponding JSON value
when the EDKII_JSON_VALUE object is created by another UEFI
driver. This is because "hashtable_seed" is initialized by
current time while JsonLib is loaded. So, "hashtable_seed"
will be different in each individual UEFI driver.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
FEAT_VHE, introduced in ARMv8.1, adds a virtual EL2 timer.
However, this library verifies that exactly 3 or 4 12-byte timer
interrupts are provided in input DT, ASSERTing when the new timer
is added.
Change the assert to >= 36.
Extend the current logic, also initializing PcdArmArchTimerHypVirtIntrNum
if 5 interrupts are provided.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Adds a plugin that finds debug macro formatting issues. These errors
often creep into debug prints in error conditions not frequently
executed and make debug more difficult when they are encountered.
The code can be as a standalone script which is useful to find
problems in a large codebase that has not been checked before or as
a build plugin that notifies a developer of an error right away.
The script was already used to find numerous issues in edk2 in the
past so there's not many code fixes in this change. More details
are available in the readme file:
.pytool\Plugin\DebugMacroCheck\Readme.md
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
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: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
When finding a free page range for allocation, if the found range
starts below the tracked memory bin address range, the lowest
memory bin address is updated which will not include the guard page if
present. When CoreConvertPagesWithGuard() is called on the range
being allocated, the memory range is adjusted to include guard
pages which can push it out of the memory bin address range and
cause the memory type statistics to be unaltered.
This patch updates the lowest memory bin address range to account for
the guard page if NeedGuard is TRUE so the memory type statistics
are updated correctly.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
Current reset vector uses 0xffffffe0 as AP waking vector, and expects
GenFv generates code aligned on a 4k boundary which will jump to this
location. However, some issues are listed below
1. GenFV doesn't generate code as the comment expects, because GenFv
assumes no modifications are required to the VTF-0 'Volume Top File'.
2. Even if removing VFT0 signature and let GenFv to modify, Genfv is
hard-code using another flash address 0xffffffd0.
3. In the same patch series, AP waking vector code is removed from
GenFv, because no such usage anymore. The existing of first two issues
also approve the usage is not available for a long time.
Therefore, remove AP waking vector related code.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
Current reset vector uses 0xffffffe0 as AP waking vector, and expects
GenFv generates code aligned on a 4k boundary which will jump to this
location. However, some issues are listed below
1. GenFV doesn't generate code as the comment expects, because GenFv
assumes no modifications are required to the VTF-0 'Volume Top File'.
2. Even if removing VFT0 signature and let GenFv to modify, Genfv is
hard-code using another flash address 0xffffffd0.
3. In the same patch series, AP waking vector code is removed from
GenFv, because no such usage anymore. The existing of first two issues
also approve the usage is not available for a long time.
Therefore, remove AP waking vector related code.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
"OvmfPkg/Include/IndustryStandard/Virtio095.h" defines the macro
VIRTIO_SUBSYSTEM_CONSOLE with value 3; other locations in the tree already
use it (such as ArmVirtPkg/PlatformBootManagerLib,
OvmfPkg/VirtioSerialDxe). We should use it in
OvmfPkg/PlatformBootManagerLib too, rather than the naked constant 3.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Jake reports that the IS_ARM_MEMORY_REGION_ATTRIBUTES_SECURE() macro is
no longer accurate since commit 852227a9d5 ("ArmPkg/Mmu: Remove
handling of NONSECURE memory regions").
Fortunately, it only affects the NS bit in level 1 short descriptors,
which is ignored when executing in non-secure mode. And given that
running UEFI in the secure world is not a use case we aim to support,
let's just drop this logic altogether.
Reported-by: Jake Garver <jake@nvidia.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Many arrays are defined with a length of MAX_MENU_NUMBER in
FormGuid.h. Two of those are BootOptionOrder and DriverOptionOrder.
In UpdatePage.c, a pointer is set to either of those arrays. The
array buffer is accessed using an index whose range is checked after
the pointer to the array is dereferenced. This change moves the check
before the dereference.
In another place in the file, the ConsoleCheck pointer is also set to
an array buffer with MAX_MENU_NUMBER elements. Only an ASSERT()
currently checks the range of the array index. This change
conditionalizes the pointer dereference itself on the range of Index.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
The immediately preceding call, GetBestLanguage, plus the implementation of
HiiGetString, which is called immediately afterwards, make it clear that
BestLanguage is a null-terminated ASCII string, and not just a five byte,
non-null terminated buffer.
Therefore AsciiStrLen is one byte too short, meaning that whether the space
allocated is really sufficient and whether the resultant string is really
null-terminated becomes implementation-dependent. Rather than switching to
AsciiStrSize, we use an explicitly compile-time string length calculation
(both compile-time and run-time approaches are currently used elsewhere in
the codebase for copying static strings).
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Add a .editorconfig file which editors can use for basic formatting
details of files, such as tabs/spaces, line endings etc.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
The first element of mAvailableAlgoArray is defined as the default
Rng algorithm to use. Don't go through the array at each RngGetRNG()
call and just return the first element of the array.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Tested-by: Kun Qin <kun.qin@microsoft.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4151
The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
a GetRngGuid() function was added in a previous patch.
The EFI_RNG_PROTOCOL can advertise multiple algorithms through
Guids. The PcdCpuRngSupportedAlgorithm is currently used to
advertise the RngLib in the Arm implementation.
The issues of doing that are:
- the RngLib implementation might not use CPU instructions,
cf. the BaseRngLibTimerLib
- most platforms don't set PcdCpuRngSupportedAlgorithm
A GetRngGuid() was added to the RngLib in a previous patch,
allowing to identify the algorithm implemented by the RngLib.
Make use of this function and place the unsage algorithm
at the last position in the mAvailableAlgoArray.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Tested-by: Kun Qin <kun.qin@microsoft.com>
The EFI_RNG_PROTOCOL can use the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
add a GetRngGuid() function to the RngLib.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441
The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
a GetRngGuid() function is added in a following patch.
Prepare GetRngGuid() return values and add a gEdkiiRngAlgorithmUnSafe
to describe an unsafe implementation, cf. the BaseRngLibTimerLib.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441
The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
a GetRngGuid() function is added in a following patch.
Prepare GetRngGuid() return values and add a gEfiRngAlgorithmArmRndr
to describe a Rng algorithm accessed through Arm's RNDR instruction.
[1] states that the implementation of this algorithm should be
compliant to NIST SP900-80. The compliance is not guaranteed.
[1] Arm Architecture Reference Manual Armv8, for A-profile architecture
sK12.1 'Properties of the generated random number'
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
The DxeRngLib tries to generate a random number using the 3 NIST
SP 800-90 compliant DRBG algorithms, i.e. 256-bits CTR, HASH and HMAC.
If none of the call is successful, the fallback option is the default
RNG algorithm of the EFI_RNG_PROTOCOL. This default algorithm might
be an unsafe implementation.
Try requesting the Raw algorithm before requesting the default one.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
In order to use PcdCpuRngSupportedAlgorithm in the MdePkg in a
following patch and to avoid making the MdePkg dependent on another
package, move PcdCpuRngSupportedAlgorithm to the MdePkg.
As the Pcd is only used for AARCH64, place it in an AARCH64
specific sections.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Tested-by: Kun Qin <kun.qin@microsoft.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4504
The BaseRngLibTimerLib allows to generate number based on a timer.
This mechanism allows to have a basic non-secure implementation
for non-production platforms.
To bind and identify Random Number Generators implementations with
a GUID, an unsafe GUID should be added. This GUID cannot be added
to the MdePkg unless it is also added to a specification.
To keep the MdePkg self-contained, copy the BaseRngLibTimerLib to
the MdeModulePkg. This will allow to define an unsafe Rng GUID
in a later patch in the MdeModulePkg.
The MdePkg implementation will be removed later. This allows to give
some time to platform owners to switch to the MdeModulePkg
implementation.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
Use MpService2Ppi to wakeup AP in s3 boot flow during initializing
CPU. If mSmmS3ResumeState->MpService2Ppi is not 0, then BSP will
use MpService2Ppi->StartupAllCPUs to do CPU initialization for both
BSP and AP instead of only sending InitSipiSipi for AP.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
This commit is code logic refinement for s3 boot flow
in CpuS3.c. It doesn't change any code functionality.
This commit implementes InitializeAp and InitializeBsp
as a single function since they are doing almost the
same thing. Then both BSP and AP will execute the same
function InitializeCpuProcedure to do CPU initialization.
This can make the code logic easier to understand.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Prepare MpService2Ppi in S3Resume when PEI and SMM env run
in the same execution mode. Then smm s3 code can use Mp
Service to wakeup AP instead of only sending InitSipiSipi.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Add MpService2Ppi field in SMM_S3_RESUME_STATE of
AcpiS3Context.h. It will be used to wakeup AP to do the CPU
initialization during smm s3 boot flow in following patches.
With this field, we can avoid sending InitSipiSipi to wakeup
AP.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
The qemu/kvm SMM emulation uses the AMD SaveState layout.
So, now that we have AMD SaveState support merged we can just use
Amd/SmramSaveStateMap.h, QemuSmramSaveStateMap.h is not needed any more.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Add DetectAndPreparePlatformVirtioDevicePath() helper function
to setup virtio-mmio devices. Start with virtio-serial support.
This makes virtio console usable with microvm.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
This reverts commit 173a7a7daa
Fixes https://bugzilla.tianocore.org/show_bug.cgi?id=4528
The build.sh qemu option starts the correct qemu executable for the
selected architecture (build.sh -a option, or implicit) and uses the
correct previously built OVMF image for the selected architecture and
build target (build.sh -b option, or implicit).
With this revert, the above step will fail if there is no matching
previously built OVMF image. This is advantageous over rebuilding each
time the build.sh qemu option is used (as in the reverted commit),
because it provides a quick way to run a just-built OVMF image in place,
while:
a) Starting immediately (saving the time required for a rebuild on each
usage, if the VM is started multiple times)
b) Preserving the NVRAM contents between multiple runs (i.e. until the
image is next rebuilt)
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Currently, unlike OVMF, ArmVirtQemu does not display any graphics, only
the QEMU monitor. Graphics are helpful to confirm booting into an OS is
successful, interacting with the EFI shell while getting separate
logging messages, etc.
This patch adds the QEMU parameters to launch a graphical window and add
a USB keyboard and mouse, which is modeled as a tablet as it tracks
better in QEMU than a generic mouse. virtio-gpu-pci is chosen as the
graphics device as it is recommended by QEMU for the ARM virtual
platform.
The graphics and USB input devices will only be added to QEMU when
QEMU_HEADLESS == FALSE, so CI builds will not attempt to use the
graphics and if a user does not want graphics, they can add
QEMU_HEADLESS=TRUE to the build cmdline.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The Hii form is named "MainFormState" while the EFI variable is named
"PlatformConfig". This discrepancy in names causes the following SCT
cases to fail on RiscVVirtQemu:
ExtractConfigConformance
ExtractConfigFunction
ExtractConfig_Func
Previous commit 16acacf addressed two of these issues, and this patch
fixes the remaining one.
Signed-off-by: Yin Wang <yin.wang@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Booting an SEV guest with AmdSev OVMF package currently triggers the
following assertion with QEMU:
InstallQemuFwCfgTables: installed 7 tables
PcRtc: Write 0x20 to CMOS location 0x32
[Variable]END_OF_DXE is signaled
Initialize variable error flag (FF)
ASSERT_EFI_ERROR (Status = Not Found)
ASSERT [BdsDxe] /home/VT_BUILD/ovmf/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c(1711): !(((INTN)(RETURN_STATUS)(Status)) < 0)
This seems to be due to commit 81dc0d8b4c, which switched to using
PlatformBootManagerLib instead of PlatformBootManagerLibGrub. That pulls
in a dependency on gEfiS3SaveStateProtocolGuid provider being available
(which is asserted for in
BdsPlatform.c:PlatformBootManagerBeforeConsole()/SaveS3BootScript()),
but the libraries that provide it aren't currently included in the
build. Add them similarly to what's done for OvmfPkg.
Fixes: 81dc0d8b4c ("OvmfPkg/AmdSev: stop using PlatformBootManagerLibGrub")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
PcdFirstTimeWakeUpAPsBySipi was recently introduced to indicate when the
full INIT-SIPI-SIPI sequence can be skipped for AP bringup. It is true
by default, but needs to be disabled for QEMU/OVMF where early INIT is
not simulated. Commit 1d76560146 ("OvmfPkg: Disable
PcdFirstTimeWakeUpAPsBySipi.") added changes to disable it by default
for OvmfPkg, but a similar change was not made for the AmdSev package.
This breaks booting of SEV and SNP guests.
Fix this defaulting PcdFirstTimeWakeUpAPsBySipi to false for AmdSev
package, as was previously done for OvmfPkg variants.
Fixes: eaffa1d7ff ("UefiCpuPkg:Wake up APs after power-up or RESET through SIPI.")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Instead of relying on raising the TPL to protect the critical sections
that manipulate the global bitmask that keeps track of bounce buffer
allocations, use compare-and-exchange to manage the global variable, and
tweak the logic to line up with that.
Given that IoMmuDxe implements a singleton protocol that is shared
between multiple drivers, and considering the elaborate and confusing
requirements in the UEFP spec regarding TPL levels at which protocol
methods may be invoked, not relying on TPL levels at all is a more
robust approach in this case.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2211060
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Pedro Falcato <pedro.falcato@gmail.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4543
REF: https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-services-locatehandlebuffer
CoreLocateHandleBuffer() can in certain cases, return an
error and not free an allocated buffer. This scenario
occurs if the first call to InternalCoreLocateHandle()
returns success and the second call returns an error.
On a successful return, LocateHandleBuffer() passes
ownership of the buffer to the caller. However, the UEFI
specification is not explicit about what the expected
ownership of this buffer is in the case of an error.
However, it is heavily implied by the code example given
in section 7.3.15 of v2.10 of the UEFI specificaton that
if LocateHandleBuffer() returns a non-successful status
code then the ownership of the buffer does NOT transfer
to the caller. This code example explicitly refrains from
calling FreePool() if LocateHandleBuffer() returns an
error.
From a practical standpoint, it is logical to assume that
a non-successful status code indicates that no buffer of
handles was ever allocated. Indeed, in most error cases,
LocateHandleBuffer() does not go far enough to get to the
point where a buffer is allocated. Therefore, all existing
users of this API must already be coded to support the case
of a non-successful status code resulting in an invalid
handle buffer being returned. Therefore, this change will
not cause any backwards compatibility issues with existing
code.
In conclusion, this boils down to a fix for a memory leak
that also brings the behavior of our LocateHandleBuffer()
implementation into alignment with the original intentions
of the UEFI specification authors.
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
The top two bits of the Extended BIOS ROM Size field indicates the unit
used for the remaining 14 bits. If the size is greater than 16GB, the
unit is gigabytes.
The test for this uses the local BiosPhysicalSize variable, which is a
UINTN, meaning that when building for ARM/CLANGDWARF we have a
tautological constant comparison, which the toolchain flags now we've
stopped disabling that warning.
So switch the BiosPhysicalSize variable to UINT64.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Fix smm perf issue in DxeCorePerformanceLib. In
current code logic, total SMM perf record is copied
multiple times to FPDT table if multiple ReadyToBoot
events are signaled. This patch changes the function
InternalGetSmmPerfData() to only get newly generated
Smm perf data. Then previous generated Smm perf data
won't be copied to FPDT again.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4470
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This updates the system slot ID up to SlotTypePCIExpressGen6andBeyond
(0xC4) added by updating type 9 with SMBIOS version 3.5 to cover modern
PCIe Gens.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
A faulty PCI device has the Option ROM image size set to 0. UEFI reads
two headers PCI_EXPANSION_ROM_HEADER and PCI_DATA_STRUCTURE to get the
Option ROM information. Because the image size is 0, the Option ROM
header address never changes. As a result, UEFI keeps reading the same
two headers definitely. This patch is intended to fix it.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The global variable has a common name that can conflict with other
TCG modules. For example, Tcg2Dxe has a similarly named global that
is of type EFI_TCG2_PROTOCOL instead of EFI_TCG2_PROTOCOL*.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The block size configuration of Blockmap does not match that in Qemu
VirtNorFlash, which causes variable data to be written into FtwWorkBlock
by mistake, resulting in data loss during reboot. Fix it and update
new checksum value.
Signed-off-by: Qingyu Shang <2931013282@sjtu.edu.cn>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Currently, HeapGuard, when in the GuardAlignedToTail mode, assumes that
the pool head has been allocated in the first page of memory that was
allocated. This is not the case for ARM64 platforms when allocating
runtime pools, as RUNTIME_PAGE_ALLOCATION_GRANULARITY is 64k, unlike
X64, which has RUNTIME_PAGE_ALLOCATION_GRANULARITY as 4k.
When a runtime pool is allocated on ARM64, the minimum number of pages
allocated is 16, to match the runtime granularity. When a small pool is
allocated and GuardAlignedToTail is true, HeapGuard instructs the pool
head to be placed as (MemoryAllocated + EFI_PAGES_TO_SIZE(Number of Pages)
- SizeRequiredForPool).
This gives this scenario:
|Head Guard|Large Free Number of Pages|PoolHead|TailGuard|
When this pool goes to be freed, HeapGuard instructs the pool code to
free from (PoolHead & ~EFI_PAGE_MASK). However, this assumes that the
PoolHead is in the first page allocated, which as shown above is not true
in this case. For the 4k granularity case (i.e. where the correct number of
pages are allocated for this pool), this logic does work.
In this failing case, HeapGuard then instructs the pool code to free 16
(or more depending) pages from the page the pool head was allocated on,
which as seen above means we overrun the pool and attempt to free memory
far past the pool. We end up running into the tail guard and getting an
access flag fault.
This causes ArmVirtQemu to fail to boot with an access flag fault when
GuardAlignedToTail is set to true (and pool guard enabled for runtime
memory). It should also cause all ARM64 platforms to fail in this
configuration, for exactly the same reason, as this is core code making
the assumption.
This patch removes HeapGuard's assumption that the pool head is allocated
on the first page and instead undoes the same logic that HeapGuard did
when allocating the pool head in the first place.
With this patch in place, ArmVirtQemu boots with GuardAlignedToTail
set to true (and when it is false, also).
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4521
Github PR: https://github.com/tianocore/edk2/pull/4731
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Copy the function BuildPlatformInfoHob() from OvmfPkg/PlatformPei.
QemuFwCfgLib expect this HOB to be present, or fails to do anything.
InternalQemuFwCfgIsAvailable() from QemuFwCfgPeiLib module will not
check if the HOB is actually present for example and try to use a NULL
pointer.
Fixes: cda98df162 ("OvmfPkg/QemuFwCfgLib: remove mQemuFwCfgSupported + mQemuFwCfgDmaSupported")
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The implementation of this new behavior aligns with the guidelines
outlined in the Intel SDM.
Following a power-up or RESET of an MP system, system hardware
dynamically selects one of the processors on the system bus as the BSP.
The remaining processors are designated as APs. The APs complete a
minimal self-configuration, then wait for a startup signal (a SIPI
message) from the BSP processor.
Additionally, the MP protocol is executed only after
a power-up or RESET. If the MP protocol has completed and a
BSP is chosen, subsequent INITs (either to a specific processor or
system wide) do not cause the MP protocol to be repeated. Instead, each
logical processor examines its BSP flag (in the IA32_APIC_BASE MSR) to
determine whether it should execute the BIOS boot-strap code (if it is
the BSP) or enter a wait-for-SIPI state (if it is an AP).
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Rewrite the script to configure openssl 3.0 from scratch. It's two
scripts now:
* Tiny helper script, dumping the perl configdata as json.
* Actual configure.py script, written in python, which copies over
the generated files to openssl-gen and updates the OpensslLib*.inf
file lists and build flags.
The configuration workflow has changed a bit:
* All generated files are stored in the OpensslGen directory tree.
* For ec/no-ec builds two different header files are used. Default is
the ec variant, and the new EDK2_OPENSSL_NOEC define is used to
select the no-ec build. A five line wrapper include is used to pick
the one or the other.
* For non-accel builds -DOPENSSL_NO_ASM on the command line is used
(same as before).
* For configration defines the OPENSSL_FLAGS_$(variant) variable is
used, where variant is the architecture for the accelerated builds
and 'NOASM' for the non-accelerated builds.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Yi Li <yi1.li@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Brian J. Johnson <brian.johnson@hpe.com>
Tested-by: Kenneth Lautner <klautner@microsoft.com>
If gST->ConOut is available when Arm's DefaultExceptionHandler is
running, AsciiPrint will get called to attempt to print to ConOut, in
addition to the serial output.
AsciiPrint calls AsciiInternalPrint in UefiLibPrint.c which in turn
calls AllocatePool to allocate a buffer to convert the Ascii input
string to a Unicode string to pass to ConOut->OutputString.
Per the comment on DefaultExceptionHandler, we should not be allocating
memory in the exception handler, as this can cause the exception handler
to fail if we had a memory exception or the system state is such that we
cannot allocate memory.
It has been observed on ArmVirtQemu that exceptions generated in the
memory handling code will fail to output the stack dump and CPU state
that is critical to debugging because the AllocatePool will fail.
This patch fixes the Arm and AARCH64 DefaultExceptionHandlers to not
allocate memory when ConOut is available and instead use stack memory to
convert the Ascii string needed for SerialPortWrite to the Unicode
string needed for ConOut->OutputString. Correspondingly, ArmVirtQemu can
now output the stack dump and CPU state when hitting an exception in
memory code.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
For EfiVarStore (EFI_HII_VARSTORE_EFI_VARIABLE_BUFFER), it will call
ExtractConfig-GetVariable-HiiBlockToConfig-ConfigToBlock when load storage
value in LoadStorage function. It's not necessary and costs lots of time
to do the conversion between config and block.
So now enhance it to call GetVariable directly.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Eric Dong <eric.dong@intel.com>
The return value stored in Status after call to SetDriveParameters
is not made of any use thereafter and hence it remains as UNUSED.
Based on Hao's findings (https://edk2.groups.io/g/devel/message/106844),
the successful execution of SetDriveParameters() is not mandatory for
initializing IDE mode of a hard disk device. Hence remove the 'Status'
assignment of the return value from SetDriveParameters() and instead add
error checks & DEBUG_WARN level messages within SetDriveParameters()
function after sending INIT_DRIVE_PARAM & SET_MULTIPLE_MODE ATA commands.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4204
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The purpose is to fix an issue where an exception occurs at the start
of the DXE phase by applying the following patch series on INTEL-based
systems.
UefiCpuPkg: Refactor the logic for placing APs in HltLoop.
UefiCpuPkg: Refactor the logic for placing APs in Mwait/Runloop.
UefiCpuPkg: Create MpHandOff.
UefiCpuPkg: ApWakeupFunction directly use CpuMpData.
UefiCpuPkg: Eliminate the second INIT-SIPI-SIPI sequence.
This series of patches makes changes to the way the APs are
initialized and woken up. It removes the 2nd time INIT-SIPI-SIPI and
introduces a special startup signal to wake up APs. These patches also
create a new HOB identified by the mMpHandOffGuid, which stores only the
minimum information required from the PEI phase to the DXE phase.
As a result, the original HOB (mCpuInitMpLibHobGuid) is now used only
as a global variable in the PEI phase and is no longer necessary in the
DXE phase for INTEL-based systems. The AMD SEV-ES related code
still relies on the OldCpuMpData in the DXE phase.
This patch decouple the SEV-ES functionality of assigning CpuMpData to
OldCpuMpData->NewCpuMpData from the Intel logic.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
- Add NTOHL() for coverting IP address from EFI_IPv4_ADDRESS to
IP4_ADDR so that IP4_IS_VALID_NETMASK() return correct value.
- Add DumpIpv4Address() in RedfishDebugLib and print IP address
when invalid IP or subnet mask address is detected.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Remove workaround for the redefinition of the type
RUNTIME_FUNCTION that is generated when building with
VS20xx tool chains and using windows include files.
The correct location for this fix is in the EmulatorPkg
in the WinInclude.h file that addresses all the name
collisions between edk2 types and windows types.
The commit that added the workaround is:
ff52068d92
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4467
Current implementation of UnitTestFrameworkPkg for shell-based unit test
will save the unit test cache to the same volume as the test application
itself. This works as long as the test application is on a writable
volume, such as USB or EFI partition.
Instead of saving the files to the same file system of unit test
application, this change will save the cache file to the path where the
user ran this test application.
This change then added an input argument to allow user to specify where
to save such cache file through `--CachePath` shell argument to allow
even more flexibility.
This change was tested on proprietary physical hardware platforms and
QEMU based virtual platform.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Searching for an unused bounce buffer in mReservedMemBitmap and
reserving the buffer by flipping the bit is a critical section
which must not be interrupted. Raise the TPL level to ensure
that.
Without this fix it can happen that IoMmuDxe hands out the same
bounce buffer twice, causing trouble down the road. Seen happening
in practice with VirtioNetDxe setting up the network interface (and
calling into IoMmuDxe from a polling timer callback) in parallel with
Boot Manager doing some disk I/O. An ASSERT() in VirtioNet caught
the buffer inconsistency.
Full story with lots of details and discussions is available here:
https://bugzilla.redhat.com/show_bug.cgi?id=2211060
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The function UsbHcGetPciAddressForHostMem has
ASSERT ((Block != NULL));
and the UsbHcFreeMem has
ASSERT (Block != NULL);
statement after for loop, but these are applicable only in DEBUG mode.
In RELEASE mode, if for whatever reasons there is no match inside the
for loop and the loop exits because of Block != NULL; condition, then
there is no "Block" NULL pointer check afterwards and the code proceeds
to do dereferencing "Block" which will lead to CRASH.
Hence, for safety add NULL pointer checks always.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4210
Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Make sure VirtNorFlashDxe loaded before VariableRuntimeDxe as it
is the backend flash driver.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Normally, DXE driver would add device resource to GCD before start using.
But some key resources such as uart used for printing info at very early
stage.
Those resources should be populated to HOB in SEC phase so they are
added to GCD before MMU enabled.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Commit 63c50d3ff2 changed the check that is
used to determine if SEV-ES is active. Originally, a CMP instruction with
a supporting JZ instruction was used for the check. It was changed to use
the BT instruction but not JZ instruction. The result of a BT instruction
changes the the carry flag (CF) and not the zero flag (ZF). As a result,
the wrong condition is being checked. Update the JZ to a JNC to properly
detect if SEV-ES is active.
Fixes: 63c50d3ff2 ("OvmfPkg/ResetVector: cache the SEV status MSR...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
When both the PEI and DXE phases operate in the same execution
mode(32-bit/64-bit), the BSP send a special start-up signal during
the DXE phase to awaken the Application APs.
To eliminate the need for the INIT-SIPI-SIPI sequence at the beginning
of the DXE phase, the BSP call the SwitchApContext function to trigger
the special start-up signal. By writing the specified
StartupSignalValue to the designated StartupSignalAddress, the BSP
wakes up the APs from mwait mode. Once the APs receive the
MP_HAND_OFF_SIGNAL value, they are awakened and proceed to execute the
SwitchContextPerAp procedure. They enter another while loop,
transitioning their context from the PEI phase to the DXE phase.
The original state transitions for an AP during the procedure are as
follows:
Idle ----> Ready ----> Busy ----> Idle
[BSP] [AP] [AP]
Instead of init-sipi-sipi sequence, we make use of a
start-up signal to awaken the APs and transfer their context from
PEI to DXE. Consequently, APs, rather than the BSP, to set their state
to CpuStateReady.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
In the original design, once the APs finished executing their assembly
code and switched to executing C code, they would enter a continuous
loop within a function. In this function, they would collect CpuMpData
using the MP_CPU_EXCHANGE_INFO mechanism. However, in the updated
approach, CpuMpData can now be passed directly to the ApWakeUpFunction,
bypassing the need for MP_CPU_EXCHANGE_INFO. This modification is made
in preparation for eliminating the requirement of a second
INIT-SIPI-SIPI sequence in the DXE phase.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Initially, the purpose of the Hob was twofold: it served as a way to
transfer information from PEI to DXE. However, during the DXE phase,
only a few fields from the CPU_MP_DATA which collected in PEI phase were
needed. A new Hob was specifically created to transfer information
to the DXE phase. This new Hob contained only the essential fields
required for reuse in DXE. For instance, instead of directly including
the BspNumber in MpHandOff, the DXE phase introduced the use of
GetBspNumber() to collect the BspNumber from ApicID and CpuCount.
The SaveCpuMpData() function was updated to construct the MP_HAND_OFF
Hob. Additionally, the function introduced the MP_HAND_OFF_SIGNAL,
which solely served the purpose of awakening the APs
and transitioning their context from PEI to DXE. The
WaitLoopExecutionMode field indicated whether the bit mode of PEI
matched that of DXE. Both of them were filled only if the ApLoopMode
was not ApInHltLoop. In the case of ApInHltLoop, it remained necessary
to wake up the APs using the init-sipi-sipi sequence. This improvement
still allow INIT-SIPI-SIPI even APs are wait in Run/Mwait loop mode.
The function GetMpHandOffHob() was added to facilitate access to the
collected MpHandOff in the DXE phase. The CpuMpData in the DXE phase
was updated by gathering information from MpHandOff. Since MpHandOff
replaced the usage of OldCpuMpData and contained essential information
from the PEI phase to the DXE phase. AmdSevUpdateCpuMpData was included
to maintain the original implementation of AmdSev, ensuring that
OldCpuMpData->NewCpuMpData pointed to CpuMpData.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4410
Inside TcgMorLockSmm.c, the SetVariableCheckHandlerMorLock() function
contains a scenario to prevent a possible dictionary attack on the MorLock
Key in accordance with the TCG Platform Reset Mitigation Spec v1.10.
The mechanism to prevent this attack must also change the MorLock Variable
Value to 0x01 to indicate Locked Without Key.
ASSERT_EFI_ERROR is added for error visibility since SetMorLockVariable
returns a status code
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Abhi Singh <Abhi.Singh@arm.com>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Introduce DumpHiiStatementValue() and DumpRedfishValue() to
RedfishDebugLib. Application uses these functions to debug
print the value of HII_STATEMENT_VALUE and EDKII_REDFISH_VALUE.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
RedfishRestExDxe driver failed to uninstall service binding protocol
when driver binding stop is called. Application drivers may still
use RedfishRestExDxe after it is disconnected in system.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Much of the MMU logic was written without function headers. This patch
adds function headers where absent and updates function headers which
do not match the EDK2 standard.
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
There are ASSERTs present in the MMU logic to ensure various
functions return successfully, but these ASSERTs may be ignored
on release builds causing unsafe behavior. This patch updates
the logic to handle unexpected return values and branch safely.
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch updates the GetMemoryRegion() function to handle the case
where there is no mapping for the requested address.
The original logic for the ARM would hit an ASSERT after
GetMemoryRegionPage() returned EFI_SUCCESS but did not update The
RegionLength parameter.
The original logic for the AARCH64 would never initialize the
RegionLength parameter to zero and return EFI_SUCCESS after
traversing an unknown number of pages.
To fix this, update the logic for both architecture to return
EFI_NO_MAPPING if the BaseAddress being checked is unmapped.
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch applies Uncrustify to the following files:
ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c
ArmPkg/Include/IndustryStandard/ArmStdSmc.h
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
Adds an SMM SMRAM save-state map for AMD processors.
SMRAM save state maps for the AMD processor family are now supported.
Save state map structure is added based on
AMD64 Architecture Programmer's Manual, Volume 2, Section 10.2.
The AMD legacy save state map for 32-bit architecture is defined.
The AMD64 save state map for 64-bit architecture is defined.
Also added Amd/SmramSaveStateMap.h to IgnoreFiles of EccCheck,
because structures defined in this file are derived from
Intel/SmramSaveStateMap.h.
Cc: Paul Grimes <paul.grimes@amd.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Abdul Lateef Attar <abdattar@amd.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The timer notify function should be called with timer period, not the
value read from timer register.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
This commit is code refinement to current smm runtime InitPaging()
page table update code. In InitPaging(), if PcdCpuSmmProfileEnable
is TRUE, use ConvertMemoryPageAttributes() API to map the range in
mProtectionMemRange to the attrbute recorded in the attribute field
of mProtectionMemRange, map the range outside mProtectionMemRange
as non-present. If PcdCpuSmmProfileEnable is FALSE, only need to
set the ranges not in mSmmCpuSmramRanges as NX.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
This commit is code refinement to current smm pagetable generation
code. Add a new GenSmmPageTable() API to create smm page table
based on the PageTableMap() API in CpuPageTableLib. Caller only
needs to specify the paging mode and the PhysicalAddressBits to map.
This function can be used to create both IA32 pae paging and X64
5level, 4level paging.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Clear CR0.WP before modify smm page table. Currently, there is
an assumption that smm pagetable is always RW before ReadyToLock.
However, when AMD SEV is enabled, FvbServicesSmm driver calls
MemEncryptSevClearMmioPageEncMask to clear AddressEncMask bit
in smm page table for this range:
[PcdOvmfFdBaseAddress,PcdOvmfFdBaseAddress+PcdOvmfFirmwareFdSize]
If page slpit happens in this process, new memory for smm page
table is allocated. Then the newly allocated page table memory
is marked as RO in smm page table in this FvbServicesSmm driver,
which may lead to PF if smm code doesn't clear CR0.WP before
modify smm page table when ReadyToLock.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
In PiSmmCpuDxeSmm code, SetMemMapAttributes() marks memory ranges
in SmmMemoryAttributesTable to RO/NX. There may exist non-present
range in these memory ranges. Set other attributes for a non-present
range is not permitted in CpuPageTableMapLib. So add code to handle
this case. Only map the present ranges in SmmMemoryAttributesTable
to RO or NX.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
In ConvertMemoryPageAttributes() function, when clear RP for a
specific range [BaseAddress, BaseAddress + Length], it means to
set the present bit to 1 and assign default value for other
attributes in page table. The default attributes for the input
specific range are NX disabled and ReadOnly. If there is existing
present range in [BaseAddress, BaseAddress + Length] and the
attributes are not NX disabled or not ReadOnly, then output the
DEBUG message to indicate that the NX and ReadOnly attributes of
the existing present range are modified in the function.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Simplify the ConvertMemoryPageAttributes API to convert paging
attribute by CpuPageTableLib. In the new API, it calls
PageTableMap() to update the page attributes of a memory range.
With the PageTableMap() API in CpuPageTableLib, we can remove
the complicated page table manipulating code.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
In UnsetGuardPage(), before SmmReadyToLock, remove NX and RO
memory attribute protection for guarded page since
EfiConventionalMemory in SMRAM is RW and executable before
SmmReadyToLock. If UnsetGuardPage() happens after SmmReadyToLock,
then apply EFI_MEMORY_XP to the guarded page to make sure
EfiConventionalMemory in SMRAM is NX since EfiConventionalMemory
in SMRAM is marked as NX in PiSmmCpuDxe driver when SmmReadyToLock.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Remove code that sets AddressEncMask for non-leaf entries when
modifing smm page table by MemEncryptSevLib. In FvbServicesSmm
driver, it calls MemEncryptSevClearMmioPageEncMask to clear
AddressEncMask bit in page table for a specific range. In AMD
SEV feature, this AddressEncMask bit in page table is used to
indicate if the memory is guest private memory or shared memory.
But all memory accessed by the hardware page table walker is
treated as encrypted, regardless of whether the encryption bit
is present. So remove the code to set the EncMask bit for smm
non-leaf entries doesn't impact AMD SEV feature.
The reason encryption mask should not be set for non-leaf
entries is because CpuPageTableLib doesn't consume encryption
mask PCD. In PiSmmCpuDxeSmm module, it will use CpuPageTableLib
to modify smm page table in next patch. The encryption mask is
overlapped with the PageTableBaseAddress field of non-leaf page
table entries. If the encryption mask is set for smm non-leaf
page table entries, issue happens when CpuPageTableLib code
use the non-leaf entry PageTableBaseAddress field with the
encryption mask set to find the next level page table.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The UEFI driver model invokes the supported() method on every driver
every time a connection attempt is made on any handle, and so doing an
unconditional DEBUG() print inside this method produced a lot of noise.
So let's drop this DEBUG() call from the VirtioSerial driver's
Supported() method.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The OP-TEE secure OS exposes a non-secure memory region for
communication between the secure OS itself and any clients in the
non-secure firmware. This memory is writable by non-secure and is not
used for code only data, and so it should be mapped non-executable.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Now that we have a sane API to set and clear memory permissions that
works the same on ARM and AArch64, we no longer have a need for the
individual set/clear no-access/read-only/no-exec helpers so let's drop
them.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
StandaloneMm has its own version of the ArmMmuLib library class, but
includes the ArmMmuLib header. This happens to work because the
prototypes that are referenced are the same, but this will no longer be
the case after a future patch. So correct the #includes.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Because it's simpler for a platform to include the ResetVector source
and having pre-built binaries add burdens of updating the pre-built
binaries. This patch removes the pre-built binaries and the script
that buids the pre-built binaries.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
ResetVector assembly implementation puts "ALIGN 16" in the end
to guarantee the final executable file size is multiple of 16 bytes.
Because the module uses a special GUID which guarantees it's put in
the very end of a FV, which should be also the end of the FD.
All of these (file size is multiple of 16B, and the module is put at
end of FV, FV is put at end of FD) guarantee the "JMP xxx" instruction
is at FFFF_FFF0h.
This patch updates INF file and ReadMe.txt to add guidance of FDF ffs
rule for the ResetVector.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Now that ArmSetMemoryAttributes() permits a mask to be provided, we can
simplify the implementation the UEFI memory attribute protocol
substantially, and just pass on the requested mask to be set or cleared
directly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Now that we have a generic method to manage memory permissions using a
PPI, we can switch to the generic version of the DXE handoff code in
DxeIpl, and drop the ARM specific version.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Implement the newly defined PPI that permits the PEI core and DXE IPL to
manage memory permissions on ranges of DRAM, for doing things like
mapping the stack non-executable, or granting executable permissions to
shadowed PEIMs.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Currently, ArmSetMemoryAttributes () takes a combination of
EFI_MEMORY_xx constants describing the memory type and permission
attributes that should be set on a region of memory. In cases where the
memory type is omitted, we assume that the memory permissions being set
are final, and that existing memory permissions can be discarded.
This is problematic, because we aim to map memory non-executable
(EFI_MEMORY_XP) by default, and only relax this requirement for code
regions that are mapped read-only (EFI_MEMORY_RO). Currently, setting
one permission clears the other, and so code managing these permissions
has to be aware of the existing permissions in order to be able to
preserve them, and this is not always tractable (e.g., the UEFI memory
attribute protocol implements an abstraction that promises to preserve
memory permissions that it is not operating on explicitly).
So let's add an AttributeMask parameter to ArmSetMemoryAttributes(),
which is permitted to be non-zero if no memory type is being provided,
in which case only memory permission attributes covered in the mask will
be affected by the update.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
If the associated PCD is set to TRUE, use the memory attribute PPI to
remap the stack non-executable. This provides a generic method for doing
so, which will be used by ARM and AArch64 as well once they move to the
generic DxeIpl handoff implementation.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The Risc-V and LoongArch specific versions of the DXE core handoff code
in DxeIpl are essentially copies of the EBC version (modulo the
copyright in the header and some debug prints in the code).
In preparation for introducing a generic PPI based method to implement
the non-executable stack, let's merge these versions, so we only need to
add this logic once.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Define a PPI interface that may be used by the PEI core or other PEIMs
to manage permissions on memory ranges. This is primarily intended for
restricting permissions to what is actually needed for correct execution
by the code in question, and for limiting the use of memory mappings
that are both writable and executable at the same time.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bhyve will gain support for TPM emulation in the near future. Therefore,
prepare OVMF by copying all TPM driver used by qemu's OVMF DSC into the
bhyve OVMF DSC.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
This makes the InstallQemuFwcfgTables function reusable by bhyve.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
This is required to move InstallQemuFwCfgTables into AcpiPlatformLib.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
Bhyve supports providing ACPI tables by FwCfg. Therefore,
InstallQemuFwCfgTables should be moved to AcpiPlatformLib to reuse the
code. As first step, move PciEncoding into AcpiPlatformLib.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
The definition and declaration of GetAcpiRsdpFromMemory doesn't match.
We don't get a compile error yet because UINTN is the same as UINT64 on
64bit machines. As the function works on memory addresses, UINTN is the
correct type of the input parameters.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Currently, RiscVVirtQemu supports unified code and variable store
mainly because only one pflash devices was available in qemu for
EDK2. However, this doesn't allow to map the code part as read-only.
With recent qemu enhancements, it is now possible for EDK2 to make
use of both pflash devices in RISC-V virt machine. So, add support
to create code and vars images separately. This also allows easy
firmware code updates without losing the variable store.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This commit is code optimization to InternalAllocateAlignedPages of
SmmMemoryAllocationLib which can reduce free memory fragments. Also
it can reduce one pre-allocation page.
Let's take a simple example:
The expected pages size is 8KB, Alignment value is 8KB.
In original InternalAllocateAlignedPages(), the first step is to
allocate 4 pages and then find the first 8KB-aligned address in
allocated 4 pages. If the upper limit address of allocated 4 pages
is already 8KB aligned, then the allocated 4 pages contains two
8KB-aligned 8KB ranges. The lower 2 pages will be selected and
removed from free pages. Then the higher 2 pages will be free.
Since the whole memory allocation is from high address to low
address, then the higher 2 pages cann't be merged with other free
pages, causing the free memory fragments.
However, when only allocate 3(2+2-1) pages, we can avoid the free
memory fragments in specific case. Also 3 pages must contain a
8KB-aligned 8KB range, which meets the requirement. If the upper
limit address of allocated 3 pages is 8KB-aligned, then the higher
2 pages range of allocated 3 pages is 8KB-aligned and will be
selected and removed from free pages. The remaining lower one page
of allocated 3 pages will be free and merged with left lower free
memory. This can reduce free memory fragments in smm.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
When a platform has lots of CPU cores/threads, perf-logging on every
AP produces lots of records. When this multiplies with number of SMIs
during post, the records are even more.
So, this patch adds a new PCD PcdSmmApPerfLogEnable (default TRUE)
to allow platform to turn off perf-logging on APs.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
MP procedures are those procedures that run in every CPU thread.
The EDKII perf infra is not MP safe so it doesn't support to be called
from those MP procedures.
The patch adds SMM MP perf-logging support in SmmMpPerf.c.
The following procedures are perf-logged:
* SmmInitHandler
* SmmCpuFeaturesRendezvousEntry
* PlatformValidSmi
* SmmCpuFeaturesRendezvousExit
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
This library supports a PeiServicesTablePointerLib implementation
that allows code dependent upon PeiServicesTable to operate in an
isolated execution environment such as within the context of a
host-based unit test framework.
The unit test should initialize the PeiServicesTable database with
any required elements (e.g. PPIs, Hob etc.) prior to the services
being invoked by code under test.
It is strongly recommended to clean any global databases by using
EFI_PEI_SERVICES.ResetSystem2 after every unit test so the tests
execute in a predictable manner from a clean state.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Currently, have two command for pre-build binary support
1. --BuildEntryOnly: build UPL Entry file
2. --PreBuildUplBinary: build UPL binary based on UPL
And these two commands should be exclusived, shouldn't
have chance run it in the meantime.
Case1: Build UPL entry with CLANGDWARF
python UefiPayloadPkg/UniversalPayloadBuild.py --BuildEntryOnly
Case2: Use pre-built UPL entry and build other fv by VS2019
python UefiPayloadPkg/UniversalPayloadBuild.py -t VS2019 \
--PreBuildUplBinary UniversalPayload.elf
Case3: Build UPL Entry with CLANGDWARF and build other fv by VS2019
python UefiPayloadPkg/UniversalPayloadBuild.py -t VS2019
Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Signed-off-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: James Lu <james.lu@intel.com>
RedfishClientPkg is moved from edk2-staging repository to
edk2-redfish-client repository. Update the link in Readme.md
to new location.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
If there is no port multiplier, PortMultiplierPort should be converted
to 0 to follow AHCI spec.
The same logic already applied in AtaAtapiPassThruDxe driver.
Signed-off-by: Neo Hsueh <Hong-Chih.Hsueh@amd.com>
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Implement the SpeculationBarrier with implementations consisting of
fence instruction which provides finer-grain memory orderings.
Perform Data Barrier in RiscV: fence rw,rw
Perform Instruction Barrier in RiscV: fence.i; fence r,r
More detail is in Appendix A: RVWMO Explanatory Material in
https://github.com/riscv/riscv-isa-manual
This API is first introduced in the below commits for IA32 and x64
d9f1cac51be83d841fdc
and below the commit for ARM and AArch64 implementation
c0959b4426
This commit is to add the RiscV64 implementation which will be used by
variable service under Variable/RuntimeDxe
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Evan Chai <evan.chai@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Tuan Phan <tphan@ventanamicro.com>
Signed-off-by: Yong Li <yong.li@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
It's much easier to create configuration dependent ACPI tables for bhyve
than for OVMF. For this reason, don't use the statically created ACPI
tables provided by OVMF. Instead, prefer the dynamically created ACPI
tables of bhyve. If bhyve provides no ACPI tables or we are unable to
detect those, fall back to OVMF tables.
Ideally, we use the qemu fwcfg interface to pass the ACPI tables from
bhyve to OVMF. bhyve will support this in the future. However, current
bhyve executables don't support passing ACPI tables by the qemu fwcfg
interface. They just copy the ACPI into main memory. For that reason,
pick up the ACPI tables from main memory.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Xen and bhyve are placing ACPI tables into system memory. So, they can
share the same code. Therefore, create a new library which searches and
installs ACPI tables from system memory.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Edk2 was failing, rather than creating more PML4 entries, when they
weren't present in the initial memory acceptance flow. Because of that
VMs with more than 512G memory were crashing. This code fixes that.
This change affects only SEV-SNP VMs.
The code was tested by successfully booting a 512G SEV-SNP VM.
Signed-off-by: Mikolaj Lisik <lisik@google.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
The RISC-V version of the DXE IPL does not implement setting the stack
NX, so before switching to an implementation that will ASSERT() on the
missing support, drop the PCD setting that enables it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Uncrustify checks are too rigid, making them counter-productive:
- it leads to code that is arguably harder to parse visually (e.g.,
the changes to ArmPkg/Include/Chipset/AArch64Mmu.h in commit
429309e0c6)
- it forces indentation-only changes to code in the vicinity of actual
changes, making the code history more bloated than necessary (see
commit 7f198321ee for an example)
- finding out from the web UI what exactly Uncrustify objected to is not
straight-forward.
So let's enable AuditMode for ArmPkg, so that interested parties can see
the uncrustify recommendations if desired, but without preventing the
changes from being merged. This leaves it at the discretion of the
ArmPkg maintainers to decide which level of conformance is required.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
In case ShellConvertStringToUint64() fails the Handles are left
uninitialized. That can for example happen for Handle2 and Handle3 in
case only one parameter was specified on the command line. Which can
trigger the ASSERT() in line 185.
Reproducer: boot ovmf to efi shell in qemu, using q35 machine type, then
try disconnect the sata controller in efi shell.
Fix that by explicitly setting them to NULL in that case. While being
at it also simplify the logic and avoid pointlessly calling
ShellConvertStringToUint64() in case ParamN is NULL.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
As per the SMBIOS spec, in smbios type0 table, if the Bios size is
greater than 16MB, extended bios size is used to update size information
and bios size is set to 0xff. when this data is printed by smbiosview,
both bios size and extended bios size is printed if the smbios version
is beyond 3.1, which is incorrect as Bios size is set to 0xff when
rom size is more than 16MB.
To fix this bug, added a condition to print bios size only when it is
not set to 0xff or if the smbios version is older than 3.1.
Signed-off-by: Thejaswani Putta <tputta@nvidia.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Now that OvmfPkg/SataControllerDxe and its MdeModulePkg counterpart have
been unified, and no in-tree uses of the OVMF variant remain, let's
delete it.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the OvmfXen platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the AmdSev platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the IntelTdx platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the CloudHv platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the Microvm platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for OvmfPkg{Ia32, X64, Ia32X64} platforms.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
ASSERT (Private != NULL) (where Private = CR(...)) is ineffective as
CR(Ptr, Type, Member, Sig) either returns Ptr - offsetof(Type, Member),
or ASSERTS on the signature, so it's unlikely to ever return NULL (must
be passed a pointer = member's offset, or in this case, 0x4).
ASSERT on This != NULL instead.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
When a UEFI_DRIVER attempts to open a protocol interface with BY_DRIVER
attribute that it already has open with BY_DRIVER attribute,
OpenProtocol() returns EFI_ALREADY_STARTED. This is not an error. The
UEFI-2.7 spec currently says,
> EFI_ALREADY_STARTED -- Attributes is BY_DRIVER and there is an item on
> the open list with an attribute of BY_DRIVER
> whose agent handle is the same as AgentHandle.
Downgrade the log mask for this one condition to DEBUG_INFO, in
SataControllerStart(). This will match the log mask of the other two
informative messages in this function.
(ported from commit 5dfba97)
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The ArmGicAcknowledgeInterrupt () returns the value returned by the
Interrupt Acknowledge Register and the InterruptID separately in an out
parameter.
The function documents the following: 'InterruptId is returned
separately from the register value because in the GICv2 the register
value contains the CpuId and InterruptId while in the GICv3 the register
value is only the InterruptId.'
This function skips setting the InterruptId in the out parameter for
GICv3. Although the return value from the function is the InterruptId
for GICv3, this breaks the function usage model as the caller expects
the InterruptId in the out parameter for the function. e.g. The caller
may end up using the InterruptID which could potentially be an
uninitialised variable value.
Therefore, set the InterruptID in the function out parameter for GICv3
as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
According to the GIC architecture version 3 and 4 specification, the
maximum number of INTID bits supported in the CPU interface is 24.
Considering this the RegShift variable is not required to be more than 8
bits. Therefore, make the RegShift variable type to UINT8. Also add
necessary typecasts when calculating the RegOffset and RegShift values.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
GICD_SGIR is a 32-bit register, of which INTID is bits [3:0] and Bits
[14:4] is RES0. Since SgiId parameter in the function ArmGicSendSgiTo ()
is UINT8, mask unused bits of SgiId before writing to the GICD_SGIR
register to prevent accidental setting of the RES0 bits.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The IrqInterruptHandler () and ExitBootServicesEvent () function
declarations were unused. Therefore, remove these declarations.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The EIOR register of the Gic CPU interface is a 32 bit register.
However, the HARDWARE_INTERRUPT_SOURCE used to represent the interrupt
source (Interrupt ID) is typedefed as UINTN, see
EmbeddedPkg\Include\Protocol\HardwareInterrupt.h
Therfore, typecast the interrupt ID (Source) value to UINT32 before
setting the EOIR register. Also, add an assert to check that the value
does not exceed 32 bits.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Although the maximum interrupt ID on GicV2 is 10bit and for GicV3/4 is
24bit, and that the IAR and EOIR registers of the Gic CPU interface are
32 bit; the typedef HARDWARE_INTERRUPT_SOURCE is defined as UINTN in
EmbeddedPkg\Include\Protocol\HardwareInterrupt.h
Therefore, use UINTN for Gic Interrupt variables and use appropriate
typecasts wherever needed.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The CPU Interface Identification Register (GICC_IIDR) is a 32-bit
register. Since ArmGicGetInterfaceIdentification () returns the value
read from the GICC_IIDR register, update the return type for this
function to UINT32.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
According to edk2 coding standard specification, Non-Boolean comparisons
must use a compare operator (==, !=, >, < >=, <=). See Section 5.7.2.1
at https://edk2-docs.gitbook.io/
edk-ii-c-coding-standards-specification/5_source_files/ 57_c_programming
Therefore, fix the comparison in ArmGicEnableDistributor()
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The Software Generated Interrupt Register (GICD_SGIR) is a 32 bit
register with the following bit assignment:
TargetListFilter, bits [25:24]
CPUTargetList, bits [23:16]
NSATT, bit [15]
SGIINTID, bits [3:0]
Therefore, modify the TargetListFilter, CPUTargetList, SGI Interrupt ID
parameters of the ArmGicSendSgiTo () to use UINT8 instead of INTN.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The data type used by variables representing the
GicInterruptInterfaceBase has been inconsistently used in the ArmGic
driver and the library. The PCD defined for the GIC Interrupt interface
base address is UINT64. However, the data types for the variables used
is UINTN, INTN, and at some places UINT32.
Therefore, update the data types to use UINTN and add necessary
typecasts when reading values from the PCD. This should then be
consistent across AArch32 and AArch64 builds.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The data type used by variables representing the GicDistributorBase has
been inconsistently used in the ArmGic driver and the library. The PCD
defined for the GIC Distributor base address is UINT64. However, the
data types for the variables used is UINTN, INTN, and at some places
UINT32.
Therefore, update the data types to use UINTN and add necessary
typecasts when reading values from the PCD. This should then be
consistent across AArch32 and AArch64 builds.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
In case a virtio serial device is found in the system register the first
console port as EFI console, by updating ConIn, ConOut and ErrOut.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
IsVirtioPciRng() becomes just a thin wrapper for IsVirtioPci().
This allows to add similar thin wrappers for other virtio
devices in the future.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
IsVirtioRng() becomes just a thin wrapper for IsVirtio().
This allows to add similar thin wrappers for other virtio
devices in the future.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The #define for IMAGE_FILE_MACHINE_ARM is not present in MdePkg,
this looks like a relic not used any more. Remove.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The BaseTools and MdePkg versions of PeImage.h diverged over time,
add some missing bits to the MdePkg header file in preparation for
removing the BaseTools version.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Appears to be a relic for ancient windows / compiler versions,
windows builds in CI work just fine without it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Not needed any more on modern toolchains, they are better
in not creating a GOT without this trick.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Older linux kernels have problems with phys-bits larger than 46,
ubuntu 18.04 (kernel 4.15) has been reported to be affected.
Reduce phys-bits limit from 47 to 46.
Reported-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Flash can be write-protected in qemu (which is usually the case for
code). In case the variable store flash block is configured read-only
ovmf wouldn't be able to store EFI variables there, so not setting up
fvb in that case (and fallhack to emulation) is the better option.
It'll avoid problems later due to flash writes failing.
The patch tries to write back the original value read earlier, so flash
content doesn't change in case the write succeeds. But the status we
read back after the attempt to write will tell us whenever flash is
writable or not.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Apparently TPL_CALLBACK is too low, code runs into an ASSERT
complaining the new TPL is lower than the old TPL.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4424
In Relaxed-AP Sync Mode, BSP will not wait for all Aps arrive. However,
PerformRemainingTasks() needs to wait all Aps arrive before calling
SetMemMapAttributes and ConfigSmmCodeAccessCheck() when mSmmReadyToLock
is true. In SetMemMapAttributes(), SmmSetMemoryAttributesEx() will call
FlushTlbForAll() that need to start up the aps. So it need to let all
aps arrive. Same as SetMemMapAttributes(), ConfigSmmCodeAccessCheck()
also will start up the aps.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhihao Li <zhihao.li@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4431
In Ap relaxed mode, some SMI handlers should call SmmWaitForApArrival() to let all ap arrive in SmmCpuRendezvous(). But in traditional mode, these SMI handlers don't need to call SmmWaitForApArrival() again. So it need to be check cpu sync mode before calling SmmWaitForApArrival().
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhihao Li <zhihao.li@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
System paging 5 level enabled or not can be checked via CR4.LA57, system
preferred Page table Level (PcdUse5LevelPageTable) must align with previous
level for 64bit long mode.
This patch is to do the wise check:
If cpu has already run in 64bit long mode PEI, Page table Level in DXE
must align with previous level.
If cpu runs in 32bit protected mode PEI, Page table Level in DXE is decided
by PCD and feature capability.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Background:
For arch X64, system will enable the page table in SPI to cover 0-512G
range via CR4.PAE & MSR.LME & CR0.PG & CR3 setting (see ResetVector code).
Existing code doesn't cover the higher address access above 512G before
memory-discovered callback. That will be potential problem if system
access the higher address after the transition from temporary RAM to
permanent MEM RAM.
Solution:
This patch is to migrate page table to permanent memory to map entire physical
address space if CR0.PG is set during temporary RAM Done.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add a macro USE_5_LEVEL_PAGE_TABLE to determine whether to create
5 level page table.
If macro USE_5_LEVEL_PAGE_TABLE is defined, PML5Table is created
at (4G-12K), while PML4Table is at (4G-16K). In runtime check, if
5level paging is supported, use PML5Table, otherwise, use PML4Table.
If macro USE_5_LEVEL_PAGE_TABLE is not defined, to save space, 5level
paging is not created, and 4level paging is at (4G-12K) and be used.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
In ResetVector, if create page table, its highest address is fixed
because after page table, code layout is fixed(4K for normal code,
and another 4K only contains reset vector code).
Today's implementation organizes the page table as following if 1G
page table is used:
4G-16K: PML4 page (PML4[0] points to 4G-12K)
4G-12K: PDP page
CR3 is set to 4G-16K
When 2M page table is used, the layout is as following:
4G-32K: PML4 page (PML4[0] points to 4G-28K)
4G-28K: PDP page (PDP entries point to PD pages)
4G-24K: PD page mapping 0-1G
4G-20K: PD page mapping 1-2G
4G-16K: PD page mapping 2-3G
4G-12K: PD page mapping 3-4G
CR3 is set to 4G-32K
CR3 doesn't point to a fixed location which is a bit hard to debug at
runtime.
The new page table layout will always put PML4 in highest address
When 1G page table is used, the layout is as following:
4G-16K: PDP page
4G-12K: PML4 page (PML4[0] points to 4G-16K)
When 2M page table is used, the layout is as following:
4G-32K: PD page mapping 0-1G
4G-28K: PD page mapping 1-2G
4G-24K: PD page mapping 2-3G
4G-20K: PD page mapping 3-4G
4G-16K: PDP page (PDP entries point to PD pages)
4G-12K: PML4 page (PML4[0] points to 4G-16K)
CR3 is always set to 4G-12K
So, this patch can improve debuggability by make sure the init
CR3 pointing to a fixed address(4G-12K).
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
This patch only renames macro, with no code logic impacted.
Two purpose to rename macro:
1. Align some macro name in PageTables1G.asm and PageTables2M.asm, so
that these two files can be easily combined later.
2. Some Macro names such as PDP are not accurate, since 4 level page
entry also uses this macro. PAGE_NLE (no leaf entry) is better
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4200
FspData->PerfIdx is getting increased for every call unconditionally
in the function SetFspMeasurePoint and hence memory access can happen
for out of bound FspData->PerfData[] array entries also.
Example -
FspData->PerfData is an array of 32 UINT64 entries. Assume a call
is made to SetFspMeasurePoint function when the FspData->PerfIdx
last value is 31. It gets incremented to 32 at line 400.
Any subsequent call to SetFspMeasurePoint functions leads to
FspData->PerfData[32] getting accessed which is out of the PerfData
array as well as the FSP_GLOBAL_DATA structure boundary.
Hence keep array access and index increment inside if block only and
return invalid performance timestamp when PerfIdx is invalid.
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Acked-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Fix incorrect value type issue for checked-box op-code.
When the variable for checked-box is defined as UINT8 in
varstore structure, IFR compiler assign its value type to
EFI_IFR_TYPE_NUM_SIZE_8 instead of EFI_IFR_TYPE_BOOLEAN.
However, the value type for checked-box is boolean value.
Redfish service may return error because of incorrect value
type passed to BIOS attribute registry.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
contains an assertion that EfiConventionalMemory and EfiBootServicesData
are subjected to the same policy when it comes to the use of NX
permissions. The reason for this is that we may otherwise end up with
unbounded recursion in the page table code, given that allocating a page
table would then involve a permission attribute change, and this could
result in the need for a block entry to be split, which would trigger
the allocation of a page table recursively.
For the same reason, a shortcut exists in ApplyMemoryProtectionPolicy()
where, instead of setting the memory attributes unconditionally, we
compare the NX policies and avoid touching the page tables if they are
the same for the old and the new memory types. Without this shortcut, we
may end up in a situation where, as the CPU arch protocol DXE driver is
ramping up, the same unbounded recursion is triggered, due to the fact
that the NX policy for EfiConventionalMemory has not been applied yet.
To break this cycle, let's remap all EfiConventionalMemory regions
according to the NX policy for EfiBootServicesData before exposing the
CPU arch protocol to the DXE core and other drivers. This ensures that
creating EfiBootServicesData allocations does not result in memory
attribute changes, and therefore no recursion.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Map the code flash with read-only attributes so we can execute from it
even under a memory protection regime that enables WXN, making all
writable memory regions non-executable by default.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The VariableRuntimeDxe links with NvVarStoreFormattedLib which is
required to establish the dependency on OvmfPkg\VirtNorFlashDxe.
The VirtNorFlashDxe installs the gEdkiiNvVarStoreFormattedGuid to
indicate it has finished initialising the flash variable storage
and that the variable service can be dispatched.
However, the kvmtool guest firmware dynamically detects if CFI
flash is absent and sets PcdEmuVariableNvModeEnable to TRUE
indicating emulated runtime variable must be used. Therefore,
in this scenario install the gEdkiiNvVarStoreFormattedGuid so
that the variable service can be dispatched.
Also link the NorFlashKvmtoolLib as a NULL library so that
it can discover if the CFI flash is absent and setup the PCD
PcdEmuVariableNvModeEnable. This is required in case the
NorFlashDxe is not yet dispatched.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The kvmtool option '--flash <flash filename>' is used to launch
a guests VM with a CFI flash device that maps the flash file
specified at the command line.
However, kvmtool allows guest VMs to be launched without a CFI
flash device. In such scenarios the firmware can utilize the
emulated variable storage for UEFI variables. To support this
the PCD gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable
must be set to TRUE.
Therefore, update the NorFlashKvmtoolLib to fallback to variable
emulation if a CFI device is not detected. Also improve the error
logging.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Kvmtool allows guest VMs to be launched with or without a
CFI flash device.
When the kvmtool option '--flash <flash filename>' is used to
launch a guest VM a CFI flash device maps the flash file that
was specified at the command line. The NorFlash driver uses
this flash as the variable storage backend.
However, when the above option is not specified, a CFI flash
device is not present. In such cases, the firmware can fallback
to use emulated runtime variables (which uses the VMs DRAM as
the storage backend).
Therefore, define the PCD PcdEmuVariableNvModeEnable required
to enable the emulated runtime variable support, but do not
enable it by default.
The firmware is expected to dynamically discover if the CFI
flash is present and subsequently enable NorFlash or emulate
the runtime variables.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The PCD gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable
indicates if a variable driver will emulate the variable NV mode.
This PCD is defined as [PcdsFixedAtBuild, PcdsPatchableInModule,
PcdsDynamic, PcdsDynamicEx].
Some firmware builds may define this PCD as a dynamic PCD and
initialise the value at runtime. Therefore, move the PCD declaration
from the [FixedPcd] section to the [Pcd] section in the platform
boot manager library file PlatformBootManagerLib.inf. Without this
change the build would not succeed.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The patch "f07a9df9af60 ArmVirtPkg: Enable stack guard"
enabled stack overflow detection for ArmVirtPkg. Following
this patch, running UEFI shell command 'dmpstore' resulted
in a crash indicating a stack overflow. Invoking 'dmpstore'
results in recursive calls to CascadeProcessVariables ()
which apparently consumes the available stack space and
overflows.
Normally, SEC and PEI run off the initial stack, and the
DxeIpl PEIM is in charge of launching the DxeCore with a
full-sized stack and remapping it non-executable as well.
PrePi platforms take some shortcuts and the DXE and BDS
run off the initial stack which is relatively small. It
is therefore desirable to allocate 128 KiB worth of boot
services data memory as the stack for the Dxe phase.
The PrePiMain () in ArmVirtPkg/PrePi/PrePi.c invokes the
LoadDxeCoreFromFv () to load the Dxe core and transfers
control. The second parameter to LoadDxeCoreFromFv () is
the stack size, which is currently set to 0.
LoadDxeCoreFromFv () is implemented in PrePiLib and if the
stack size is 0, it continues to use the initial stack.
However, if a stack size is specified in the call to
LoadDxeCoreFromFv (), memory is allocated for a new stack
and the stack is switched to use the newly allocated stack
for the Dxe phase.
Therefore, specify 128 KiB as the stack size in the call to
LoadDxeCoreFromFv () so that a separate stack is allocated
and used for the Dxe phase.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4463
When the AARCH64 CpuDxe attempts to SyncCacheConfig() with the GCD, it
collects the page attributes as:
EntryAttribute = Entry & TT_ATTR_INDX_MASK
However, TT_ATTR_INDX_MASK only masks the cacheability attributes and
drops the memory protections attributes. Importantly, it also drops the
TT_AF (access flag) which is now wired up in EDK2 to represent
EFI_MEMORY_RP, so by default all SystemMem pages will report as
EFI_MEMORY_RP to the GCD. The GCD currently drops that silently, because
the Capabilities field in the GCD does not support EFI_MEMORY_RP by
default.
However, some ranges may support EFI_MEMORY_RP and incorrectly mark
those ranges as read protected. In conjunction with another change on
the mailing list (see: https://edk2.groups.io/g/devel/topic/98505340),
this causes an access flag fault incorrectly. See the linked BZ below
for full details.
This patch exposes all memory protections attributes to the GCD layer so
it can correctly set pages as EFI_MEMORY[RP|XP|RO] when it initially
syncs.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Taylor Beebe <t@taylorbeebe.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
If PcdUse1GPageTable is not enabled restrict the physical address space
used to 1TB, to limit the amount of memory needed for identity mapping
page tables.
The same already happens in case the processor has no support for
gigabyte pages.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Flip the default for IO address space reservations for PCI(e) bridges
and root ports with hotplug support from TRUE to FALSE.
PCI(e) bridges will still get IO address space assigned in case:
(a) Downstream devices actually need IO address space, or
(b) Explicit configuration, using "qemu -device
pcie-root-port,io-reserve=<size>".
In case IO address space is exhausted edk2 will stop assigning resources
to PCI(e) bridges. This is not limited to IO resources, the affected
bridges will not get any memory resources assigned either.
This patch solves this issue by not handing out the scarce IO address
space, which is not needed in most cases anyway. Result is a more
consistent PCI configuration in virtual machine configurations with many
PCie root ports.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
When calling SetValue() with string type input, there is
assertion of providing zero string ID to HII string function.
Fix this issue by creating string ID for input string buffer.
Fix Unicode and Ascii code convert issue together.
Add text op-code support
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
RTC runtime is unable to get dynamic PCD value after booting to
OS using runtime services.
Resolution: Cache the dynamic PCD value in RTC driver entry point
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Ideally behavior is like below order that can support one local build
machine, clone multiple Edk2, some of edk2 repo use old tag and
some of edk2 repo use new tag, they can both support on one machine.
1. if defined PYTHON_COMMAND only
- use PYTHON_COMMAND = user assigned
2. if not defined PYTHON_COMMAND, auto detect py -3
- use PYTHON_COMMAND = py -3
3. if defined PYTHON_COMMAND and PYTHON_HOME, use PYTHON_COMMAND
- use PYTHON_COMMAND = user assigned
4. if defined PYTHON_HOME only,
- use PYTHON_COMMAND = %PYTHON_HOME%/python.exe
SCRIPT_ERROR should return for paraent batch file to consume
for error handle.
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: Gua Guo <gua.guo@intel.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4438
The main dispatch loop in PeiDispatcher() goes through each FV and
calls DiscoverPeimsAndOrderWithApriori() to search Apriori file to
reorder all PEIMs then do the PEIM dispatched.
DiscoverPeimsAndOrderWithApriori() calculates Apriori file count for
every FV once and set Private->AprioriCount, but Private->AprioriCount
doesn't be set to 0 before dispatch loop walking through the next FV.
It causes the peim which sort on less than Private->AprioriCount and
depex is not satisfied would be dispatched when dispatch loop go through
to a scaned FV, even the peim is not set in APRIORI file.
Cc: Leon Chen <leon.chen@insyde.com>
Cc: Tim Lewis <tim.lewis@insyde.com>
Reported-by: Esther Lee <esther.lee@insyde.com>
Signed-off-by: Wendy Liao <wendy.liao@insyde.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The helper that updates live page table entries writes a zero entry,
invalidates the covered address range from the TLBs, and finally writes
the actual entry. This ensures that no TLB conflicts can occur.
Writing the final entry needs to complete before any translations can be
performed, as otherwise, the zero entry, which describes an invalid
translation, may be observed by the page table walker, resulting in a
translation fault. For this reason, the final write is followed by a DSB
barrier instruction.
However, this barrier will not stall the pipeline, and instruction
fetches may still hit this invalid translation, as has been observed and
reported by Oliver. To ensure that the new translation is fully active
before returning from this helper, we have to insert an ISB barrier as
well.
Reported-by: Oliver Steffen <osteffen@redhat.com>
Tested-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
If the SerialPortLib had any initialization needed, this
would be skipped in the RiscVVirt Sec. Follow the example
seen elsewhere (ArmVirtPkg PrePi).
Seen with BaseSerialPortLibRiscVSbiLibRam not using DBCN in Sec,
yet using DBCN elsewhere.
Cc: Daniel Schaefer <git@danielschaefer.me>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
These are implementations of SerialPortLib using SBI console services.
- BaseSerialPortLibRiscVSbiLib is appropriate for SEC/PEI (XIP)
environments
- BaseSerialPortLibRiscVSbiLibRam is appropriate for PrePI/DXE
environments
Tested with:
- Qemu RiscVVirt (non-DBCN case, backed by UART)
- TinyEMU + RiscVVirt (non-DBCN case, HTIF)
- TinyEMU + RiscVVirt (DBCN case, HTIF)
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
After moving BDS driver to a new FV for universal UEFI payload,
the shell boot option path is not correct since it used the BDS
FV instead of DXE FV in its device path.
This patch would find the correct FV by reading shell file.
It also removed PcdShellFile by using gUefiShellFileGuid.
Signed-off-by: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Reviewed-by: James Lu <james.lu@intel.com>
Reviewed-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: Mike Maslenkin <mike.maslenkin@gmail.com>
The warnings Clang emits when enabling -Wunneeded-internal-declaration
(which is part of -Wall) are generating false positives for variables
whose size gets taken but are not referenced beyond yet.
This may happen legitimately in debug code, so let's disable this
warning for Clang, rather than tiptoe around it in the code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
When using CLANGDWARF to build for the ARM architecture, objcopy is
references via the wrong environment variable, resulting in the wrong
llvm-objcopy to be used (if one exists), or the build to fail (if
CLANGDWARF_BIN points to the only available instance)
So use CLANGDWARF_BIN instead, which was what was intended.
Fixes: ecbc394365 ("BaseTools: Set CLANGDWARF RC path ...")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3805
Replace hardcoded SMBIOS Anchor string and size with defines.
Fix buffer overflow as described below.
Smbios64BitPrintEPSInfo () is coded like:
UINT8 Anchor[5];
MemToString (Anchor, SmbiosTable->AnchorString, 5);
But the definition of MemToString()
Copy Length of Src buffer to Dest buffer,
add a NULL termination to Dest buffer.
So Anchor needs to be +1 the size of the SMBIOS Anchor string `_SM3_`.
Changes from v1 to v2:
- Replace doxygen style inline comments
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Andrew Fish <afish@apple.com>
Signed-off-by: Giri Mudusuru <girim@apple.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Windows command prompt have 8191 characters limitation,
enhance it to make command too long can be resloved.
Provide an example, if have too many cov files, it causes to run single
command over the 8191 characters limitation.
> OpenCppCoverage
> --export_type binary:coverage.cov
> --working_dir={workspace}Build
> --input_coverage=AAA.cov
> ...
> --input_coverage=NNN.cov
The solution is passing many coverage files in single command line to
breaking it up into many command lines with one coverage file per
command line in order to prevent single line is over to 8191 characters.
- Command Line 1
> OpenCppCoverage
> --export_type binary:coverage.cov
> --working_dir={workspace}Build
> --input_coverage=AAA.cov
> --input_coverage=coverage.cov
...
- Command Line N
> OpenCppCoverage
> --export_type. binary:coverage.cov
> --working_dir={workspace}Build
> --input_coverage=NNN.cov
> --input_coverage=coverage.cov
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
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: Gua Guo <gua.guo@intel.com>
Reviewed-by: Michael Kubacki <mikuback@linux.microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
On Windows, executables have a '.exe' suffix which needs to be added for
them to be found in a path.
Also, files need to be explicitly opened as binary.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
The BASETOOLS_PYTHON_SOURCE environment variable is only used temporarily to
set PYTHONPATH. Since it doesn't help improve clarity, remove it.
While here, make sure we set PYTHONPATH when we're using Pip BaseTools
so that build etc. can be found.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
This reverts commit 11f62f4cc0.
While GCC uses objcopy for the OBJCOPY command, it's not needed for the
CLANGDWARF toolchain and can be left as echo.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard BIesheuvel <ardb@kernel.org>
Use PlatformBootManagerLib with PcdBootRestrictToFirmware
set to TRUE instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
In case PcdBootRestrictToFirmware is set, disable loading EFI variables
from NvVars file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add new PCD PcdBootRestrictToFirmware. When set to TRUE restrict
boot options to EFI applications embedded into the firmware image.
Behavior should be identical to the PlatformBootManagerLibGrub
library variant.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Remove bashisms from edksetup.sh and BaseTools/BuildEnv. This allows any
POSIX shell to use those scripts, removing the dependency on bash.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The build rule for Hii-Binary-Package.UEFI_HII should be the same as for
GCC, using $(RC) to embed the HII resource into the binary. Since the
build rule defaults to GCC, just remove CLANGGCC from the section.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
The llvm-rc tool is for Windows PE resources. Since the CLANGDWARF
toolchain creates ELF binaries, update the RC path to be llvm-objcopy.
This follows the GCC toolchain which uses objcopy for the RC path.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
There's only a single rule in build_rule.template for CLANGGCC, and it's
incorrect. We should instead just use the rules for GCC, so remove the
BUILDRULEFAMILY line for the CLANGDWARF toolchain definition.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Since CLANG35 and CLANG38 toolchains have been deleted from
tools_def.template, delete the build flags for them from CryptoPkg.
Since CLANGDWARF has replaced CLANG38, add build flags for it to the
CryptoPkg .inf files.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
specification) and so we should never encounter a situation in which
an interrupt occurs at TPL_HIGH_LEVEL. The specification also
restricts usage of TPL_HIGH_LEVEL to the firmware itself.
However, nothing actually prevents a UEFI application from calling
gBS->RaiseTPL(TPL_HIGH_LEVEL) and then violating the invariant by
enabling interrupts via the STI or equivalent instruction. Some
versions of the Microsoft Windows bootloader are known to do this.
NestedInterruptTplLib maintains the invariant that interrupts are
disabled at TPL_HIGH_LEVEL (even when performing the dark art of
deliberately manipulating the stack so that IRET will return with
interrupts still disabled), but does not itself rely on external code
maintaining this invariant.
Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
to an error message, to allow UEFI applications such as these versions
of the Microsoft Windows bootloader to continue to function.
Debugged-by: Gerd Hoffmann <kraxel@redhat.com>
Debugged-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
NestedInterruptTplLib relies on CPU interrupts being disabled to
guarantee exclusive (and hence atomic) access to the shared state in
IsrState. Nothing in the calling interrupt handler should have
re-enabled interrupts before calling NestedInterruptRestoreTPL(), and
the loop in NestedInterruptRestoreTPL() itself maintains the invariant
that interrupts are disabled at the start of each iteration.
Add assertions to clarify this invariant, and expand the comments
around the calls to RestoreTPL() and DisableInterrupts() to clarify
the expectations around enabling and disabling interrupts.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Update toolsetup.bat and Tests/PythonTest.py to check if we're running a
version of Python that's compatible with BaseTools and the Pip
BaseTools.
BaseTools uses syntax from Python 3.6 or newer, so set that as the minimum
version EDK2 requires.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
If toolsetup.bat fails (i.e. exits with a non-zero %ERRORLEVEL%), don't
try and carry on but just quit.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
threading.currentThread is a deprecated alias for
threading.current_thread, and causes a warning to be displayed when it's
called. Update NmakeSubdirs.py to use the latter method instead.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Since Python3 is now required, we can remove the checks for PYTHON3_ENABLE
and PYTHON3 and simplify the code in toolsetup.bat. Also, remove the
leftover from when we supported freezing Python code.
While here, fix a couple of typos and improve error messages.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
When a MAC address matching interface is found, a RestEx child will be
created to provide the Redfish communication on that interface.
Currently, It will try to locate all RestEx binding services and choose
the first satisfied instance without taking care about current selected
interface. This might raise an issue on the system with multiple network
devices that the RestEx child was installed on wrong interface.
Signed-off-by: Minh Nguyen <minhnguyen1@os.amperecomputing.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <Abner.Chang@amd.com>
Clang 3.8 is a very old release and is no longer relevant. Delete the
CLANG38 toolchain from tools_def.template.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Clang 3.5 is a very old release and is no longer relevant. Remove the
CLANG35 toolchain from tools_def.template.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
As with the IA32 and X64 CLANGDWARF toolchain definitions, use ld.lld
for ARM and AARCH64.
Add -Wl,--no-pie,--no-relax to the command line to fix linking when
using lld.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Add a 'GCC' toolchain that's a copy of the existing GCC5 definition.
Add a 'GCCNOLTO' toolchain that's a copy of the existing GCC49
toolchain.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Update the Visual Studio toolchain descriptions in
tools_def.txt.template:
- The WinDDK is no longer needed.
- Update 3 is required for VS 2015.
- VS 2005 has been removed.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
The edk2-stable202302 release was the last to support building
EFI Byte Code drivers. Since the Intel EFI Byte Code Compiler is no
longer available, a decision has been made to remove support for EBC
from edk2.
Remove the definitions for Intel's EBC compiler from
Conf/tools_def.template.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
With recent changes, Visual Studio versions older than VS2015 are
unable to build EDK2 code.
To avoid confusion, remove VS2008, 2010, 2012 and 2013 toolchain
definitions from Conf/tools_def.template, leaving only versions that can
be used to successfully build firmware.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Older versions of GenFw put the wrong value in the debug directory size
field in the PE/COFF header: instead of putting the combined size of all
the entries, it puts the size of the only entry it creates, but adds the
size of the NB10 payload that the entry points to. This confuses the
loader now that we started using additional debug directory entries to
describe DLL characteristics.
GenFw was fixed in commit 60e85a39fe, but the binaries that were
generated with it still need to be supported.
So let's detect this condition, and check whether the size of the debug
directory is consistent with the NB10 payload: if we should expect
additional directory entries where we observe the NB10 payload, the size
field is clearly wrong, and we can break from the loop.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4425
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Tested-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Add a driver for the virtio serial device.
The virtio serial device also known as virtio console device because
initially it had only support for a single tty, intended to be used as
console. Support for multiple streams and named data ports has been
added later on.
The driver supports tty ports only, they are registered as SerialIo
UART in the system.
Named ports are detected and logged, but not exposed as devices. They
are usually used by guest agents to communicate with the host. It's not
clear whenever it makes sense for the firmware to run such agents and if
so which efi protocol could be to expose the ports. So leaving that for
another day.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add header files with structs and defines for the virtio serial device.
The virtio serial device also known as virtio console device because
initially it had only support for a single tty, intended to be used as
console. Support for multiple streams and named data ports has been
added later on.
https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-2900003
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ArmVirtXen.dsc initializes
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString with with the
value of the variable "FIRMWARE_VER".
Move that functionality to ArmVirt.dsc.inc to make it available to all
ArmVirt packages, and make it conditional: only set the PCD string if
FIRMWARE_VER is actually defined.
This allows specifying the firmware version string on the build command
line with -D FIRMARE_VER=...
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Initialize gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString with
with the value of the variable "FIRMWARE_VER", if is is defined. Applies
to all flavors of OvmfPkg.
This behavior is already implemented in ArmVirtXen.dsc. It allows
specifying the firmware version string on the build command line with
-D FIRMARE_VER=...
Introduce a common include file to be used in the .dsc files for the
different OVMF flavors, and add the changes there. (ArmVirtPkg already
has such a file).
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
The UEFI Shell is a non-active boot option, at the opposite of UiApp.
If no valid boot option is found, UiApp is selected. UiApp requires a
human interaction. When installing a new EDKII image in CIs or when
scripting is required, this is problematic.
If no valid boot option is discovered, add a path to directly go to
the UEFI Shell where the startup.nsh script is automatically executed.
The UEFI Shell is launched after connecting possible devices, but
before the reset that is meant to automatically make them visible.
The new PcdUefiShellDefaultBootEnable must be set to TRUE to enable
this behaviour. The Pcd is set to false by default.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Tested-by: Patrik Berglund <patrik.berglund@arm.com>
The code blindly assumes a TIS interface is present in case both CRB and
FIFO checks fail. Check the InterfaceType for TIS instead and only
return PtpInterfaceTis in case it matches, PtpInterfaceMax otherwise.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The code blindly assumes a TIS interface is present in case both CRB and
FIFO checks fail. Check the InterfaceType for TIS instead and only
return Tpm2PtpInterfaceTis in case it matches, Tpm2PtpInterfaceMax
otherwise.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
This is the Implementation of EDKII_REDFISH_PLATFORM_CONFIG_PROTOCOL,
which is the EDKII Redfish Platform Config driver instance that accesses
EDK2 HII configuration format and storage.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Igor Kulchytskyy <igork @ami.com>
EDKII Redfish Platform Config Protocol defines the protocol
interfaces that abstracts the platform configuration format
and storage from EDK2 Redfish Feature driver. This protocol
provides the interfaces to get and set platform configuration
with the format and configuration storage agnostic to the
Redfish feature driver.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Igor Kulchytskyy <igork @ami.com>
Arm CI build error:
- ArmPkg/Library/CompilerIntrinsicsLib/memset.c:39:1: warning: type of
‘memset’ does not match original declaration [-Wlto-type-mismatch]
MdeModulePkg/Universal/RegularExpressionDxe/OnigurumaUefiPort.c:123:1:
note: type ‘char’ should match type ‘int’
- multiple definition of `memcpy'; OnigurumaUefiPort.obj (symbol from
plugin):(.text+0x0): first defined here
Fix:
- Update memset() implementation to match memset() definition in
ArmPkg/Library/CompilerIntrinsicsLib.
- memcpy() is supported by ArmPkg/Library/CompilerIntrinsicsLib. Exclude
it in OnigurumaUefiPort.c.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Add the AUTH_SIG_NOT_FOUND Action to the Image Execution Info Table
when the Image is signed but signature is not allowed by DB and the
hash of image is not found in DB/DBX.
This is documented in the UEFI spec 2.10, table 32.5.
This issue is found by the SIE SCT with the error message as follows:
SecureBoot - TestImage1.bin in Image Execution Info Table with
SIG_NOT_FOUND. --FAILURE
B3A670AA-0FBA-48CA-9D01-0EE9700965A9
SctPkg/TestCase/UEFI/EFI/RuntimeServices/SecureBoot/BlackBoxTest/
ImageLoadingBBTest.c:1079:Status Success
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Azure should install code coverage tool (lcov), it didn't
exist on Fedora and Ubuntu by default.
Update docker setting, pick below solution between 47addc9 and 3b3eb8f
3b3eb8f Fixes and improvements to dev containers (#69)
54e5bd1 Enable GTK on Fedora QEMU (#63)
f1c7a20 Fedora: install code coverage tools for GCC (#62)
2ce82af Ubuntu-22: Add initial Ubuntu-22 image (#61)
14d2aba Add Fedora 37 image with gcc12 (#60)
5b8a008 Add dotnet runtime to fedora build (#57)
f5c874a Fix platform build file name for EDK2 change (#58)
48540ad Ubuntu-20: Fix dev image entrypoint (#55)
98e849d Fedora-35: Add Powershell to build image (#52)
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Oliver Steffen <osteffen@redhat.com>
Cc: Chris Fernald <chfernal@microsoft.com>
Signed-off-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kubacki <mikuback@linux.microsoft.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Currently OVMF tries to rely on the base size advertised via the CPUID
table entries corresponding to leaf 0xD, sub-leafs 0x0/0x1. This will
generally work for KVM guests, but might not for other SEV-SNP
hypervisor implementations. Make the handling more robust by simply
using the base area size documented by the APM.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
CPUID leaf 0xD sub-leafs 0x0 and 0x1 contain cumulative sizes for the
enabled XSave areas. Those sizes are calculated by tallying up all the
other sub-leafs that contain per-area size information for XSave areas
that are currently enabled in XCr0/XSS. The current check has the logic
inverted. Fix that.
This doesn't seem to cause problems currently, but could in the future
if OVMF made more extensive use of XSave areas. It was noticed while
implementing SNP-related tests for KVM Unit Tests, which re-uses the
OVMF #VC handler in some cases.
Reported-by: Pavan Kumar Paluri <papaluri@amd.com>
Cc: Pavan Kumar Paluri <papaluri@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
The Confidential Computing blob defined here is intended to match the
definition defined by linux guest kernel. Previously, both definitions
relied on natural alignment, but that relies on both OVMF and kernel
being compiled as 64-bit. While there aren't currently any plans to
enable SNP support for 32-bit compilations, the kernel definition has
since been updated to use explicit padding/reserved fields to avoid
this dependency. Update OVMF to match that definition.
While at it, also fix up the Reserved fields to match the numbering
used in the kernel.
No functional changes (for currently-supported environments, at least).
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
The SEV-SNP Confidential Computing blob contains metadata that should
remain accessible for the life of the guest. Allocate it as
EfiACPIReclaimMemory to ensure the memory isn't overwritten by the guest
operating system later.
Reported-by: Dov Murik <dovmurik@linux.ibm.com>
Suggested-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
gRedfishDiscoveredToken may be allocated several times,
if multiple NIC installed on the system.
To avoid this issue Discover Token related global variables
replaced with the local variables.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
The topology of a platform is represented in ACPI using the PPTT
table. It is possible to append information to CPUs/processor
containers using their associated AML nodes in a SSDT
table.
A platform might have multiple 'physical packages' (or top-level
nodes) in their PPTT topology representation. It can be assumed
from [1] that a 'physical packages' is always a 'top-level node',
and conversely.
The SSDT topology generator doesn't support having multiple top-level
nodes. The top-level node is also not generated in the SSDT topology
representation.
Add support to generate multiple top-level nodes in the SSDT topology
generator and generate an AML node for this top-level node. This will
allow to have matching PPTT and SSDT topology representations. Prior
to this patch, this top-level AML node was not generated.
Also factorize the flag checking in CheckProcNode() and add more
checks.
This patch takes inspiration from the discussion at:
- v1: https://edk2.groups.io/g/devel/message/99410
- v2: https://edk2.groups.io/g/devel/message/99615
[1]
ACPI 6.5, 5.2.30.1 Processor hierarchy node structure (Type 0):
- "Multiple trees may be described, covering for example multiple
packages. For the root of a tree, the parent pointer should be 0.""
- "Each valid processor must belong to exactly one package. That is,
the leaf must itself be a physical package or have an ancestor
marked as a physical package."
Suggested-by: Jeff Brasen <jbrasen@nvidia.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add quotes around the OBJCOPY command in build_rule.template to fix the
case where LLVM is installed on Windows in a path with spaces such as
C:\Program Files\LLVM.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Bug #4414
Add DEBUG_MANAGEABILITY print error lever to
output debug message of detailed manageability
related module information, such as
- RedfishPkg:
- HTTP header/request/response
- JSON plain text
- Refish resource
- Redfish Host interface information
- Redfish credential information
- Platform configuration to Redfish mapping
- etc.
- ManageabilityPKg
- Protocol payload of MCTP/PLDM/IPMI
- Payload of transport interface transfers
- IPMI BLOB transfer
- etc.
- RedfishClinetPkg
- Redfish feature driver dispatcher
- Redfish BIOS attributes
- Platform configuration (HII) to
Redfish property information
- Redfish C structure information
- etc.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Cc: Tinh Nguyen <tinhnguyen@os.amperecomputing.com>
HostBasedUnitTestRunner.py is a build plugin responsible for locating
and executing host-based unit tests.
Recently, commit 6bb00aa introduced support for the plugin to
generate code coverage reports via lcov and OpenCppCoverage.
The plugin has discovered unit tests by searching for executables
with "Test" in the name for a while. However, the test coverage
change makes assumptions about test presence when crafting the
OpenCppCoverage command that ultimately fails with an ambiguous error
message if no host-based unit tests are discovered (see "ERROR").
```
SECTION - Run Host based Unit Tests
SUBSECTION - Testing for architecture: X64
ERROR - UnitTest Coverage: Failed to generate cobertura format xml in
single package.
PROGRESS - --->Test Success: Host Unit Test Compiler Plugin NOOPT
```
This change preempts that message with a check in the plugin to
determine if any host-based tests were discovered. If not, a message
is printed with more guidance about how the developer should proceed
to either (1) fix their tests so code coverage is generated as
expected or (2) prevent the error message.
New message:
```
SECTION - Run Host based Unit Tests
SUBSECTION - Testing for architecture: X64
WARNING - UnitTest Coverage:
No unit tests discovered. Test coverage will not be generated.
Prevent this message by:
1. Adding host-based unit tests to this package
2. Ensuring tests have the word "Test" in their name
3. Disabling HostUnitTestCompilerPlugin in the package CI YAML file
PROGRESS - --->Test Success: Host Unit Test Compiler Plugin NOOPT
```
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>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
As the ASM_FUNC() macro performs a section switch, the preceding
.balign directive applies the alignment constraint to the current
location in the previous section. As the linker may not merge the
sections in-order, ArmReplaceLiveTranslationEntry() may be left
unaligned.
Replace the explicit invocation of .balign with the ASM_FUNC_ALIGN()
macro, which guarantees the alignment constraint is applied correctly.
To make sure related issues are reliably caught in the future, align the
end of the function before checking the total occupied size. This
ensures crossing a 0x200 boundary will cause a compilation error.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
With the current ASM_FUNC() macro, there is no good way to declare an
alignment constraint for a function. As ASM_FUNC() switches sections,
declaring the constraint before the macro invocation applies it to the
current location in the previous section. Declaring the constraint after
the macro invocation lets the function label point to the location prior
to alignment. Depending on toolchain behaviour, this may cause the label
to point to alignment padding preceding the actual function definition.
To address these issues, introduce the ASM_FUNC_ALIGN() macro, which
declares the alignment constraint right before the function label.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add a .git-blame-ignore-revs file containing the hashes of every
uncrustify format commit as retrieved in:
git log --oneline --no-abbrev-commit | grep "uncrustify"
This file can be used by tools (such as GitHub[1]) to ignore
certain revisions when git blame-ing a file.
It can also be trivially usable locally by doing something akin
to:
git config blame.ignoreRevsFile .git-blame-ignore-revs
It may also be desirable in the future to add more commits to it.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[1]: https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/
To help people format patches with the correct options, add an alias
named 'fp' to SetupGit.py that runs format-patch with '-M --stat=1000
--stat-graph-width=20'.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
New code should use the C99 macro __func__ instead of the pre-Standard
macro __FUNCTION__. Update PatchCheck.py to reject patches with the
latter.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Add a new library, JedecJep106Lib which provides a service to return the
JEDEC JEP106 manufacturer string given the code and continuation bytes
values.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
FmpDevicePkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Wei6 Xu <wei6.xu@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
UefiPayloadPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: James Lu <james.lu@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
EmulatorPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Abner Chang <Abner.Chang@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
SourceLevelDebugPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
NetworkPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
CryptoPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
StandaloneMmPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
PrmPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
UnitTestFrameworkPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
ArmPlatformPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
RedfishPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
EmbeddedPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Abner Chang <abner.chang@amd.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
SecurityPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdeModulePkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
OvmfPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
UefiCpuPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
ArmVirtPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
ArmPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Update PrmPkg host-based unit test INF files to only list
VALID_ARCHITECTURES of IA32 and X64 to align with all other
host-based unit test INF files. The UnitTestFrameworkPkg only
provides build support of host-based unit tests to OS applications
for IA32 and X64.
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <mikuback@linux.microsoft.com>
Update MdeModulePkg host-based unit test INF files to only list
VALID_ARCHITECTURES of IA32 and X64 to align with all other
host-based unit test INF files. The UnitTestFrameworkPkg only
provides build support of host-based unit tests to OS applications
for IA32 and X64.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Update BaseLib host-based unit test INF file to only list
VALID_ARCHITECTURES of IA32 and X64 to align with all other
host-based unit test INF files. The UnitTestFrameworkPkg only
provides build support of host-based unit tests to OS applications
for IA32 and X64.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Update SecureBootVariableLib host-based unit test INF file to only
list VALID_ARCHITECTURES of IA32 and X64 to align with all other
host-based unit test INF files. The UnitTestFrameworkPkg only
provides build support of host-based unit tests to OS applications
for IA32 and X64.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
The unit test code for the SecureBootVariableLib is initializing
local variable structures in their declaration from other local
variables that are also initialized in their declaration. ANSI C
does not allow this and error 4122 is generated on VS20xx compilers.
The test cases are updated to initialize the local structure
fields in C statements instead of their local variable declaration.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4405
The memory attributes table has been extended with a flag that indicates
whether or not the OS is permitted to map the EFI runtime code regions
with strict enforcement for IBT/BTI landing pad instructions.
Given that the PE/COFF spec now defines a DllCharacteristicsEx flag that
indicates whether or not a loaded image is compatible with this, we can
wire this up to the flag in the memory attributes table, and set it if
all loaded runtime image are compatible with it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The generic and XCODE5 versions of this library are now identical, so
drop the special case. The library will be removed entirely in a
subsequent patch.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
The CPU exception handler library code was rewritten at some point to
populate the vector code templates with absolute references at runtime,
given that the XCODE linker does not permit absolute references in
executable code when creating PIE executables.
This is rather unfortunate, as this prevents us from using strict
permissions on the memory mappings, given that the .text section needs
to be writable at runtime for this arrangement to work.
So let's make this hack XCODE-only, by setting a preprocessor #define
from the command line when using the XCODE toolchain, and only including
the runtime fixup code when the macro is defined.
While at it, rename the Xcode5ExceptionHandlerAsm.nasm source file and
drop the Xcode5 prefix: this code is used by other toolchains too.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The PEI flavor of CpuExceptionHandlerLib never populates more than 32
IDT vectors, and there is no CET shadow stack support in the PEI phase.
So there is no need to use the generic ExceptionHandler NASM source,
which carries a 256-entry template and CET support, and writes to its
own .text section when built using XCODE, which is not permitted in the
PEI phase. So let's switch to the reduced SEC/PEI version of this
component, which is sufficient for PEI and doesn't suffer from the same
issue.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Currently, we use the non-Xcode5 version of ExceptionHandlerAsm.nasm
only for the SEC and PEI phases, and this version was not compatible
with the XCODE or LLD linkers, which do not permit absolute relocations
in read-only sections.
Given that SEC and PEI code typically executes in place from flash and
does not use page alignment for sections, we can simply emit the code
carrying the absolute symbol references into the .data segment instead.
This works around the linker's objections, and the resulting image will
be mapped executable in its entirety anyway. Since this is only needed
for XCODE, let's make this change conditionally using a preprocessor
macro.
Let's rename the .nasm file to reflect the fact that is used for the
SecPei flavor of this library only, and while at it, remove some
unnecessary absolute references.
Also update the Xcode specific version of this library, and use this
source file instead. This is necesessary, as the Xcode specific version
modifies its own code at runtime, which is not permitted in SEC or PEI.
Note that this also removes CET support from the Xcode5 specific build
of the SEC/PEI version of this library, but this is not needed this
early in any case, and this aligns it with other toolchains, which use
this version of the library, which does not have CET support either.
1. Change for non-XCODE SecPeiCpuExceptionHandlerLib:
. Use SecPeiExceptionHandlerAsm.nasm (renamed from
ExceptionHandlerAsm.nasm)
. Removed some unnecessary absolute references
(32 IDT stubs are still in .text.)
2. Change for XCODE SecPeiCpuExceptionHandlerLib:
. Use SecPeiExceptionHandlerAsm.nasm instead of
Xcode5ExceptionHandlerAsm.nasm
. CET logic is not in SecPeiExceptionHandlerAsm.nasm (but aligns to
non-XCODE lib instance)
. Fixed a bug that does runtime fixup in TEXT section in SPI flash.
. Emitted the code carrying the absolute symbol references into the
.data which XCODE or LLD linkers allow.
. Then fixup can be done by other build tools such as GenFv if the code
runs in SPI flash, or by PE coff loader if the code is loaded to
memory.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
We rely on PIE executables to get the codegen that is suitable for
PE/COFF conversion where the resulting executables can be loaded
anywhere in the address space.
However, ELF linkers may default to disallowing text relocations in PIE
executables, as this would require text segments to be updated at
runtime, which is bad for security and increases the copy-on-write
footprint of ELF executables and shared libraries.
However, none of those concerns apply to PE/COFF executables in the
context of EFI, which are copied into memory rather than mmap()'ed, and
fixed up by the loader before launch.
So pass -z notext to the LLD linker to permit runtime relocations in
read-only sections.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Update the antlr makefile to remove the explicit setting of CC to either
clang or gcc. This causes it to use /usr/bin/cc or whatever the user has
set $(CC) to.
This removes the last dependency on gcc for BaseTools.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The clang toolchain might default to fPIE/fPIC, which prevents
lld from linking the objects into a binary.
Specify -fno-pie -fno-pic as done on GCC to fix linking.
Test:
Building the Universal Payload using the command
'python UefiPayloadPkg/UniversalPayloadBuild.py -a IA32' actually
works.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4356
clang 17 defaults to C++17, where the 'register' keyword is deprecated
and the warning changed to an error. To avoid build errors, compile
against C++14 by specifying '-std=c++14' in CXXFLAGS.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was
added by having users specify "make CXX=llvm" when building BaseTools.
The Makefile then sees that and sets CC=$(CLANG_BIN)clang and
CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and
'clang++' exist and for example aren't named 'clang-17' and
'clang++-17'. Also, it's an unusual way of specifying the compiler,
since many users will expect to be able to override CC and CXX on the
make command line.
Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC
and BUILD_CXX) and using the standard name 'LDFLAGS' instead of
'LFLAGS'. This allows clang to be used by running
'make -C BaseTools CC=clang CXX=clang++'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was
added by having users specify "make CXX=llvm" when building BaseTools.
The Makefile then sees that and sets CC=$(CLANG_BIN)clang and
CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and
'clang++' exist and for example aren't named 'clang-17' and
'clang++-17'. Also, it's an unusual way of specifying the compiler,
since many users will expect to be able to override CC and CXX on the
make command line.
Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC
and BUILD_CXX) and using the standard name 'LDFLAGS' instead of
'LFLAGS'. This allows clang to be used by running
'make -C BaseTools CC=clang CXX=clang++'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bump the version of edk2-basetools in pip-requirements.txt to 0.1.43.
This version contains the update to generate makefiles with both
CFLAGS and BUILD_CFLAGS.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4391
FSP should support the scenario that CPU microcode already loaded
before calling LoadMicrocodeDefault(), in this case it should return
directly without spending more time.
Also the LoadMicrocodeDefault() should only attempt to load one version
of the microcode for current CPU and return directly without parsing
rest of the microcode in FV.
This patch also removed unnecessary LoadCheck code after supporting
CPU microcode already loaded scenario.
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Ted Kuo <ted.kuo@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
As recommended by CodeQL this change replaces
cpp/potential-buffer-overflow with cpp/overrunning-write-with-float
and cpp/overrunning-write.
Enables:
1. cpp/overrunning-write
- @name Likely overrunning write
- @description Buffer write operations that do not control the length
data written may overflow
- @kind problem
- @problem.severity error
- @security-severity 9.3
- @precision high
- @id cpp/very-likely-overrunning-write
- @tags reliability
- security
- external/cwe/cwe-120
- external/cwe/cwe-787
- external/cwe/cwe-805
2. cpp/overrunning-write-with-float
- @name Potentially overrunning write with float to string conversion
- @description Buffer write operations that do not control the length
of data written may overflow when floating point inputs
take extreme values.
- @kind problem
- @problem.severity error
- @security-severity 9.3
- @precision medium
- @id cpp/overrunning-write-with-float
- @tags reliability
- security
- external/cwe/cwe-120
- external/cwe/cwe-787
- external/cwe/cwe-805
3. cpp/very-likely-overrunning-write
- @name Likely overrunning write
- @description Buffer write operations that do not control the length
of data written may overflow
- @kind problem
- @problem.severity error
- @security-severity 9.3
- @precision high
- @id cpp/very-likely-overrunning-write
- @tags reliability
- security
- external/cwe/cwe-120
- external/cwe/cwe-787
- external/cwe/cwe-805
- CWEs:
- https://cwe.mitre.org/data/definitions/120.html
- https://cwe.mitre.org/data/definitions/787.html
- https://cwe.mitre.org/data/definitions/805.html
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
The previous commits fixed issues with these queries across various
packages. Now that those are resolved, enable the queries in the
edk2 query set so regressions can be found in the future.
Enables:
1. cpp/conditionallyuninitializedvariable
- CWE: https://cwe.mitre.org/data/definitions/457.html
- @name Conditionally uninitialized variable
- @description An initialization function is used to initialize a
local variable, but the returned status code is
not checked. The variable may be left in an
uninitialized state, and reading the variable may
result in undefined behavior.
- @kind problem
- @problem.severity warning
- @security-severity 7.8
- @id cpp/conditionally-uninitialized-variable
- @tags security
- external/cwe/cwe-457
2. cpp/pointer-overflow-check
- CWE: https://cwe.mitre.org/data/definitions/758.html
- @name Pointer overflow check
- @description Adding a value to a pointer to check if it
overflows relies on undefined behavior and
may lead to memory corruption.
- @kind problem
- @problem.severity error
- @security-severity 2.1
- @precision high
- @id cpp/pointer-overflow-check
- @tags reliability
- security
- external/cwe/cwe-758
3. cpp/potential-buffer-overflow
- CWE: https://cwe.mitre.org/data/definitions/676.html
- @name Potential buffer overflow
- @description Using a library function that does not check
buffer bounds requires the surrounding program
to be very carefully written to avoid buffer
overflows.
- @kind problem
- @id cpp/potential-buffer-overflow
- @problem.severity warning
- @security-severity 10.0
- @tags reliability
- security
- external/cwe/cwe-676
- @deprecated This query is deprecated, use
Potentially overrunning write
(`cpp/overrunning-write`) and
Potentially overrunning write with float to string
conversion
(`cpp/overrunning-write-with-float`) instead.
Note that cpp/potential-buffer-overflow is deprecated. This query
will be updated to the succeeding queries in the next commit. The
query is used in this commit to show that we considered and tested
the query in history.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Fixes CodeQL alerts for CWE-457:
https://cwe.mitre.org/data/definitions/457.html
Note that this change affects the actual return value from the
following functions. The functions documented that if an integer
overflow occurred, MAX_UINTN would be returned. They were
implemented to actually return an undefined value from the stack.
This change makes the function follow its description. However, this
is technically different than what callers may have previously
expected.
MdePkg/Library/BaseLib/String.c:
- StrDecimalToUintn()
- StrDecimalToUint64()
- StrHexToUintn()
- StrHexToUint64()
- AsciiStrDecimalToUintn()
- AsciiStrDecimalToUint64()
- AsciiStrHexToUintn()
- AsciiStrHexToUint64()
Cc: Erich McMillan <emcmillan@microsoft.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Co-authored-by: Erich McMillan <emcmillan@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
While more portable methods exist to handle these cases, this change
does not attempt to do more than fix the immediate problem and
follow the conventions already established in this code.
`snprintf()` is introduced as the minimum improvement apart from
making the buffers larger.
Fixes the following CodeQL alerts:
1. Failure on line 2339 in
BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c
- Type: Potentially overrunning write
- Severity: Critical
- Problem: This 'call to sprintf' operation requires 17 bytes but
the destination is only 16 bytes.
2. Failure on line 2341 in
BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c
- Type: Potentially overrunning write
- Severity: Critical
- Problem: This 'call to sprintf' operation requires 17 bytes but
the destination is only 16 bytes.
3. Failure on line 1309 in
BaseTools/Source/C/VfrCompile/Pccts/antlr/main.c
- Type: Potentially overrunning write
- Severity: Critical
- Problem: This 'call to sprintf' operation requires 25 bytes but
the destination is only 20 bytes.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Purdue Compiler Construction Tool Set (PCCTS) source code was copied/
pasted into BaseTools/Source/C/VfrCompile/Pccts/.
The code contains tab characters instead of spaces.
PatchCheck.py gives an error on modifications to files that
contain tabs.
The goal of my upcoming change there is not to mix tabs and spaces
but to fix a bug while preserving its current formatting characters.
This change adds that directory to the pre-existing list of
directories in which tab checks are ignored in PatchCheck.py
and also updates the check for makefiles to check for *.makefile:
this allows {header,footer,app,lib}.makefile in
BaseTools/Source/C/Makefiles to be detected and avoid having
PatchCheck.py complain about tab characters.
The check for "Makefile" is updated to be case-insensitive since
there are some Makefiles named 'makefile' instead of 'Makefile'.
Co-authored-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Drop MtrrLibIsPowerOfTwo function, use the new IS_POW2() macro instead.
The ASSERT() removed (inside MtrrLibIsPowerOfTwo) is superfluous,
another ASSERT() a few lines up in MtrrLibCalculateMtrrs() already
guarantees that Length can not be zero at this point.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
ALIGNOF: Determining the alignment requirement of data types is
crucial to ensure safe memory accesses when parsing untrusted data.
IS_POW2: Determining whether a value is a power of two is important
to verify whether untrusted values are valid alignment values.
IS_ALIGNED: In combination with ALIGNOF data offsets can be verified.
A more general version of the IS_ALIGNED macro previously defined by
several modules.
ADDRESS_IS_ALIGNED: Variant of IS_ALIGNED for pointers and addresses.
Replaces module-specific definitions throughout the code base.
ALIGN_VALUE_ADDEND: The addend to align up can be used to directly
determine the required offset for data alignment.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
This patch is a preparation for the patches that follow. The
subsequent patches will introduce and integrate new alignment-related
macros, which collide with existing definitions in OvmfPkg.
Temporarily rename them to avoid build failure, till they can be
substituted with the new, shared definitions.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
This patch is a preparation for the patches that follow. The
subsequent patches will introduce and integrate new alignment-related
macros, which collide with existing definitions in MdeModulePkg.
Temporarily rename them to avoid build failure, till they can be
substituted with the new, shared definitions.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4353
Due to AMD erratum #1467, an SEV-SNP VMSA should not be 2MB aligned. To
work around this issue, allocate two pages instead of one. Because of the
way that page allocation is implemented, always try to use the second
page. If the second page is not 2MB aligned, free the first page and use
the second page. If the second page is 2MB aligned, free the second page
and use the first page. Freeing in this way reduces holes in the memory
map.
Fixes: 06544455d0 ("UefiCpuPkg/MpInitLib: Use SEV-SNP AP Creation ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ray Ni <ray.ni@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=4353
When parking the APs on exiting from UEFI, a new page allocation is made.
This allocation, however, does not end up being marked reserved in the
memory map supplied to the OS. To avoid this, re-use the VMSA by clearing
the VMSA RMP flag, updating the page contents and re-setting the VMSA RMP
flag.
Fixes: 06544455d0 ("UefiCpuPkg/MpInitLib: Use SEV-SNP AP Creation ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ray Ni <ray.ni@intel.com>
BufferPages is UINTN, so we need "%Lu" when printing it to avoid
it being truncated. Also cast to UINT64 to make sure it works
for 32bit builds too.
Fixes: 4f441d024b ("UefiCpuPkg/PiSmmCpuDxeSmm: fix error handling")
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
TME (Total Memory Encryption) is the capability to encrypt
the entirety of physical memory of a system.
TME-MK (Total Memory Encryption-Multi-Key) builds on TME and adds
support for multiple encryption keys.
The patch adds some necessary CPUID/MSR definitions for TME-MK.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4011
Currently AHCI driver will try to retry all failed packets
regardless of the failure cause. This is a problem in password
unlock flow where number of password retries is tracked by the
device. If user passes a wrong password Ahci driver will try
to send the wrong password multiple times which will exhaust
number of password retries and force the user to restart the
machine. This commit introduces a logic to check for the cause
of packet failure and only retry packets which failed due to
transient conditions on the link. With this patch only packets for
which CRC error is flagged are retried.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hunter Chang <hunter.chang@intel.com>
Cc: Baraneedharan Anbazhagan <anbazhagan@hp.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Baraneedharan Anbazhagan <anbazhagan@hp.com>
Add bounds checks of PcdRtcDefaultYear to guarantee that the year
is always between PcdMinimalValidYear and PcdMaximalValidYear.
This is required to make the following commit a backwards compatible
change and guarantee and invalid year is never set.
d55d73152e
This is required because use of an expression in the DEC file
PCD default value is only used to determine the DEC default values.
If an INF/DSC overrides PcdRtcDefaultYear, then the DEC expression
for PcdMinimalValidYear is not applied again.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This library follows Redfish Host Interface specification and use IPMI
command to get bootstrap account credential(NetFn 2Ch, Command 02h)
from BMC. RedfishHostInterfaceDxe will use this credential for the
following communication between BIOS and BMC.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
The IdMap.S asm source file has not executable content, but its lack of
a BTI annotation prevents the linker from marking any executables it
emits as BTI compatible if this object is part of the build. So add the
BTI note by hand.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The object file containing the vector table does not contain any
callable functions, so it will not be implicitly annotated as BTI
compatible on BTI builds. So add the annotation by hand, and use the
'empty' type so we get the GNU ELF note but not the actual BTI opcode.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
The ELF based toolchains use objcopy to create HII object files, which
contain only a single .hii section. This means no GNU note is inserted
that describes the object as compatible with BTI, even though the lack
of executable code in such an object makes the distinction irrelevant.
However, the linker will not add the note globally to the resulting ELF
executable, and this breaks BTI compatibility.
So let's insert a GNU BTI-compatible ELF note by hand when generating
such object files.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
The GccLto helper library does not contain any code, as its only purpose
is to pull in other libraries that implement intrinsics to which the
linker's codegen pass may emit calls.
So mark it as BTI compatible, so that the linker does not complain about
unannotated objects.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
When building with -mbranch-protection=bti, which affects the compiler
codegen only, ensure that the assembler based codegen is aligned with
this, by emitting the BTI C opcode at the start of each exported
function. While most exported functions are not in fact ever called
indirectly, whether or not this is the case is a property of the caller
so annotating every exported function is a reasonable default.
While at it, fix two occurrences in ArmPkg of exported functions that
did not use the ASM_FUNC() macro.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Currently, the AArch64 implementation of LongJump() avoids using the RET
instruction to perform the jump, even though the target address is held
in the link register X30, as the nature of a long jump implies that the
ordinary return address prediction machinery will not be able to make a
correct prediction.
However, LongJump() is rarely used, and the return stack will be out of
sync in any case, so this optimization has little value in practice, and
given that indirect calls other than function returns require a BTI
landing pad at the call site, this optimization is not compatible with
BTI. So let's just use RET instead.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Implement a CPP macro that can be called from .S files to emit the .note
section carrying the annotation that informs the linker that the object
file is compatible with BTI control flow integrity checks.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
The Rtc library for the kvmtool guest firmware configures the
RTC controller address range as runtime memory by calling the
gDS->SetMemorySpaceAttributes().
The SetMemorySpaceAttributes() function has a dependency on
the CPU Arch Protocol. If the CPU Arch Protocol is not
installed the call to set the memory attributes fails with
error code EFI_NOT_AVAILABLE_YET.
Therefore, set the library dependency on the CPU Arch protocol.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
When scanning for the Serial Port in the device
tree, the length and value parameters to ScanMem8()
are not in the right order. This results in the
serial port not being detected if the chosen node
in the device tree has additional elements.
Therefore, pass the parameters to ScanMem8() in the
correct order to fix this issue.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
When scanning for the Serial Port in the device
tree, the length and value parameters to ScanMem8()
are not in the right order. This results in the
serial port not being detected if the chosen node
in the device tree has additional elements.
Therefore, pass the parameters to ScanMem8() in the
correct order to fix this issue.
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reduce the log output from Configuration Manager Object Parser
in TableHelperLib by enabling the logs only if DEBUG_INFO is
enabled.
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The CLANGDWARF toolchain has the same problem as XCODE5 linking
CpuExceptionHandlerLib. So, use the
Xcode5SecPeiCpuExceptionHandlerLib.inf when building with the CLANGDWARF
toolchain.
Since the difference is that the non-Xcode5 version uses `mov` while the
Xcode5 version uses `lea`, they can be merged in future with the single
version using `lea`.
[ardb: the main difference is that the 'mov' instructions result in
absolute symbol references, which are necessary because the code
in question is copied in memory independently from the code that
carries the symbols it refers to. The Xcode5 version has
additional runtime handling to fix up the copied code with the
correct absolute references.]
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Bug fix:
- function stack fault
- properly handle "SubnetAddrInfoIPv6" when there is no IPv6 support
- copy-n-paste error in RedfishGetHostInterfaceProtocolData()
- fix typo
Enhancement:
- Redfish discover driver now can configure host IP address based on
the information from SMBIOS type 42 record. This saves the effort of
configuring host IP address in setup menu.
- Performance improvement to driver binding process. Redfish discover
driver will wait until all required drivers are ready and do driver
binding start().
- Use CopyGuid() to copy GUID instead of intrinsic function.
- Error handling when SMBIOS data is corrupted.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
commit f13264b34 introduces a bug for CloudHv as OvmfPkg/OvmfPkg.dec is
missing in CloudHvHasAcpiDtDxe.inf which leads to
gUefiOvmfPkgTokenSpaceGuid found nowhere when build.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
The BIOS Firmware Version in the SMBIOS Type 0 can be fetched from
the fixed PcdFirmwareVersionString or platform specific OemMiscLib.
In fact, the support from OemMiscLib comes into play when the firmware
version may be modified at boot time for extended information.
Therefore, the priority of getting the version from OemMiscLib should
be higher.
In case there is no modification in the OemMiscLib, we have to keep
HII string STR_MISC_BIOS_VERSION empty or 'Not Specified'
to indicate that the firmware version should be fetched from
the PcdFirmwareVersionString.
Signed-off-by: Tinh Nguyen <tinhnguyen@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
With the new mmconfig location at 0xe0000000 above the 32-bit PCI MMIO
window we don't have to special-case the mmconfig xbar any more. We'll
just add a mtrr uncachable entry starting at MMIO window base and ending
at 4GB.
Update comments to match reality.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Also swap the ordering of 32bit PCI MMIO window on q35, i.e. use the
room between end of low memory and the start of the mmconfig bar.
With a typical configuration on modern qemu with gigabyte-aligned memory
the MMIO window start at 0x8000000, sized 1532 MB. In case there is
memory present above 0x80000000 the window will start at 0xc0000000
instead, with 512 MB size.
This depends on qemu commit 4a4418369d6d ("q35: fix mmconfig and
PCI0._CRS"), so it raises the bar for the lowest supported version
to qemu 4.1 (released Aug 2019).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Move the commment up so it is placed just before the address space
calculations start. Also add q35 memory layout.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
M-mode firmware ranges should not be used by EDK2/OS.
Currently, we search for mmode_resv0 node in FDT and mark it as the
reserved memory in EFI memory map. However, if there are multiple
M-mode firmware ranges, then this will miss those extra ranges
allowing the OS to access the memory and hit a fault.
This issue is exposed since recent opensbi started creating
two ranges for text and data.
Fix this by searching for all reserved memory nodes and marking
them as reserved in the EFI memory map.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reduce the number of random tests. In previous patch, non-1:1
mapping is enbaled and it may need more than an hour and a half
for the CI test, which may lead to CI timeout. Reduce the number
of random test count to pass the CI.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Modify CpuPageTableLib code to enable PAE paging.
In PageTableMap() API:
When creating new PAE page table, after creating page table,
set all MustBeZero fields of 4 PDPTE to 0. The MustBeZero
fields are treated as RW and other attributes by the common
map logic. So they might be set to 1.
When updating exsiting PAE page table, the special steps are:
1.Prepare 4K-aligned 32bytes memory in stack for 4 temp PDPTE.
2.Copy original 4 PDPTE to the 4 temp PDPTE and set the RW,
UserSupervisor to 1 and set Nx of 4 temp PDPTE to 0.
4.After updating the page table, set the MustBeZero fields of
4 temp PDPTE to 0.
5.Copy the temp PDPTE to original PDPTE.
In PageTableParse() API, also create 4 temp PDPTE in stack.
Copy original 4 PDPTE to the 4 temp PDPTE. Then set the RW,
UserSupervisor to 1 and set Nx of 4 temp PDPTE to 0. Finally
use the address of temp PDPTE as the page table address.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Combine 'if' condition branch for non-present and leaf Parent
Entry in PageTableLibMapInLevel. Most steps of these two condition
are the same. This commit doesn't change any functionality.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add code to compare ParentPagingEntry Attribute&Mask and input
Attribute&Mask to decide if new next level page table is needed
in non-present ParentPagingEntry condition. This can help avoid
unneccessary page table creation.
For example, there is a page table in which [0, 1G] is mapped(Lv4[0]
,Lv3[0,0], a non-leaf level4 entry and a leaf level3 entry).And we
only want to map [1G, 1G+2M] linear address still as non-present.
The expected behaviour should be nothing happens in the process.
However, previous code logic doesn't check if ParentPagingEntry
Attribute&Mask and input Attribute&Mask are the same in non-present
ParentPagingEntry condition. Then a new 4K memory is allocated for
Lv2 since 1G+2M is not 1G-aligned.
So when ParentPagingEntry is non-present, before allocate 4K memory
for next level paging, we also check if ParentPagingEntry Attribute&
Mask and input Attribute&Mask are the same.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The definition of IA32_MAP_ATTRIBUTE has 64 bits, and one of the bit
field PageTableBaseAddress is from bit 12 to bit 52. This means if the
compiler treats the 64bits value as two UINT32 value, the field
PageTableBaseAddress spans two UINT32 value. That's why when building in
NOOPT mode in IA32, the below issue is noticed:
unresolved external symbol __allshl
This patch fix the build failure by seperate field PageTableBaseAddress
into two fields, make sure no field spans two UINT32 value.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Add OUTPUT IsModified parameter in PageTableMap() to indicate
if page table has been modified. With this parameter, caller
can know if need to call FlushTlb when the page table is in CR3.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Enable non-1:1 mapping in random test. In previous test, non-1:1
test will fail due to the non-1:1 mapping issue in CpuPageTableLib
and invalid Input Mask when creating new page table or mapping
not-present range. Now these issue have been fixed.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Modify RandomTest to check invalid input. When creating new page
table or updating exsiting page table:
1.If set [LinearAddress, LinearAddress+Length] to non-present, all
other attributes should not be provided.
2.If [LinearAddress, LinearAddress+Length] contain non-present range,
the Returnstatus of PageTableMap() should be InvalidParameter when:
2.1Some of attributes are not provided when mapping non-present range
to present.
2.2Set any other attribute without setting the non-present range to
Present.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Add an input parameter to control the probability of returning
true. Change RandomBoolean() in RandomTest from 50% chance
returning true to returning true with the percentage of input
Probability.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add manual test case to check input Mask and Attribute. The check
steps are:
1.Create Page table to cover [0, 2G]. All fields of MapMask should
be set.
2.Update Page table to set [2G - 8K,2G] from present to non-present.
All fields of MapMask except present should not be set.
3.Still set [2G - 8K, 2G] as not present, this case is permitted.
But set [2G - 8K, 2G] as RW is not permitted.
4.Update Page table to set [2G - 8K, 2G] as present and RW. All
fields of MapMask should be set.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
For different usage, check if the combination for Mask and
Attr is valid when creating or updating page table.
1.For non-present range
1.1Mask.Present is 0 but some other attributes is provided.
This case is invalid.
1.2Mask.Present is 1 and Attr.Present is 0. In this case,all
other attributes should not be provided.
1.3Mask.Present is 1 and Attr.Present is 1. In this case,all
attributes should be provided to intialize the attribute.
2.For present range
2.1Mask.Present is 1 and Attr.Present is 0.In this case, all
other attributes should not be provided.
All other usage for present range is permitted.
In the mentioned cases, 1.2 and 2.1 can be merged into 1 check.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
When splitting leaf parent entry to smaller granularity, create
child page table before modifing parent entry. In previous code
logic, when splitting a leaf parent entry, parent entry will
point to a null 4k memory before child page table is created in
this 4k memory. When the page table to be modified is the page
table in CR3, if the executed CpuPageTableLib code is in the
range mapped by the modified leaf parent entry, then issue will
happen.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Clear PageSize bit(Bit7) for non-leaf entry in PageTableLibSetPnle.
This function is used to set non-leaf entry attributes so it should
make sure that the PageSize bit of the entry should be 0.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
In previous code logic, when splitting a leaf parent entry to
smaller granularity child page table, if the parent entry
Attribute&Mask(without PageTableBaseAddress field) is equal to the
input attribute&mask(without PageTableBaseAddress field), the split
process won't happen. This may lead to failure in non-1:1 mapping.
For example, there is a page table in which [0, 1G] is mapped(Lv4[0]
,Lv3[0,0], a non-leaf level4 entry and a leaf level3 entry). And we
want to remap [0, 2M] linear address range to [1G, 1G + 2M] with the
same attibute. The expected behaviour should be: split Lv3[0,0]
entry into 512 level2 entries and remap the first level2 entry to
cover [0, 2M]. But the split won't happen in previous code since
PageTableBaseAddress of input Attribute is not checked.
So, when checking if a leaf parent entry needs to be splitted, we
should also check if PageTableBaseAddress calculated by parent entry
is equal to the value caculated by input attribute.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Remove unneeded 'if' condition in CpuPageTableLib code.
The deleted code is in the code branch for present non-leaf parent
entry. So the 'if' check for (ParentPagingEntry->Pnle.Bits.Present
== 0) is always FALSE.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add PcdRtcDefaultYear to specify the default year to use when
the RTC is in an invalid state. Make sure PcdRtcDefaultYear is
>= PcdMinimalValidYear and <= PcdMaximalValidYear. Set the
default value for this PCD to PcdMinimalValidYear to preserve
the existing behavior. A platform DSC file can override this
default value setting.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Itanium support has been removed from EDK2 around 2019.
ITANIUM_HANDOFF_STATUS data structure looks to be
some leftover from that process.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1560
GitHub: 4e1daa60f5
There is also positive side effect of this data structure removal.
Due to HOB allocation type used in PEI stage there is a limit
how much data about virtual CPU can be hold. This limit result
in only 1024 vCPU can be used by VM.
With Itanium related data structure removed more allocated space
can be used for vCPU data and with current allocation limit
will change from 1024 to around 8k vCPUs.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Paweł Poławski <ppolawsk@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Replace the duplicate __PcdSet prototype in PcdValueCommon.h
with the prototype for __PcdGet.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Move the documentation blocks from between the parameter list and function
body to above the function.
Convert all the documentation blocks to Doxygen format.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Time to leave behind relics from the last century and arrive in the
modern world. Drop PC-ANSI Terminal Type for the serial console, use
UTF-8 instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ASSERT() is not proper handling of allocation failures, it gets compiled
out on RELEASE builds. Print a message and enter dead loop instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Call gRT->GetVariable() directly to read the SecureBoot variable. It is
one byte in size so we can easily place it on the stack instead of
having GetEfiGlobalVariable2() allocate it for us, which avoids a few
possible error cases.
Skip secure boot checks if (and only if):
(a) the SecureBoot variable is not present (EFI_NOT_FOUND) according to
the return value, or
(b) the SecureBoot variable was read successfully and is set to
SECURE_BOOT_MODE_DISABLE.
Previously the code skipped the secure boot checks on *any*
gRT->GetVariable() error (GetEfiGlobalVariable2 sets the variable
value to NULL in that case) and also on memory allocation failures.
Fixes: CVE-2019-14560
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2167
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Suggested-by: Marvin Häuser <mhaeuser@posteo.de>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdePkg.
Visual Studio versions before VS 2015 don't support __func__ and so
will fail to compile. A workaround is to define __func__ as
__FUNCTION__ :
#define __func__ __FUNCTION__
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
With the introduction of the use of _Static_assert, edk2 requires a C11
compatible compiler. Update Include/Base.h to be compliant with C11.
As of C11, the maximum type of an enum is type `int`. Since the UEFI
Specification 2.3.1 Errata C allows either `int` or `unsigned int`, fix
the 32-bit enum check to use a signed int.
Since the UEFI 2.3 Specification only allowed signed int, update the
comment to reference 2.3.1 Errata C where the change was made to allow
unsigned int.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The PEI flavor of the ArmMmuLib will install a HOB that exposes its
implementation of the special helper routine that is used to update live
entries, so that other instantiations of ArmMmuLib can invoke it. This
is needed to ensure that splitting page tables using break-before-make
(BBM) does not unmap the code that is performing the split.
However, the BASE variety of ArmMmuLib discovers the HOB and sets a
global pointer to refer to it, which is not possible in PEIMs, and so
all PEIMs must use the PEI variety of this library if one does.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
To prepare for the enablement of booting EFI with the SCTLR.WXN control
enabled, which makes all writeable memory regions non-executable by
default, introduce a memory type that we will use to describe the flash
region that carries the SEC and PEIM modules that execute in place. Even
if these are implicitly read-only due to the ROM nature, they need to be
mapped with read-only attributes in the page tables to be able to
execute from them.
Also add the XP counterpart which will be used for all normal DRAM right
at the outset.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Non-secure memory is a distinction that only matters when executing code
in the secure world that reasons about the secure vs non-secure address
spaces. EDK2 was not designed for that, and the AArch64 version of the
MMU handling library already treats them as identical, so let's just
drop the ARM memory region types that mark memory as 'non-secure'
explicitly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Expose the protocol introduced in v2.10 that permits the caller to
manage mapping permissions in the page tables.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
In preparation for introducing an implementation of the EFI memory
attributes protocol that is shared between ARM and AArch64, unify the
existing code that converts a page table descriptor into a
EFI_MEMORY_xx bitfield, so it can be called from the generic code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Currently, the ARM MMU page table logic will break down any block entry
that overlaps with the region being mapped, even if the block entry in
question is using the same attributes as the new region.
This means that creating a non-executable mapping inside a region that
is already mapped non-executable at a coarser granularity may trigger a
call to AllocatePages (), which may recurse back into the page table
code to update the attributes on the newly allocated page tables.
Let's avoid this, by preserving the block entry if it already covers the
region being mapped with the correct attributes.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Enable the stack guard in ArmVirtPkg builds, so that stack overflows are
caught as they occur, rather than when they happen to hit a read-only
memory region.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Implement support for read-protected memory by wiring it up to the
access flag in the page table descriptor. The resulting mapping is
implicitly non-writable and non-executable as well, but this is good
enough for implementing this attribute, as we never rely on write or
execute permissions without read permissions.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Currently, the MMU code that is supposed to clear the RO or XP
attributes from a region just clears both unconditionally. This
approximates the desired behavior to some extent, but it does mean that
setting the RO bit first on a code region, and then clearing the XP bit
results both RO and XP being cleared, and we end up with writable code,
and avoiding that is the point of all these protections.
Once we introduce RP support, this will only get worse, so let's fix
this up, by reshuffling the attribute update code to take the entry mask
from the caller, and use the mask to preserve other attributes when
clearing RO or XP.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Split the ARM permission fields in the short descriptors into an access
flag and AP[2:1] as per the recommendation in the ARM ARM. This makes
the access flag available separately, which allows us to implement
EFI_MEMORY_RP memory analogous to how it will be implemented for
AArch64.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The section-to-page attribute conversion takes the shareability and
execute-never attributes into account, whereas the page-to-section
counterpart does not. The result is that GetMemoryRegionPage () -which
takes a section attribute argument (via *RegionAttributes) that is
ostensibly based on the first page in the range, but differs from the
actual page attributes when converted back- may return with a
RegionLength of zero. This is incorrect, and confuses code that scans a
region by calling GetMemoryRegion () in sequence.
So fix the conversion, and ASSERT () on a non-zero region length.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
With large page support out of the picture, we can treat bits 1 and 0 of
the page descriptor as individual valid and XN bits, instead of treating
XN as a page type. Doing so aligns the handling of the attribute with
the section descriptor layout, as well as the XN handling on AArch64,
and this is beneficial for maintainability.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Large page support on 32-bit ARM is essentially a glorified contiguous
bit where 16 consecutive entries describing a contiguous range with the
same attributes are presented in a way that permits the TLB to cache its
translation with a single entry.
This was never wired up completely, and does not add a lot of value in
EFI, where the page granularity is 4k and we expect to be able to set RO
and XP permissions on individual pages.
Given that large page support complicates the handling of the XN bit at
the page level (which is in a different place depending on whether the
page is small or large), let's just rip it out.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
When the range instruction cache invalidating not supported, the whole
instruction cache should be invalidated instead.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2850
Add "-Y REPORT_INFO" option to build command to generate compile
information as part of BuildReport.
This option generates files to be used by external tools as IDE's
to enhance functionality.
Files are created inside build folder:
<Build>/<BuildTarget>/<ToolChain>/CompileInfo
Files created:
* compile_commands.json - Compilation Database. To be used by IDE's
to enable advance features
* cscope.files - List of files used in compilation. Used by Cscope to parse
C code and provide browse functionality.
* module_report.json - Module data form buildReport in Json format.
Signed-off-by: Guillermo Antonio Palomino Sosa <guillermo.a.palomino.sosa@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The Section 6.1.3, SMBIOS specification version 3.6.0 describes the
handling of test strings in SMBIOS tables.
Text strings are added at the end of the formatted portion of the SMBIOS
structure and are referenced by index in the SMBIOS structure.
Therefore, introduce a SmbiosStringTableLib to simplify the publishing
of the string set.
SmbiosStringTableLib introduces a concept of string table which records
the references to the SMBIOS strings as they are added and returns an
string reference which is then assigned to the string field in the
formatted portion of the SMBIOS structure. Once all strings are added,
the library provides an interface to get the required size for the string
set. This allows sufficient memory to be allocated for the SMBIOS table.
The library also provides an interface to publish the string set in
accordance with the SMBIOS specification.
Example:
EFI_STATUS
BuildSmbiosType17Table () {
STRING_TABLE StrTable;
UINT8 DevLocatorRef;
UINT8 BankLocatorRef;
SMBIOS_TABLE_TYPE17 *SmbiosRecord;
CHAR8 *StringSet;
...
// Initialize string table for 7 strings
StringTableInitialize (&StrTable, 7);
StringTableAddString (&StrTable, "SIMM 3", &DevLocatorRef);
StringTableAddString (&StrTable, "Bank 0", &BankLocatorRef);
...
SmbiosRecord = AllocateZeroPool (
sizeof (SMBIOS_TABLE_TYPE17) +
StringTableGetStringSetSize (&StrTable)
);
...
SmbiosRecord->DeviceLocator = DevLocatorRef;
SmbiosRecord->BankLocator = BankLocatorRef;
...
// get the string set area
StringSet = (CHAR8*)(SmbiosRecord + 1);
// publish the string set
StringTablePublishStringSet (
&StrTable,
StringSet,
StringTableGetStringSetSize (&StrTable)
);
// free string table
StringTableFree (&StrTable);
return EFI_SUCCESS;
}
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Girish Mahadevan <gmahadevan@nvidia.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Cc: William Watson <wwatson@nvidia.com>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Because UefiCpuPkg/UefiCpuLib is merged to MdePkg/CpuLib, remove the
dependency of UefiCpuLib.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yu Pu <yu.pu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
There are two libraries: MdePkg/CpuLib and UefiCpuPkg/UefiCpuLib and
UefiCpuPkg/UefiCpuLib will be merged to MdePkg/CpuLib. To avoid build
failure, add CpuLib dependency to all modules that depend on UefiCpuLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4360
An incorrect format specifier is being used in a DEBUG print,
specifically, a variable of type EFI_STATUS was being printed with
the %a format specifier (pointer to an ASCII string), thus the value of
the Status variable was being treated as the address of a string,
leading to a CPU exception, when encountered this bug manifests itself
as a hang near "Ready to Boot Event", with the last DEBUG print being
"INFO: Got MicrocodePatchHob with microcode patches starting address"
followed by a CPU Exception dump.
Signed-off-by: Darbin Reyes <darbin.reyes@intel.com>
Reviewed-by: Jacob Narey <jacob.narey@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
In case PcdFirmwareReleaseDateString is not set use a valid date
as fallback. Using "unknown" makes Windows unhappy.
Fixes: 4cb94f20b0 ("OvmfPkg/SmbiosPlatformDxe: use PcdFirmware*")
Reported-by: ruifeng.gao@intel.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RegisterCpuInterruptHandler did not allow setting
exception handlers for anything beyond the timer IRQ.
Beyond that, it didn't meet the spec around handling
of inputs.
RiscVSupervisorModeTrapHandler now will invoke
set handlers for both exceptions and interrupts.
Two arrays of handlers are maintained - one for exceptions
and one for interrupts.
For unhandled traps, RiscVSupervisorModeTrapHandler dumps
state using the now implemented DumpCpuContext.
For EFI_SYSTEM_CONTEXT_RISCV64, extend this with the trapped
PC address (SEPC), just like on AArch64 (ELR). This is
necessary for X86EmulatorPkg to work as it allows a trap
handler to return execution to a different place. Add
SSTATUS/STVAL as well, at least for debugging purposes. There
is no value in hiding this.
Fix nested exception handling. Handler code should not
be saving SIE (the value is saved in SSTATUS.SPIE) or
directly restored (that's done by SRET). Save and
restore the entire SSTATUS and STVAL, too.
Cc: Daniel Schaefer <git@danielschaefer.me>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
The TimerDxe implementation doesn't account for the physical
time passed due to timer handler execution or (perhaps even
more importantly) time spent with interrupts masked.
Other implementations (e.g. like the Arm one) do. If the
timer tick is always incremented at a fixed rate, then
you can slow down UEFI's perception of time by running
long sections of code in a critical section.
Cc: Daniel Schaefer <git@danielschaefer.me>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
On Arm platforms, the number of available RNG algorithms is
dynamically detected and can be 0 in the absence of FEAT_RNG
and firmware TRNG.
In this case, the EFI_RNG_PROTOCOL should not be installed to
prevent from installing an empty protocol.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
[ardb: return EFI_REQUEST_UNLOAD_IMAGE instead of an error]
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
mAvailableAlgoArrayCount holds the count of available RNG algorithms.
In a following patch, its value will be used to prevent the
EFI_RNG_PROTOCOL to be installed if no RNG algorithm is available.
Correctly set/reset the value for all implementations.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In openssl 3.0 SHA512() goes through the provider logic,
requiring a huge amount of openssl code. The individual
functions do not, so use them instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In openssl 3.0 SHA384() goes through the provider logic,
requiring a huge amount of openssl code. The individual
functions do not, so use them instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In openssl 3.0 SHA256() goes through the provider logic,
requiring a huge amount of openssl code. The individual
functions do not, so use them instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In openssl 3.0 SHA1() goes through the provider logic,
requiring a huge amount of openssl code. The individual
functions do not, so use them instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Add the 'AsmRelocateApLoopStartGeneric' for X64 processors except 64-bit
AMD processors with SEV-ES.
Remove the unused arguments of AsmRelocateApLoopStartGeneric, updated
the stack offset.
Create PageTable for the allocated reserved memory.
Only keep 4GB limitation of memory allocation for the case APs still
need to be transferred to 32-bit mode before OS.
Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Improve the formatting of DEBUG messages in UsbBusDxe by adding
a hyphen to separate the EFI_STATUS code.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337
Existing SMBASE Relocation is in the PiSmmCpuDxeSmm driver, which
will relocate the SMBASE of each processor by setting the SMBASE
field in the saved state map (at offset 7EF8h) to a new value.
The RSM instruction reloads the internal SMBASE register with the
value in SMBASE field when each time it exits SMM. All subsequent
SMI requests will use the new SMBASE to find the starting address
for the SMI handler (at SMBASE + 8000h).
Due to the default SMBASE for all x86 processors is 0x30000, the
APs' 1st SMI for rebase has to be executed one by one to avoid
the processors over-writing each other's SMM Save State Area (see
existing SmmRelocateBases() function), which means the next AP has
to wait for the previous AP to finish its 1st SMI, then it can call
into its 1st SMI for rebase via Smi Ipi command, thus leading the
existing SMBASE Relocation has to be running in series. Besides, it
needs very complex code to handle the AP exit semaphore
(mRebased[Index]), which will hook return address of SMM Save State
so that semaphore code can be executed immediately after AP exits
SMM for SMBASE relocation (see existing SemaphoreHook() function).
With SMM Base Hob support, PiSmmCpuDxeSmm does not need the RSM
instruction to do the SMBASE Relocation. SMBASE Register for each
processors have already been programmed and all SMBASE address have
recorded in SMM Base Hob. So the same default SMBASE Address
(0x30000) will not be used, thus the processors over-writing each
other's SMM Save State Area will not happen in PiSmmCpuDxeSmm driver.
This way makes the first SMI init can be executed in parallel and
save boot time on multi-core system. Besides, Semaphore Hook code
logic is also not required, which will greatly simplify the SMBASE
Relocation flow.
Mainly changes as below:
* Assume the biggest possibility of tile size is 8k.
* Combine 2 SMIs (gcSmmInitTemplate & gcSmiHandlerTemplate) into one
(gcSmiHandlerTemplate), the new SMI handler needs to run to 2 paths:
one to SmmCpuFeaturesInitializeProcessor(), the other to SMM Core
Entry Point.
* Issue SMI IPI (All Excluding Self SMM IPI + BSP SMM IPI) for first
SMI init before normal SMI sources happen.
* Call SmmCpuFeaturesInitializeProcessor() in parallel.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337
The default SMBASE for the x86 processor is 0x30000. When
SMI happens, processor runs the SMI handler at SMBASE+0x8000.
Also, the SMM save state area is within SMBASE+0x10000.
One of the SMM initialization from processor perspective is to
relocate and program the new SMBASE (in TSEG range) for each
processor. When the SMBASE relocation happens in a PEI module,
the PEI module shall produce the SMM_BASE_HOB in HOB database
which tells the PiSmmCpuDxeSmm driver (runs at a later phase)
about the new SMBASE for each processor. PiSmmCpuDxeSmm driver
installs the SMI handler at the SMM_BASE_HOB.SmBase[Index]+0x8000
for processor Index. When the HOB doesn't exist, PiSmmCpuDxeSmm
driver shall relocate and program the new SMBASE itself.
This patch adds the SMM Base HOB for any PEI module to do
the SmBase relocation ahead of PiSmmCpuDxeSmm driver and
store the relocated SmBase address in array for each
processor.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@Intel.com>
This patch is to replace mIsBsp by mBspApicId check.
mIsBsp becomes the local variable (IsBsp), then it can be
checked dynamically in the function. Instead, we define the
mBspApicId, which is to record the BSP ApicId used for
compare in SmmInitHandler. With this change, SmmInitHandler
can be run in parallel during SMM init.
Note:
This patch is the per-prepared work by refining the
SmmInitHandler, then, we can do the next step to
combine 2 SMIs (gcSmmInitTemplate & gcSmiHandlerTemplate)
into one (gcSmiHandlerTemplate), the new SMI handler
will call the SmmInitHandler in parallel to do the init.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Introduce RedfishDebugLib to RedfishPkg. This library provides several
debugging functions for Redfish application. Redfish drivers rely on
Rest Ex protocol to communicate with BMC and the communication data
may be big and complicated. Use RedfishDebugLib in RedfishRestExDxe to
simplify debugging process.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
The output of the "ping" command shows the time without a space between
the label and the value. e.g.:
20 bytes from 192.168.0.1 : icmp_seq=1 ttl=1 time1~2ms
Improve the readability and consistency by adding an equals sign for the
time value:
20 bytes from 192.168.0.1 : icmp_seq=1 ttl=1 time=1~2ms
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
2023-03-06 02:41:00 +00:00
1530 changed files with 311017 additions and 68099 deletions
// Maximum number of characters to print to serial (UINT8s) and to console if
// available (as UINT16s)
//
#define MAX_PRINT_CHARS 100
STATICCHAR8*gExceptionTypeString[]={
"Synchronous",
"IRQ",
@@ -188,18 +194,14 @@ DefaultExceptionHandler (
INOUTEFI_SYSTEM_CONTEXTSystemContext
)
{
CHAR8Buffer[100];
CHAR8Buffer[MAX_PRINT_CHARS];
CHAR16UnicodeBuffer[MAX_PRINT_CHARS];
UINTNCharCount;
INT32Offset;
if(mRecursiveException){
STATICCHAR8CONSTMessage[]="\nRecursive exception occurred while dumping the CPU state\n";
SerialPortWrite((UINT8*)Message,sizeofMessage-1);
if(gST->ConOut!=NULL){
AsciiPrint(Message);
}
CpuDeadLoop();
}
@@ -207,9 +209,10 @@ DefaultExceptionHandler (
CharCount=AsciiSPrint(Buffer,sizeof(Buffer),"\n\n%a Exception at 0x%016lx\n",gExceptionTypeString[ExceptionType],SystemContext.SystemContextAArch64->ELR);
SerialPortWrite((UINT8*)Buffer,CharCount);
if(gST->ConOut!=NULL){
AsciiPrint(Buffer);
}
// Prepare a unicode buffer for ConOut, if applicable, in case the buffer
DEBUG((DEBUG_ERROR,"%a: no PSCI method defined\n",__FUNCTION__));
DEBUG((DEBUG_ERROR,"%a: no PSCI method defined\n",__func__));
ASSERT(FALSE);
}
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
