REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2770
The Trim.py would break the build process when the file not found
issue occures, however sometimes we do not care about this issue.
This patch changes the error with warning in order to solve this
kind of break.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng<bob.c.feng@intel.com>
AutoGen manager/workers halt the progress when an error occurs but
doesn't propagate the error code to main and allows main exit with 0
and gets the build system unable to catch the occurrence of an error.
This change informs main with an error when a progress is halted and
helps main exit with 1.
Signed-off-by: Irene Park <ipark@nvidia.com>
Reviewed-by: Bob Feng<bob.c.feng@intel.com>
In order to avoid boot delays from devices such as network controllers
that may not even be involved in booting at all, drop the call to
EfiBootManagerConnectAll () from the boot path. It will be called by
UiApp, so when going through the menu, all devices will be connected
as usual, but for the default boot, it is really not necessary so
let's get rid of this.
Enumerating all possible boot options and creating Boot#### variables
for them is equally unnecessary in the default case, and also happens
automatically in UiApp, so drop that as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Without ConnectAll() being called on the boot path, the UEFI shell will
be entered with no block devices or anything else connected, and so for
the novice user, this is not a very accommodating environment. Now that
we have made the UiApp the last resort on boot failure, and made the
UEFI Shell accessible directly via the 's' hotkey if you really need
it, let's hide it as an ordinary boot option.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
UEFI boot options may exist but have the LOAD_OPTION_ACTIVE flag
cleared. This means that the boot option should not be selected
by default, but it does not mean it should be omitted from the
boot selection presented by the boot manager: for this purpose,
another flag LOAD_OPTION_HIDDEN exists.
Given that the latter flag exists solely for the purpose of omitting
boot options from the boot selection menu, and LOAD_OPTION_XXX flags
can be combined if desired, hiding inactive boot options as well is
a mistake, and violates the intent of paragraph 3.1.3 of the UEFI
specification (revision 2.8 errata A). Let's fix this by dropping
the LOAD_OPTION_ACTIVE check from the code that populates the boot
selection menu.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
As a last resort, drop into the UiApp application when no active boot
options could be started. Doing so will connect all devices, and so
it will allow the user to enter the Boot Manager submenu and pick a
network or removable disk option.
Note that this only occurs if even the default removable filepath
could not be booted (e.g., \EFI\BOOT\BOOTAA64.EFI on AArch64)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
In preparation of hiding the UEFI Shell boot option as an ordinary
boot option, make sure we can invoke it directly using the 's'
hotkey. Without ConnectAll() having been called, this results in
a shell that may have no block devices or other things connected,
so don't advertise the 's' in the console string that is printed
at boot - for novice users, we will go through the UiApp which
connects everything first. For advanced use, having the ability
to invoke the UEFI shell without any devices connected may be an
advantage, so let's keep this behavior as is for now.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The way the BDS handles the short-form USB device path of the console
keyboard relies on USB host controllers to be locatable via their PCI
metadata, which implies that these controllers already have a PCI I/O
protocol installed on their handle.
This is not the case for non-discoverable USB host controllers that are
supported by the NonDiscoverable PCI device driver. These controllers
must be connected first, or the BDS will never notice their existence,
and will not enable any USB keyboards connected through them.
Let's work around this by connecting these handles explicitly. This is
a bit of a stopgap, but it is the cleanest way of dealing with this
without violating the UEFI driver model entirely. This ensures that
platforms that do not rely on ConnectAll() will keep working as
expected.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Supervisor Call instruction (SVC) is used by the Arm Standalone MM
environment to request services from the privileged software (such as
ARM Trusted Firmware running in EL3) and also return back to the
non-secure caller via EL3. Some Arm CPUs speculatively executes the
instructions after the SVC instruction without crossing the privilege
level (S-EL0). Although the results of this execution are
architecturally discarded, adversary running on the non-secure side can
manipulate the contents of the general purpose registers to leak the
secure work memory through spectre like micro-architectural side channel
attacks. This behavior is demonstrated by the SafeSide project [1] and
[2]. Add barrier instructions after SVC to prevent speculative execution
to mitigate such attacks.
[1]: https://github.com/google/safeside/blob/master/demos/eret_hvc_smc_wrapper.cc
[2]: https://github.com/google/safeside/blob/master/kernel_modules/kmod_eret_hvc_smc/eret_hvc_smc_module.c
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Follow the implementation from Unix host to implement SNP
EMU_IO_THUNK_PROTOCOL and EMU_SNP_PROTOCOL. The network IO driver is the
same one as Nt32. Please refer to NETWORK-IO Subproject for network Io
driver(SnpNt32Io.dll).
Signed-off-by: Nickle Wang <nickle.wang@hpe.com>
Signed-off-by: Derek Lin <derek.lin2@hpe.com>
Acked-by: Ray Ni <ray.ni@intel.com>
PlatformBootManagerLib now asserts at build time that the correct
terminal type is used, and so leaving it unset breaks the ArmPkg
DSC build. So fix that.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
In the ArmPkg version of PlatformBootManagerLib, we construct a
serial device path based on the default settings for baud rate,
parity and the number of stop bits, to ensure that a serial console
is available even on the very first boot.
This assumes that PcdUartDefaultParity or PcdUartDefaultStopBits are
not set to '0', meaning 'the default', as there is no default for
these when constructing a device path.
So add a couple of STATIC_ASSERT()s to make sure that we catch this
condition, since it otherwise ignores the bogus device path silently,
which is rather tedious to debug,.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Replace the runtime ASSERT with the build time STATIC_ASSERT on the
check that ensures that the terminal type we use for the serial
console matches the one we explicitly add to the ConIn/ConOut/StdErr
variables.
This helps catch serial console issues early, even in RELEASE builds,
reducing the risk of ending up with no console at all, which can be
tricky to debug on bare metal.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Gary reports the GCC 10 will emit calls to atomics intrinsics routines
unless -mno-outline-atomics is specified. This means GCC-10 introduces
new intrinsics, and even though it would be possible to work around this
by specifying the command line option, this would require a new GCC10
toolchain profile to be created, which we prefer to avoid.
So instead, add the new intrinsics to our library so they are provided
when necessary.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Gary Lin <glin@suse.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Bret Barkelew <bret.barkelew@microsoft.com>
Signed-off-by: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2721
The ReportOutput() function in UnitTestResultReportLib copies characters
from a function input buffer to an intermediate local buffer in fixed
size chunks of the maximum size of the intermediate buffer. The
implementation currently calls AsciiStrCpyS() which will ASSERT on an
error.
This commit changes the call to AsciiStrnCpyS() to avoid the
ASSERT which is not expected in the usage of the string copy in this
implementation.
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Use the safe string function StrCpyS() in BaseLib to test the
SAFE_STRING_CONSTRAINT_CHECK() macro.
Cc: Andrew Fish <afish@apple.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Bret Barkelew <bret.barkelew@microsoft.com>
Cc: Brian J. Johnson <brian.johnson@hpe.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Marvin Häuser <mhaeuser@outlook.de>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Vincent Zimmer <vincent.zimmer@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Vitaly Cheptsov <vit9696@protonmail.com>
Acked-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054
Runtime checks returned via status return code should not work as
assertions to permit parsing not trusted data with SafeString
interfaces. Replace ASSERT() with a DEBUG_VERBOSE message.
Cc: Andrew Fish <afish@apple.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Bret Barkelew <bret.barkelew@microsoft.com>
Cc: Brian J. Johnson <brian.johnson@hpe.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Marvin Häuser <mhaeuser@outlook.de>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Vincent Zimmer <vincent.zimmer@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2713
In current code, If TCG2_PHYSICAL_PRESENCE_FLAGS_VARIABLE variable
is not exist, code will get default value from two places.
This fix is to make the default value comes from the PCD
gEfiSecurityPkgTokenSpaceGuid.PcdTcg2PhysicalPresenceFlags
Signed-off-by: Maggie Chu <maggie.chu@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Dating back to commits f5cb376703 and ddd34a8183, the
"ArmVirtPkg/ArmVirtQemu.dsc" platform includes the
"OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf" module when the TPM2_ENABLE
build flag is defined.
This was regressed in commit 8923699291, which added a Tpm12DeviceLib
dependency to Tcg2ConfigPei. "ArmVirtQemu.dsc" does not resolve that class
to any instance, so now we get a build failure:
> build.py...
> ArmVirtPkg/ArmVirtQemu.dsc(...): error 4000: Instance of library class
> [Tpm12DeviceLib] is not found
> in [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf] [AARCH64]
> consumed by module [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf]
The TPM-1.2 code in OvmfPkg/Tcg2ConfigPei is limited to a special use case
(a kind of physical TPM-1.2 assignment), and that has never applied to
"ArmVirtQemu.dsc".
Short-circuit the TPM-1.2 detection in the ARM/AARCH64 builds of
OvmfPkg/Tcg2ConfigPei, removing the Tpm12DeviceLib dependency.
Functionally, this patch is a no-op on IA32 / X64.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Move the calls to the Tpm12RequestUseTpm() and Tpm12SubmitCommand()
Tpm12DeviceLib functions to a separate C file, so that we can override
these actions in a subsequent patch.
This code movement requires moving the TPM_RSP_GET_TICKS / TestTpm12()
helper structure / function too.
While at it, give the TestTpm12() function @retval / @return
documentation, plus wrap an overlong line in it.
Functionally, this patch is a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Commit 8923699291 introduced an explicit Tpm12CommandLib dependency to
Tcg2ConfigPei.
In reality this lib class is not consumed by Tcg2ConfigPei at all (such a
dependency is not even inherited from other lib instances). Simplify the
module by dropping the superfluous dependency.
(The Tpm12CommandLib class resolution that was also added in commit
8923699291 is not useless, at the platform build level: it is consumed
by TcgPei and TcgDxe. Meaning that said Tpm12CommandLib resolution should
have likely been a part of the subsequent patch in the original series,
namely commit 6be54f15a0c9.)
Commit 8923699291 also introduced SwapBytesXx() calls. Those functions
are provided by BaseLib. Spell out the BaseLib dependency.
Functionally, this patch is a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-2-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2726
When FSP switching stack and calling bootloader functions,
the function parameter in stack may not be accessible easily.
We can store the function parameter pointer to FspGlobalData
and retrieve it after stack switched.
Also need to add Loader2PeiSwitchStack () to header file
as public function for platform FSP code to consume.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Add bitmask to structure which gives a binary-inspectable mechanism to
determine if a capsule contains an authentication section or depex section.
(UEFI 2.8 errata a, mantis 2026)
Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Add bitmask to structure which gives a binary-inspectable mechanism to
determine if a capsule contains an authentication section or depex section.
(UEFI 2.8 errata a, mantis 2026)
Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Add bitmask to structure which gives a binary-inspectable mechanism to
determine if a capsule contains an authentication section or depex section.
(UEFI 2.8 errata a, mantis 2026)
Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Define Guid & data structure for EFI_RT_PROPERTIES_TABLE, designed
to be published by a platform if it no longer supports all EFI
runtime services once ExitBootServices() has been called by the OS.
(UEFI 2.8 errata a, mantis 2049)
Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Some OUT parameters in the specification were mistakenly marked as IN OUT.
"IN OUT" replaced with "OUT" in the following interfaces
EFI_BOOT_SERVICES.GetMemoryMap():MemoryMap
EFI_BOOT_SERVICES.LocateHandleBuffer():NoHandles
EFI_SIMPLE_POINTER_PROTOCOL.GetState():State
EFI_ABSOLUTE_POINTER_PROTOCOL.GetState():State
EFI_EDID_OVERRIDE_PROTOCOL.GetEdid():EdidSize and Edid
EFI_ATA_PASS_THRU_PROTOCOL.BuildDevicePath():DevicePath
EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL.BuildDevicePath():DevicePath
EFI_SD_MMC_PASS_THRU_PROTOCOL.BuildDevicePath():DevicePath
EFI_EXT_SCSI_PASS_THRU_PROTOCOL.BuildDevicePath():DevicePath
EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImage():Image
(UEFI 2.8 errata a, mantis 2035)
Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The condition, NET_HEADSPACE(&(Nbuf->BlockOp[Index])) < Len, is
meaningless if Index = 0. So checking 'Index != 0' should be
performed first in the if statement.
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Any new OVMF binary (containing commit d42fdd6f83, and built with
SMM_REQUIRE) is likely to reboot during its first boot, regardless of
whether the variable store is logically empty, or it contains a
MemoryTypeInformation variable from an earlier OVMF binary.
This "reboot on first boot after OVMF upgrade" occurs despite having
eliminated BS Code/Data tracking in earlier parts of this series. Meaning
that we've outgrown the bins of those memory types too that matter for SMM
security.
Eliminating said reboot will make an upgrade to edk2-stable202005 more
comfortable for users. Increase the defaults empirically. (The total
doesn't exceed 3MB by much.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Some OvmfPkg modules already depend on "EmbeddedPkg.dec"; thus, replace
the open-coded memory type info defaults in the source code with the
EmbeddedPkg PCDs that stand for the same purpose. Consequently, platform
builders can override these values with the "--pcd" option of "build",
without source code updates.
While at it, sort the memory type names alphabetically.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-4-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The previous patch has no effect -- i.e., it cannot stop the tracking of
BS Code/Data in MemTypeInfo -- if the virtual machine already has a
MemoryTypeInformation UEFI variable.
In that case, our current logic allows the DXE IPL PEIM to translate the
UEFI variable to the HOB, and that translation is verbatim. If the
variable already contains records for BS Code/Data, the issues listed in
the previous patch persist for the virtual machine.
For this reason, *always* install PlatformPei's own MemTypeInfo HOB. This
prevents the DXE IPL PEIM's variable-to-HOB translation.
In PlatformPei, consume the records in the MemoryTypeInformation UEFI
variable as hints:
- Ignore all memory types for which we wouldn't by default install records
in the HOB. This hides BS Code/Data from any existent
MemoryTypeInformation variable.
- For the memory types that our defaults cover, enable the records in the
UEFI variable to increase (and *only* to increase) the page counts.
This lets the MemoryTypeInformation UEFI variable function as designed,
but it eliminates a reboot when such a new OVMF binary is deployed (a)
that has higher memory consumption than tracked by the virtual machine's
UEFI variable previously, *but* (b) whose defaults also reflect those
higher page counts.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
In commit d42fdd6f83 ("OvmfPkg: improve SMM comms security with adaptive
MemoryTypeInformation", 2020-03-12), we enabled the boot-to-boot tracking
of the usages of various UEFI memory types.
Both whitepapers listed in that commit recommend that BS Code/Data type
memory *not* be tracked. This recommendation was confirmed by Jiewen in
the following two messages as well:
[1] https://edk2.groups.io/g/devel/message/55741http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97B579@shsmsx102.ccr.corp.intel.com
[2] https://edk2.groups.io/g/devel/message/55749http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97BDC5@shsmsx102.ccr.corp.intel.com
While tracking BS Code/Data type memory has one benefit (it de-fragments
the UEFI memory map), the downsides outweigh it. Spikes in BS Data type
memory usage are not uncommon in particular, and they may have the
following consequences:
- such reboots during normal boot that look "spurious" to the end user,
and have no SMM security benefit,
- a large BS Data record in MemoryTypeInformation may cause issues when
the DXE Core tries to prime the according bin(s), but the system's RAM
size has been reduced meanwhile.
Removing the BS Code/Data entries from MemoryTypeInformation leads to a
bit more fragmentation in the UEFI memory map, but that should be
harmless.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-2-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Intel SDM introduces 6-levels for describing the CPU topology:
* Package
* Module
* Tile
* Die
* Core
* Thread
A PI spec ECR was submitted to enhance CPU_MP PPI/Protocol to
support returning such information through GetProcessorInfo().
An accordingly change was implemented and pushed to edk2-staging.
Now the PI spec has been published.
The patch is cherry-picked from edk2-staging to edk2.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Added EXTENDED_PROCESSOR_INFORMATION structure and supporting
structures and definitions. The intent is to support updated
topology layout for CPUs. (PI 1.7a Mantis 2071)
Signed-off-by: Robert Phelps <robert@ami.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Created new header file for the new EFI_DELAYED_DISPATCH_PPI PPI
(PI 1.7 Mantis 1891)
Signed-off-by: Robert Phelps <robert@ami.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Revision number defines and MACROs were incorrect for the current
version of the Specification (PI 1.7 Mantis 1892)
Signed-off-by: Robert Phelps <robert@ami.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Updated PiStatusCodes to reflect changes to PI 1.7 Specification
(PI 1.7 Mantis 1889)
Signed-off-by: Robert Phelps <robert@ami.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1898
The binary is totally changed, so update the Crypto Version to 7:
1. Retire below deprecated function:
MD4, ARC4, TDES, AES ECB MODE, HMAC MD5, HMAC SHA1
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1898
Convert file ending of the crypto created openssl config file -
opensslconf.h from '\n' to '\r\n' to make align the line ending and
pass the patch check.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1898
HMAC SHA1 is not secure any longer.
Remove the HMAC SHA1 support from edk2.
Change the HMAC SHA1 field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1898
HMAC MD5 is not secure any longer.
Remove the HMAC MD5 support from edk2.
Change the HMAC MD5 field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1898
Add the unrequired aes_ecb files in process_files.pl and run it
thru perl.
It would remove the unrequired aes_ecb files from OpensslLib inf.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1898
Aes Ecb mode is not secure any longer.
Remove the Aes Ecb mode support from edk2.
Change the Aes Ecb mode field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1898
This patch is create by adding the setting "no_des" of
process_files.pl and running it thru perl.
It would remove the TDES from OpensslLib.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1898
TDES is not secure any longer.
Remove the Tdes support from edk2.
Change the Tdes field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1898
This patch is create by adding the setting "no_rc4" of
process_files.pl and running it thru perl.
It would remove the ARC4 from OpensslLib.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Bob Feng
Irene Park
Ard Biesheuvel
Vijayenthiran Subramaniam
Nickle Wang
Bret Barkelew
Michael Kubacki
Michael D Kinney
Vitaly Cheptsov
Maggie Chu
Liu, Zhiguang
Sami Mujawar
Laszlo Ersek
Chasel Chiu
Oleksiy Yakovlev
Liming Gao
Zhang, Shenglei
Ray Ni
Robert Phelps
Zhichao Gao