gcc-11 (fedora 35):
/home/kraxel/projects/edk2/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c: In function ?UsbIoBulkTransfer?:
/home/kraxel/projects/edk2/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c:277:12: error: ?UsbHcBulkTransfer? accessing 80 bytes in a region of size 8 [-Werror=stringop-overflow=]
Upstream commit ae8272ef78
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Update the `SecureBootEnable` variable and perform a platform reset when
the enable/disable button is pressed.
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Shoehorn in logic from Device Manager to show only the Secure Boot
Config entry under the firmware config form.
Signed-off-by: Tim Crawford <tcrawford@system76.com>
In function ?SetDevicePathEndNode?,
inlined from ?FileDevicePath? at DevicePathUtilities.c:857:5:
DevicePathUtilities.c:321:3: error: writing 4 bytes into a region of size 1 [-Werror=stringop-overflow=]
321 | memcpy (Node, &mUefiDevicePathLibEndDevicePath, sizeof (mUefiDevicePathLibEndDevicePath));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from UefiDevicePathLib.h:22,
from DevicePathUtilities.c:16:
../Include/Protocol/DevicePath.h: In function ?FileDevicePath?:
../Include/Protocol/DevicePath.h:51:9: note: destination object ?Type? of size 1
51 | UINT8 Type; ///< 0x01 Hardware Device Path.
| ^~~~
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Sdk/C/LzmaEnc.c: In function ?LzmaEnc_CodeOneMemBlock?:
Sdk/C/LzmaEnc.c:2828:19: error: storing the address of local variable ?outStream? in ?*p.rc.outStream? [-Werror=dangling-pointer=]
2828 | p->rc.outStream = &outStream.vt;
| ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
Sdk/C/LzmaEnc.c:2811:28: note: ?outStream? declared here
2811 | CLzmaEnc_SeqOutStreamBuf outStream;
| ^~~~~~~~~
Sdk/C/LzmaEnc.c:2811:28: note: ?pp? declared here
Sdk/C/LzmaEnc.c:2828:19: error: storing the address of local variable ?outStream? in ?*(CLzmaEnc *)pp.rc.outStream? [-Werror=dangling-pointer=]
2828 | p->rc.outStream = &outStream.vt;
| ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
Sdk/C/LzmaEnc.c:2811:28: note: ?outStream? declared here
2811 | CLzmaEnc_SeqOutStreamBuf outStream;
| ^~~~~~~~~
Sdk/C/LzmaEnc.c:2811:28: note: ?pp? declared here
cc1: all warnings being treated as errors
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Preserve existing UI and add the note about pressing Space to go to
the systemd-boot menu for Pop!_OS Recovery.
Signed-off-by: Tim Crawford <tcrawford@system76.com>
In coreboot, we mark GPU prefmem above 4GB, because NVIDIA wants a lot
(16GB region on the 30 series), otherwise coreboot will obviously fail
to allocate the resources.
In EDK2, we then end up hitting this assert:
InitRootBridge: populated root bus 0, with room for 36 subordinate bus(es)
RootBridge: PciRoot(0x0)
Support/Attr: 7001F / 7001F
DmaAbove4G: No
NoExtConfSpace: No
AllocAttr: 0 ()
Bus: 0 - 24 Translation=0
Io: 1000 - EFFF Translation=0
Mem: 80400000 - 1001FFFFFF Translation=0
MemAbove4G: FFFFFFFFFFFFFFFF - 0 Translation=0
PMem: FFFFFFFFFFFFFFFF - 0 Translation=0
PMemAbove4G: FFFFFFFFFFFFFFFF - 0 Translation=0
ASSERT [PciHostBridgeDxe] .../edk2/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(120): Bridge->Mem.Limit < 0x0000000100000000ULL
So, bring back Pci*NoEnumerationDxe from the deleted DuetPkg, which
doesn't check anything and let's us boot.
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Register an event to trigger when a block device is added or removed
that will update the list of boot options. Use a refreshguid to force
the form to display the changes if it already open.
Make use of the SMFI command interface to forward logs from edk2 to
System76 EC.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
The keyword is not defined and will end as public variable beeing declared
in every source that includes the header.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Make sure that:
* FaultTolerantDxe is started before VariableRuntimeDxe
This ensures that FailedTolerantPei is not required and faults when writing
the variable store are discovered
* SMBUSConfigLoader is started right after VariableRuntimeDxe
This ensured that the board specific variables are updated as soon as possible
* Start SmbiosDxe and BlSupportDxeSmbios early to install board specific NULL protocols
* Start SecureBootConfigDxe right after VariableRuntimeDxe to update SecureBootKeys before
Tcg2Dxe starts
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Read the coreboot table containing the TPM PPI handoff buffer and
place it in gEfiTcgPhysicalPresenceInfoHob.
coreboot uses the same PPI interface as QEMU does and installs the
corresponding ACPI code to provide a full PPI interface to the OS.
The OS must reboot in order to execute the requests.
The corresponding coreboot patch can be found here:
https://review.coreboot.org/c/coreboot/+/45568
In a follow up commit the OvmfPkg PhysicalPresence library will be used
to confirm TPM PPI request. This is necessary as coreboot doesn't have
input drivers or a graphical UI that could be used.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Instead of waiting and infinite time, abort the TPM PPI request after
3 minutes. This allow to boot headless platforms where no keyboard is
attached or the user didn't made it in time.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Put the PPI configuration retriveal into an own library.
That will allow to reuse the code in the UefipayloadPkg, where the
firmware provides the ACPI tables, like QEMU does on OvmfPkg.
However one major difference is that the PPI interface in UefiPayloadPkg
is not backed by a MMIO device, but resides in DRAM and is shared with ACPI code.
Add an additional parameter to provide the location of the PPI and
test if the memory region has the correct attributes.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
* Add support for TPM1.2 and TPM2.
This adds measured boot support and will be extended with Secureboot.
Signed-off-by: Christian Walter <christian.walter@9elements.com>
In BlSupportDxe read the AcpiBoardInfo and set PcdTpmInstanceGuid
to indicate that a TPM is likely present as TPM tables had been installed
by the bootloader.
The Tcg*Dxes will probe for the TPM, so no need to do it here as well.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Probe for ACPI tables
* TPM2
* TCPA
and store the result in AcpiBoardInfo.
Will be used to determine if a TPM1.2 or TPM2.0 is present.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Install the gPciPlatformProtocol to scan for Option ROMs.
For every device we probe the Option ROM and provide a pointer
to the activated BAR if found.
It's safe to assume that all ROM bars have been enumerated,
reserved in the bridge resources and are disabled by default.
This is made a mandatory bootloader requirement in the next commit.
Enabling them and leaving them enabled will do no harm.
This can easily be tested on qemu, where it will start finding Option ROMs
for VGA and network cards.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Marcello Sylvester Bauer <marcello.bauer@9elements.com>
Cc: Patrick Rudolph <patrick.rudolph@9elements.com>
Cc: Christian Walter <christian.walter@9elements.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Recent model Chromebooks only return ACK, but not
BAT_SUCCESS, which causes hanging and failed ps2k init.
To mitigate this, make the absence of BAT_SUCCESS reply
non-fatal, and reduce the no-reply timeout from 4s to 1s.
Tested on google/dracia and purism/librem_14
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Don't set PcdDebugPropertyMask for release builds, and properly set it
for debug builds based on SOURCE_DEBUG_ENABLE.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Previous 1s timeout causeed stalls on boot splash with no benefit.
Reduced to 100ms and no interruptions to boot when no SD card inserted.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
array.fromstring and array.tostring deprecated, and alias for
array.frombytes and array.tobytes. Deprecated since version 3.2,
have been removed in version python 3.9.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Yunhua Feng <fengyunhua@byosoft.com.cn>
Startup script does nothing other than confuse users.
Show a welcome banner and tell users how to exit.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Make sure that:
* FaultTolerantDxe is started before VariableRuntimeDxe
This ensures that FailedTolerantPei is not required and faults when writing
the variable store are discovered
* Start BlSupportDxeSmbios early to install board specific NULL protocols
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
This adds support for FVB in order to support a platform independent
and non-volatile variable store on UefiPayloadPkg. It is required for
non-volatile variable support, TPM support, Secureboot support and more.
Since commit bc744f5893fc4d53275ed26dd8d968011c6a09c1 coreboot supports
the SMMSTORE v2 feature. It implements a SMI handler that is able to
write, read and erase pages in the boot media (SPI flash).
The communication is done using a fixed communication buffer that is
allocated in CBMEM. The existence of this optional feature is advertised
by a coreboot table.
When the SMMSTORE feature is not available the variable emulation is used
by setting PcdEmuVariableNvModeEnable to TRUE.
Add a library for SMMStore to be used in DXE.
The DXE component provides runtime services and takes care of virtual to
physical mapping the communication buffers between SMM and OS.
Make use of the APRIORI DXE to initialize an empty store on the first boot
and set the PCDs to sane values before the variable driver is loaded.
Tests on Intel(R) Xeon(R) E-2288G CPU @ 3.70G showed that the SMI isn't
triggered with a probability of 1:40 of all cases when called in a tight
loop. The CPU continues running and the SMI is triggeres asynchronously
a few clock cycles later. coreboot only handels synchronous APM request
and does nothing on asynchronous APM triggers.
As there's no livesign from SMM it's impossible to tell if the handler
has run. Just wait a bit and try again to trigger a synchronous SMI.
Tests confirmed that out of 5 million tries the SMI is now always handled.
Tested on Linux and Windows 10 on real hardware.
Currently this cannot be tested on coreboot and qemu as it doesn't support
the SMMSTORE on qemu.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
This fixes an issue where the framebuffer provided by coreboot or
slimbootloader will only work on the primary VGA device. If the
framebuffer corresponds to a different device the screen will stay black.
In addition, the code doesn't work for multiple graphic cards, has
reference to non existing functions, and is a duplication of common code.
Call EfiBootManagerConnectVideoController on every display device found,
not only the legacy VGA device. This is the same as OvmfPkg does.
Allows to display output on the framebuffer set up by firmware, which might
not be the VGA device.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Uses the RDRAND instruction if available and install EfiRngProtocol.
The protocol may be used by iPXE or the Linux kernel to gather entropy.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
No need to check the interface protocol then conditionally setting,
just set it to BOOT_PROTOCOL and check for error.
This is what Linux does for HID devices as some don't follow the USB spec.
One example is the Aspeed BMC HID keyboard device, which adds a massive
boot delay without this patch as it doesn't respond to 'GetProtocolRequest'.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
the default value, TRUE, causes reboots if a device boots to the
shell, exits, and then attempts to boot from another source.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Add support for Bayhub eMMC controller found on AMD
Stoneyridge Chromebooks.
Test: build/boot various google/kahlee-based devices
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Add device type prefixes for USB, IDE, SATA, and NVMe drives.
Remove UEFI prefix, remove serial numbers.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
BMP files by tools other than MS paint can have a
variable number of padding bytes, which results in
the DataSize being less than (ImageSize - HeaderSize).
Fix the check to be less stringent.
Test: use BMP created by/saved by Photoshop
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
This is a shoehorned-in implementation of an ACPI BGRT
table, ported pretty much directly from the version used
under CorebootPayloadPkg.
EDK2 provides a facility to do this already, but it assumes
the ACPI tables already exist as EFI structures, so would need
to write code to populate those using the tables already in RAM
created by coreboot. This seemed like the easier option ATM.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
V1: Add quotes when using $(ARCH) in .dsc and .fdf file.
The quotes are added due to the way by which Core ci parse the .dsc file.
Add UINTN in Hob.c to fix cast from pointer to integer of different size error.
V2: Delete lines which reference ShellBinPkg.The pkg doesn't exist in edk2.
Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Signed-off-by: DunTan <dun.tan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Change-Id: I18c2027f57a4fbf291925a11226ed620b808a970
Map->Operation is used to select whether a DMA region that
is being bounced has the source buffer copied to it. Except
Map->Operation isn't yet set, so the behavior is somewhat
random. Instead use the passed in Operation parameter.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Adding two unit test case for UefiSortLib. One is a test on
sorting an array of UINT32 by using PerformQuickSort, another
is a test on comparing the same buffer by using StringCompare.
Add 'main' function name to ECC exception list to avoid ECC
error.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
This change allows to build StandaloneMmPkg components for 32bit Arm
StandaloneMm firmware.
This change mainly moves AArch64/ source files to Arm/ side directory
for several components: StandaloneMmCpu, StandaloneMmCoreEntryPoint
and StandaloneMmMemLib. The source file is built for both 32b and 64b
Arm targets.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Use intermediate (UINTN) cast when casting int from/to pointer. This
is needed as UINT64 values cast from/to 32bit pointer for 32bit
architectures.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Change GenFv for Arm architecture to generate a specific jump
instruction as image entry instruction, when the target entry label
is assembled with Thumb instruction set. This is possible since
SecCoreEntryAddress value fetched from the PE32 has its LSBit set when
the entry instruction executes in Thumb mode.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Changes in ArmPkg to prepare building StandaloneMm firmware for
32bit Arm architectures.
Adds ArmmmuStandaloneMmLib library to the list of the standard
components build for ArmPkg on when ARM architectures.
Changes path of source file AArch64/ArmMmuStandaloneMmLib.c
and compile it for both 32bit and 64bit architectures.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Defines ARM_SVC_ID_FFA_* and ARM_SVC_ID_SP_* identifiers for 32bit
function IDs as per SMCCC specification. Defines also generic ARM
SVC identifier macros to wrap 32bit or 64bit identifiers upon target
built architecture.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Public the header file, move RefishCrtLib.h from PrivateInclude/
to Include/.
RefishCrtLib.lib will be public later. (Moved out from PrivateLibrary/)
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
Bugzilla: 3516 (https://bugzilla.tianocore.org/show_bug.cgi?id=3516)
This patch introduces a header file for the ACPI specification version
6.4. Currently it is based on the Acpi63.h header file however makes
six changes:
1. Replace all occurences of "6_3"/"6.3" with "6_4/6.4".
2. Remove the trailing underscore from the header guard in accordance
with the EDK2 coding standards, section 5.3.5.
3. Make Acpi64.h the latest ACPI definition included by Acpi.h.
4. Fix the BGRT Status field comment to match the ACPI 6.3A spec.
5. Fix several typos where definitions were named "PMMT" when it should
be "PMTT".
6. Fix a typo: "PPTT Platform Communication Channel" should be "PDTT
Platform Communication Channel".
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Change the default value of the below PCDs to diable some legacy feature.
gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDegradeResourceForOptionRom|FALSE
gUefiCpuPkgTokenSpaceGuid.PcdCpuNumberOfReservedVariableMtrrs|0
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Define some PCDs as DynamicEX PCD to be used as global variable.
Because PcdUartDefaultBaudRate is defined as DynamicEX, remove the code
to set it in platformlib. That code was actually redundant.
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Add the three PCDs as fixed at build PCD:
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister
The default value is defined as Macro, so it can be passed in at build
command.
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2855
The Tpm2GetCapabilitySupportedAndActivePcrs function prints a
count number that should reflect the *supported and currently
active* PCR banks, but the implementation in place displays
instead the count of the *supported PCR banks* retrieved
directly from the Tpm2GetCapabilityPcrs()
TPML_PCR_SELECTION output.
The counter should only take into account those PCRs banks
which are active.
Replaced usage of EFI_D_* for DEBUG_* definitions in debug
messages.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Qi Zhang <qi1.zhang@intel.com>
Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
it can be used in a media device path to specify a Linux style initrd
that can be loaded by the OS using the LoadFile2 protocol.
Move these defines to MdePkg from OvmfPkg as these are relevant to
non-OVMF targets as well.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
This commit add option which allows reset content of Secure Boot
keys and databases to default variables.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie> # on Raspberry Pi 4
This commits adds modules and dependencies related
to initialization and usage of default Secure Boot
key variables to SecurityPkg.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie> # on Raspberry Pi 4
This application allows user to force key enrollment from
Secure Boot default variables.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
This driver initializes default Secure Boot keys and databases
based on keys embedded in flash.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie> # on Raspberry Pi 4
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
This commits add file which can be included by platform Flash
Description File. It allows to specify certificate files, which
will be embedded into binary file. The content of these files
can be used to initialize Secure Boot default keys and databases.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This commit removes functions which were added
to SecureBootVariableLib. It also adds dependecy
on that library.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
The edk2 patch
SecurityPkg: Create library for setting Secure Boot variables.
moves generic functions from SecureBootConfigDxe and places
them into SecureBootVariableLib. This patch adds SecureBootVariableLib
mapping for EmulatorPkg.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The edk2 patch
SecurityPkg: Create library for setting Secure Boot variables.
moves generic functions from SecureBootConfigDxe and places
them into SecureBootVariableLib. This patch adds SecureBootVariableLib
mapping for OvmfPkg.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The edk2 patch
SecurityPkg: Create library for setting Secure Boot variables.
moves generic functions from SecureBootConfigDxe and places
them into SecureBootVariableLib. This patch adds SecureBootVariableLib
mapping for ArmVirtPkg platform.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This commits add library, which consist functions to
enrolll Secure Boot keys and initialize Secure Boot
default variables. Some of the functions was moved
from SecureBootConfigImpl.c file.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
This commits add library, which consist helper functions related
to creation/removal Secure Boot variables. Some of the functions
was moved from SecureBootConfigImpl.c file.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
This library extends Boot Maintenance Menu and allows to select
Boot Discovery Policy. When choice is made BootDiscoveryPolicy
variable is set. Platform code can use this variable to decide
which class of device shall be connected.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
In Split tool, the copy file actions only need to
copy file content but not need to copy file metadata.
copy2() copies the file metadata that causes split
unit test failed under edk2-basetools CI environment.
So this patch changes the call of copy2() to copyfile().
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
threading camelCase functions have preferred alternatives since
python2.6. python3.10 has started emitting DeprecationWarnings
for them
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
This patch fixes two issues below:
1. SCT SetTime_Func failures.
- https://github.com/pftf/RPi4/issues/164
2. Using shell time and date commands to set time can't work.
The problem is that gRT->SetTime always returns EFI_INVALID_PARAMETER
error status.
The root cause is that LibSetTime() sets RtcEpochSeconds variable with
inconsistent attributes. One is without EFI_VARIABLE_NON_VOLATILE,
the other one is with EFI_VARIABLE_NON_VOLATILE. That caused that the
variable driver returns EFI_INVALID_PARAMETER. Per UEFI spec, if a
preexisting variable is rewritten with different attributes,
SetVariable() shall not modify the variable and shall return
EFI_INVALID_PARAMETER.
Therefore, the solution is to add EFI_VARIABLE_NON_VOLATILE attribute
to the first EfiSetVariable() call to make two calls consistent.
By the way, this patch also fix a minor issue with a debug message.
Signed-off-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
* Update GetMaintainer.py to support an optional GitHub ID at the
end of maintainer and reviewer lines.
* Remove contents after email address from standard output
* Fix minor issue in --lookup to convert file path separators
from '\' to '/' to be compatible with regular expression
file matching.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The following changes were addressed,
1. Smbios specs 3.4.0 table-51 bit5&6, these fields moved
from specific MemoryArrayLocationCXLFlexbus10AddonCard
to generic MemoryArrayLocationCXLAddonCard
to address both CXL1.0 and 2.0 CXL revisions.
2. Smbios specs 3.4.0 table-79, The memory technology name changed
from MemoryTechnologyIntelPersistentMemory
to MemoryTechnologyIntelOptanePersistentMemory.
Signed-off-by: Thotala Gopi <gopi.thotala@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
cmd_load_symbols.py can only load symbols from FV. Add the possibility to
use UEFI console output to calculate dll load address and send
add-symbol-file commands directly to ArmDS debugger
dll load address can't be used directly from UEFI output, see comment in
DebugPeCoffExtraActionLib: "This may not work correctly if you generate
PE/COFF directly as then the Offset would not be required".
1) Use objdump -S module.dll | grep <_ModuleEntryPoint> to get offset
in dll (offset)
2) Use Entrypoint=<address> from UEFI console output (entrypoint)
3) dll load address is (entrypoint)-(offset)
Signed-off-by: Artem Kopotev <artem.kopotev@arm.com>
Tested-by: Pierre Gondois <Pierre.Gondois@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3483
This patch initializes the linked list RegisteredRamDisks in
RamDiskDxeEntryPoint before the registration of gEfiRamDiskProtocolGuid
with InstallMultipleProtocolInterfaces, allowing ramdisks to be created
via a callback installed with RegisterProtocolNotify as soon as the
protocol is registered.
Without this, calling RamDisk->Register() in the callback causes a crash:
ASSERT [RamDiskDxe] MdePkg/Library/BaseLib/LinkedList.c(75): List->ForwardLink != ((void *) 0)
Signed-off-by: Trammell Hudson <hudson@trmm.net>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
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>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The edk2 path and the workspace path are identical when running
Ecc on edk2. When running Ecc on another repository
(e.g.: edk2-platforms with edk2 as a submodule of edk2-platforms),
these directories are different. Indeed, in the latter configuration,
Ecc must run git commands on the tested repository, i.e. the workspace
directory, edk2-platforms.
Thus, rename edk2_path as workspace_path.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The BaseTools directory is currently being located as a
sub-directory of the WORKSPACE env var. This might not be
true in other environments. Cf EDKII Build Specification,
s4.1.3 "Build Process Restrictions":
There is no restriction on the location of the EDK_TOOLS_PATH,
it may be located within a directory identified as the
WORKSPACE directory, or in any other location that is
accessible on the development workstation.
Locate the BaseTools directory using EDK_TOOLS_PATH instead.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Currently, the ConvertFceToStructurePcd.py tool generate
StructurePcd dsc file with comments from UNI file including
non-ascii character. Following DSC spec, there should not have
non-ascii character in DSC file. This patch removes the non-ascii
character when adding the comment and changes the circle R to (R).
Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* Enable Mergify queue feature to support auto rebase when
'push' label is set and gauarntee that all EDK II CI checks
are run before merging in changes with linear history.
* Use status checks configured in GitHub branch protections
* Allow non EDK II Maintainers to create a PR
Requires an EDK II Maintainer to accept the change and
request merge by adding 'push' label. Only EDK II Maintainers
have ability to set/clear labels.
* Do not automatically close PRs for personal builds.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3476
parseInfFile currently reading the EFI_BASE_ADDRESS from INF, once the
address found still it's continues to read the complete inf file which
is not required. once the EFI_BASE_ADDRESS read from the INF no need to
read the INF further.
MSFT compiler can generate the map file address 8 or 16 based on which
architecture the INF is compiler. currently it's support for IA32,
modified the patchfv to support for all.
modification of few typo errors in parseModMapFile, getCurr function
required
verification : Working Fine
Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Cloud Hypervisor is KVM based VMM and is implemented in rust. Just like
other VMMs it need UEFI support to let ACPI work. That's why
Cloud Hypervisor is introduced here.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
There is no device like Fw-cfg in Qemu in Cloud Hypervisor, so a specific
Acpi handler is introduced here.
The handler implemented here is in a very simple way:
1. acquire the RSDP from the PCD variable in the top ".dsc";
2. get the XSDT address from RSDP structure;
3. get the ACPI tables following the XSDT structure and install them
one by one;
4. get DSDT address from FADT and install DSDT table.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The ArmVirtPkg\PlatformHasAcpiDtDxe implementation is not common
and is specific for Qemu. So add a Cloud Hypervisor specific
version that decides whether the firmware should expose an ACPI
based or a Device Tree based hardware description to an operating
system.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add OnigurumaUefiPort.h and OnigurumaUefiPort.c into ECC exception in
MdeModulePkg.ci.yaml in order to fix CI error.
Signed-off-by: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Memory buffer that is allocated by malloc() and realloc() will be
shifted by 8 bytes because Oniguruma keeps its memory signature. This 8
bytes shift is not handled while calling free() to release memory. Add
free() function to check Oniguruma signature before release memory
because memory buffer is not touched when using calloc().
Signed-off-by: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
When enter SMM exception, there will be a stack switch only if the IST
field of the interrupt gate is set. When CET shadow stack feature is
enabled, if there is a stack switch between SMM exception and SMM, the
shadow stack token busy bit needs to be cleared when return from SMM
exception to SMM. In UEFI BIOS, only page fault exception does the stack
swith when SMM shack guard feature is enabled. The condition of clear
shadow stack token busy bit should be SMM stack guard enabled, CET shadows
stack feature enabled and page fault exception.
The shadow stack token should be initialized by UINT64.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3462
Signed-off-by: Sheng Wei <w.sheng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Qihua Zhuang <qihua.zhuang@intel.com>
Cc: Daquan Dong <daquan.dong@intel.com>
Cc: Justin Tong <justin.tong@intel.com>
Cc: Tom Xu <tom.xu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Per UEFI Spec 2.8 (UEFI_Spec_2_8_final.pdf, page 114)
5.2.3 Protective MBR
Table 20. Protective MBR Partition Record protecting the entire disk
The description for BootIndicator states the following:
> Set to 0x00 to indicate a non-bootable partition. If set to any
> value other than 0x00 the behavior of this flag on non-UEFI
> systems is undefined. Must be ignored by UEFI implementations.
Unfortunately, we have been incorrectly assuming that the
BootIndicator value must be 0x00, which leads to problems
when the 'pmbr_boot' flag is set on a disk containing a GPT
(such as with GNU parted). When the flag is set, the value
changes to 0x01, causing this check to fail and the system
is rendered unbootable despite it being valid from the
perspective of the UEFI spec.
To resolve this, we drop the check for the BootIndicator
so that we stop caring about the value set there, which
restores the capability to boot such disks.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3474
Cc: Chris Murphy <chrismurphy@fedoraproject.org>
Cc: David Duncan <davdunc@amazon.com>
Cc: Lazlo Ersek <lersek@redhat.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Neal Gompa <ngompa@fedoraproject.org>
Message-Id: <20210705093603.575707-1-ngompa@fedoraproject.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
It's neccessary to allocate a Graphics Stolen Memory area to enable
GPU-Passthrough for integrated Intel GPUs. Therefore, use a new
memory layout with a static Pci32Baseaddress.
Old layout:
[... , lowmemlimit] RAM
[lowmemlimit, 0xE000 0000] PCI Space
New layout:
[... , lowmemlimit] RAM
[lowmemlimit, gsmbase ] Memory hole (may be absent)
[gsmbase , 0xC000 0000] GSM (may be absent)
[0xC000 0000, 0xE000 0000] PCI Space
Reviewed-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Rebecca Cran <rebecca@bsdio.com>
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
Message-Id: <20210705110842.14088-2-c.koehne@beckhoff.com>
Introduce the NETWORK_ISCSI_MD5_ENABLE feature test macro for NetworkPkg.
When explicitly set to FALSE, remove MD5 from IScsiDxe's CHAP algorithm
list.
Set NETWORK_ISCSI_MD5_ENABLE to TRUE by default, for compatibility
reasons. Not just to minimize the disruption for platforms that currently
include IScsiDxe, but also because RFC 7143 mandates MD5 for CHAP, and
some vendors' iSCSI targets support MD5 only.
With MD5 enabled, IScsiDxe will suggest SHA256, and then fall back to MD5
if the target requests it. With MD5 disabled, IScsiDxe will suggest
SHA256, and break off the connection (and session) if the target doesn't
support SHA256.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3355
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210629163337.14120-7-lersek@redhat.com>
Introduce the "mChapHash" table, containing the hash algorithms supported
for CHAP. Hash algos listed at the beginning of the table are preferred by
the initiator.
In ISCSI_CHAP_STEP_ONE, send such a CHAP_A value that is the
comma-separated, ordered list of algorithm identifiers from "mChapHash".
Pre-format this value string at driver startup, in the new function
IScsiCHAPInitHashList().
(In IScsiCHAPInitHashList(), also enforce that every hash algo's digest
size fit into ISCSI_CHAP_MAX_DIGEST_SIZE, as the latter controls the
digest, outgoing challenge, and hex *allocations*.)
In ISCSI_CHAP_STEP_TWO, allow the target to select one of the offered hash
algorithms, and remember the selection for the later steps. For
ISCSI_CHAP_STEP_THREE, hash the challenge from the target with the
selected hash algo.
In ISCSI_CHAP_STEP_THREE, send the correctly sized digest to the target.
If the initiator wants mutual authentication, then generate a challenge
with as many bytes as the target's digest will have, in
ISCSI_CHAP_STEP_FOUR.
In ISCSI_CHAP_STEP_FOUR (i.e., when mutual authentication is required by
the initiator), verify the target's response (digest) with the selected
algorithm.
Clear the selected hash algorithm before every login (remember that in
IScsiDxe, every login is a leading login).
There is no peer-observable change from this patch, as it only reworks the
current MD5 support into the new internal representation.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3355
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210629163337.14120-5-lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
IScsiDxe uses the ISCSI_CHAP_RSP_LEN macro for expressing the size of the
digest (16) that it solely supports at this point (MD5).
ISCSI_CHAP_RSP_LEN is used for both (a) *allocating* digest-related
buffers (binary buffers and hex encodings alike), and (b) *processing*
binary digest buffers (comparing them, filling them, reading them).
In preparation for adding other hash algorithms, split purpose (a) from
purpose (b). For purpose (a) -- buffer allocation --, introduce
ISCSI_CHAP_MAX_DIGEST_SIZE. For purpose (b) -- processing --, rely on
MD5_DIGEST_SIZE from <BaseCryptLib.h>.
Distinguishing these purposes is justified because purpose (b) --
processing -- must depend on the hashing algorithm negotiated between
initiator and target, while for purpose (a) -- allocation --, using the
maximum supported digest size is suitable. For now, because only MD5 is
supported, introduce ISCSI_CHAP_MAX_DIGEST_SIZE *as* MD5_DIGEST_SIZE.
Note that the argument for using the digest size as the size of the
outgoing challenge (in case mutual authentication is desired by the
initiator) remains in place. Because of this, the above two purposes are
distinguished for the "ISCSI_CHAP_AUTH_DATA.OutChallenge" field as well.
This patch is functionally a no-op, just yet.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3355
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210629163337.14120-4-lersek@redhat.com>
RFC 7143 explains that a single iSCSI session may use multiple TCP
connections. The first connection established is called the leading
connection. The login performed on the leading connection is called the
leading login. Before the session is considered full-featured, the leading
login must succeed. Further (non-leading) connections can be associated
with the session later.
(It's unclear to me from RFC 7143 whether the non-leading connections
require individual (non-leading) logins as well, but that particular
question is irrelevant from the perspective of this patch; see below.)
The data model in IScsiDxe exhibits some confusion, regarding connection /
session association:
- On one hand, the "ISCSI_SESSION.Conns" field is a *set* (it has type
LIST_ENTRY), and accordingly, connections can be added to, and removed
from, a session, with the IScsiAttatchConnection() and
IScsiDetatchConnection() functions.
- On the other hand, ISCSI_MAX_CONNS_PER_SESSION has value 1, therefore no
session will ever use more than 1 connection at a time (refer to
instances of "Session->MaxConnections" in
"NetworkPkg/IScsiDxe/IScsiProto.c").
This one-to-many confusion between ISCSI_SESSION and ISCSI_CONNECTION is
very visible in the CHAP logic, where the progress of the authentication
is maintained *per connection*, in the "ISCSI_CONNECTION.AuthStep" field
(with values such as ISCSI_AUTH_INITIAL, ISCSI_CHAP_STEP_ONE, etc), but
the *data* for the authentication are maintained *per session*, in the
"AuthType" and "AuthData" fields of ISCSI_SESSION. Clearly, this makes no
sense if multiple connections are eligible for logging in.
Knowing that IScsiDxe uses only one connection per session (put
differently: knowing that any connection is a leading connection, and any
login is a leading login), there is no functionality bug. But the data
model is still broken: "AuthType", "AuthData", and "AuthStep" should be
maintained at the *same* level -- be it "session-level" or "(leading)
connection-level".
Fixing this data model bug is more than what I'm signing up for. However,
I do need to add one function, in preparation for multi-hash support:
whenever a new login is attempted (put differently: whenever the leading
login is re-attempted), which always happens with a fresh connection, the
session-level authentication data needs to be rewound to a sane initial
state.
Introduce the IScsiSessionResetAuthData() function. Call it from the
central -- session-level -- IScsiSessionLogin() function, just before the
latter calls the -- connection-level -- IScsiConnLogin() function.
Right now, do nothing in IScsiSessionResetAuthData(); so functionally
speaking, the patch is a no-op.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3355
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210629163337.14120-2-lersek@redhat.com>
For R_386_RELATIVE and R_X86_64_RELATIVE, today's logic assumes that
the content pointed by the Rela->r_offset is 0 but it's not always
TRUE. We observed that linker may set the content to Rela->r_addend.
The patch removes the assertion.
There is no functionality impact for this patch.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Per ELF spec, the DT_REL/DT_RELA tag in dynamic section stores the
virtual address of the relocation section.
But today's code logic treats it as the section offset and finds
the relocation section whose offset equals to DT_REL/DT_RELA.
The logic can work when the section offset equals to the section
virtual address. But when the ELF is generated from the link script
that reserves a sizeof(pe_header) in the file beginning, the section
offset doesn't equal to section virtual address. Such logic can
not find the relocation section.
The patch fixes this bug.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3396
This is a GUI interface that can be used by users who
would like to change configuration settings directly
from the interface without having to modify the source.
This tool depends on Python GUI tool kit Tkinter.
It runs on both Windows and Linux.
The user needs to load the YAML file along with DLT file
for a specific board into the ConfigEditor, change the desired
configuration values. Finally, generate a new configuration delta
file or a config binary blob for the newly changed values to take
effect. These will be the inputs to the merge tool or the stitch
tool so that new config changes can be merged and stitched into
the final configuration blob.
This tool also supports binary update directly and display FSP
information. It is also backward compatible for BSF file format.
Running Configuration Editor:
python ConfigEditor.py
Co-authored-by: Maurice Ma <maurice.ma@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Signed-off-by: Loo Tung Lun <tung.lun.loo@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3440
The definition of EFI_MM_RESERVED_MMRAM_REGION, according to PI Spec 1.5
is also referenced in EFI_PEI_MM_CONFIGURATION_PPI. Defining this
structure as is will enforce any potential usage of MM Configuration PPI
interface to include <Protocol/MmConfiguration.h>.
This change moves this structure definition to PiMultiPhase.h, which is
already included by Protocol/MmConfiguration.h through PiMmCis.h. It also
paves way for introducing Ppi/MmConfiguration.h with proper dependency.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
When using the in-source BaseTools, edksetup.bat will exit with an
ERRORLEVEL of 1 because the line in toolsetup.bat
"%PYTHON_COMMAND% -c "import edk2basetools" >NUL 2>NUL"
fails.
Ensure ERRORLEVEL is set to 0 when edksetup.bat or toolsetup.bat is
successfully run.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Split is now a Python tool, so BaseTools\Bin\Win32\Split.exe no longer
exists. Remove the check for it from toolsetup.bat to prevent the
erroneous claim that the binary C tools are missing.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Edk2 bootloader will pass the pei pcd database, and UPL also contain a
PCD database.
Dxe PCD driver has the assumption that the two PCD database can be
catenated and the local token number should be successive。
This patch will manually fix up the UPL PCD database to meet that
assumption.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
From gUniversalPayloadExtraDataGuid Guid Hob, get the Dxe FV information,
and get the Dxe Core from the FV.
Also, make sure if there are muliple FV hob, the FV hob pointing to this FV
will be the first in the hob list.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
This patch create the UniversalPayload Entry based on the UefiPayload
Entry. It implements the logic to find a proper memory range to create the
new Hob and migrate the Hobs from Bootloader.
To make the change history clear, the logic to get the DxeCore will be in
the next patch.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
For payload entry, use PayloadEntryHobLib as HobLib and payload entry
should initialize hob base.
For DxeCore, use new added DxeHobLib as HobLib, and DxeCore will
initialize hob base.
For Dxe Driver, use new added DxeHobLib as HobLib, and use DxeHobListLib
to initialize hob base.
Adding a new library DxeHobLib + DxeHobListLib instead of using the
DxeHobLib.inf in MdePkg is because the constructor needed be separated
from DxeHobLib.
If not, when building UefiPayloadPkg, the dependency chain is as below:
DebugLib -> SerialPortLib -> PlatformHookLib -> HobLib -> DebugLib
Each library has a constructor, and this becomes a constructor circle.
To break the circle, separate the constructor from the HobLib as a new
DxeHobListLib, which won't depend on DebugLib.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Intel Platform utility Syscfg/sysfwupdt will trigger SMI
to enter BIOS interface. then BIOS invoke EncodePassword
in SMM mode to check password.
it's need sha384(in CryptSha512.c) in SMM mode.
the origin SmmCryptLib.lib size is 1389KB,
after changed, the size is 1391KB.
the origin RuntimeCryptLib.lib size is 911KB,
after changed,the size is 913KB.
in SmmCryptLib.inf and RuntimeCryptLib.inf,
change CryptSha512NULL.c to CryptSha512.c.
https://bugzilla.tianocore.org/show_bug.cgi?id=3423
Signed-off-by: xueshengfeng <xueshengfeng@byosoft.com.cn>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Previous it would hang in CpuDxe if DXE drivers are dispatched above 4GB.
Now remove the work around since the fixed in CpuDxe are merged.
Signed-off-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Currently several DXE crash due to invalid memory resource settings.
The PciHostBridgeDxe which expects the MMCONF and PCI Aperature
to be EfiMemoryMappedIO, but currently those regions are (partly)
mapped as EfiReservedMemoryType.
coreboot and slimbootloader provide an e820 compatible memory map,
which doesn't work well with EDK2 as the e820 spec is missing MMIO regions.
In e820 'reserved' could either mean "DRAM used by boot firmware" or "MMIO
in use and not detectable by OS".
Guess Top of lower usable DRAM (TOLUD) by walking the bootloader provided
memory ranges. Memory types of RAM, ACPI and ACPI NVS below 4 GiB are used
to increment TOLUD and reserved memory ranges touching TOLUD at the base
are also assumed to be reserved DRAM, which increment TOLUD.
Then mark everything reserved below TOLUD as EfiReservedMemoryType and
everything reserved above TOLUD as EfiMemoryMappedIO.
This fixes assertions seen in PciHostBridgeDxe.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
PCIe support has been added to the Kvmtool virtual machine
manager. Therefore, enable PCIe support for Kvmtool firmware.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
PCIe support has been added to Kvmtool Virtual Machine Manager.
The PCI host bridge utility lib is used to retrieve information
about the Root Bridges in a platform.
Therefore, add an instance of PciHostBridgeUtilityLib as this is
required to enable PCIe support for Kvmtool firmware.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Many of the cache definitions in ArmLibPrivate.h are being used outside
of ArmLib, in Universal/Smbios. Move them into ArmCache.h to make them
public, and remove the include of ArmLibPrivate.h from files in
Universal/Smbios.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Per discussion with MdeModulePkg package maintainer, add
Zhiguang as one of the reviewers for ACPI and SMBIOS modules.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3445
Spellcheck was not covering all specified files due to CSpell v5 and
Node v10 incompatibility of current CI pipeline configuration.
This change switches the spellcheck for ArmPlatformPkg to AuditOnly to
avoid potentially numerous spell errors. The correction action is to be
revisited by package maintainers once the tool incompatibility is
resolved.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This is the fix of the regression issue at c6b872c6.
Based on ELF spec, readonly alloc section is .rodata section. It is used.
This fix is to add back original check logic for ELF section. Now,
the readonly alloc section and execute alloc section are regarded as .text.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Per universal payload spec, the payload is in ELF format.
The patch adds a payload loader that supports to load ELF image.
The location of extra data sections whose names start with "upld."
is stored in UNIVERSAL_PAYLOAD_EXTRA_DATA HOB.
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
The payload is in ELF format per the universal payload spec.
UNIVERSAL_PAYLOAD_INFO_HEADER is stored in the ELF payload as a separate
section named ".upld_info".
Extra data needed by payload is stored in sections whose name starts
with ".upld.".
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
When passing PCD database from Edk2 boot loader to Universal Payload, the
local token number in boot loader PCD database can be different with that
in Payload PCD database.
Dynamic PCD directly use local token number, while DynamicEx will search
token number by Guid and ExTokenNumber, which are unique pair and can make
sure finding the correct token number in boot loader's PCD database.
Therefore, using DynamicEx instead of Dynamic.
Also, explicitly define some PCDs as DynamicEx, or their default type will
be Dynamic
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
If HOB contains APCI table information, entry point of AcpiTableDxe.inf
should parse the APCI table from HOB, and install these tables.
We assume the whole ACPI table
(starting with EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)
is contained by a single gEfiAcpiTableGuid HOB.
If error happens when installing ACPI table, stop installing and removing
all the tables that are already added.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The default EfiSmbiosProtocol operates on an empty SMBIOS table.
The SMBIOS tables are provided by the bootloader on UefiPayloadPkg.
Scan for existing tables in SmbiosDxe and load them if they seem valid.
This fixes the settings menu not showing any hardware information, instead
only "0 MB RAM" was displayed.
Tests showed that the OS can still see the SMBIOS tables.
SmbiosDxe will get the SMBIOS from a guid Hob.
Also will keep the SmbiosHandle if it is available.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Currently, BDS driver will link a PlatformBootManagerLib, which contains
platform specific logic. This patch get the platform specific logic from
a protocol, so that platform logic for Boot manager can be in another
binary.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
IScsiDxe (that is, the initiator) receives two hex-encoded strings from
the iSCSI target:
- CHAP_C, where the target challenges the initiator,
- CHAP_R, where the target answers the challenge from the initiator (in
case the initiator wants mutual authentication).
Accordingly, we have two IScsiHexToBin() call sites:
- At the CHAP_C decoding site, check whether the decoding succeeds. The
decoded buffer ("AuthData->InChallenge") can accommodate 1024 bytes,
which is a permissible restriction on the target, per
<https://tools.ietf.org/html/rfc7143#section-12.1.3>. Shorter challenges
from the target are acceptable.
- At the CHAP_R decoding site, enforce that the decoding both succeed, and
provide exactly ISCSI_CHAP_RSP_LEN bytes. CHAP_R contains the digest
calculated by the target, therefore it must be of fixed size. We may
only call IScsiCHAPAuthTarget() if "TargetRsp" has been fully populated.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210608121259.32451-11-lersek@redhat.com>
The IScsiHexToBin() function documents the EFI_BUFFER_TOO_SMALL return
condition, but never actually checks whether the decoded buffer fits into
the caller-provided room (i.e., the input value of "BinLength"), and
EFI_BUFFER_TOO_SMALL is never returned. The decoding of "HexStr" can
overflow "BinBuffer".
This is remotely exploitable, as shown in a subsequent patch, which adds
error checking to the IScsiHexToBin() call sites. This issue allows the
target to compromise the initiator.
Introduce EFI_BAD_BUFFER_SIZE, in addition to the existent
EFI_BUFFER_TOO_SMALL, for reporting a special case of the buffer overflow,
plus actually catch the buffer overflow.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-10-lersek@redhat.com>
The IScsiHexToBin() function has the following parser issues:
(1) If the *subject sequence* in "HexStr" is empty, the function returns
EFI_SUCCESS (with "BinLength" set to 0 on output). Such inputs should
be rejected.
(2) The function mis-handles a "HexStr" that ends with a stray nibble. For
example, if "HexStr" is "0xABC", the function decodes it to the bytes
{0xAB, 0x0C}, sets "BinLength" to 2 on output, and returns
EFI_SUCCESS. Such inputs should be rejected.
(3) If an invalid hex char is found in "HexStr", the function treats it as
end-of-hex-string, and returns EFI_SUCCESS. Such inputs should be
rejected.
All of the above cases are remotely triggerable, as shown in a subsequent
patch, which adds error checking to the IScsiHexToBin() call sites. While
the initiator is not immediately compromised, incorrectly parsing CHAP_R
from the target, in case of mutual authentication, is not great.
Extend the interface contract of IScsiHexToBin() with
EFI_INVALID_PARAMETER, for reporting issues (1) through (3), and implement
the new checks.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-9-lersek@redhat.com>
Considering IScsiBinToHex():
> if (((*HexLength) - 3) < BinLength * 2) {
> *HexLength = BinLength * 2 + 3;
> }
the following subexpressions are problematic:
(*HexLength) - 3
BinLength * 2
BinLength * 2 + 3
The first one may wrap under zero, the latter two may wrap over
MAX_UINT32.
Rewrite the calculation using SafeIntLib.
While at it, change the type of the "Index" variable from UINTN to UINT32.
The largest "Index"-based value that we calculate is
Index * 2 + 2 (with (Index == BinLength))
Because the patch makes
BinLength * 2 + 3
safe to calculate in UINT32, using UINT32 for
Index * 2 + 2 (with (Index == BinLength))
is safe too. Consistently using UINT32 improves readability.
This patch is best reviewed with "git show -W".
The integer overflows that this patch fixes are theoretical; a subsequent
patch in the series will audit the IScsiBinToHex() call sites, and show
that none of them can fail.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210608121259.32451-6-lersek@redhat.com>
The "ISCSI_CHAP_AUTH_DATA.OutChallenge" field is declared as a UINT8 array
with ISCSI_CHAP_AUTH_MAX_LEN (1024) elements. However, when the challenge
is generated and formatted, only ISCSI_CHAP_RSP_LEN (16) octets are used
in the array.
Change the array size to ISCSI_CHAP_RSP_LEN, and remove the (now unused)
ISCSI_CHAP_AUTH_MAX_LEN macro.
Remove the "ISCSI_CHAP_AUTH_DATA.OutChallengeLength" field, which is
superfluous too.
Most importantly, explain in a new comment *why* tying the challenge size
to the digest size (ISCSI_CHAP_RSP_LEN) has always made sense. (See also
Linux kernel commit 19f5f88ed779, "scsi: target: iscsi: tie the challenge
length to the hash digest size", 2019-11-06.) For sure, the motivation
that the new comment now explains has always been there, and has always
been the same, for IScsiDxe; it's just that now we spell it out too.
No change in peer-visible behavior.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3356
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Message-Id: <20210608121259.32451-4-lersek@redhat.com>
Commit c6b872c updates GenFw base code attribute to find .text section.
With GCC49 tool chain, aslc file is compiled into elf image.
But, its text section has no CODE attribute. So, it can't be detected
by new GenFw tool.For this type file. its text section is not required.
Its data section will be converted to acpi table.
This fix is to remove assert check when the generated image is ACPI data.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Tested-by: Leif Lindholm <leif@nuviainc.com>
The "OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf"
library instance is used in the following platform DSC files in edk2:
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
OvmfPkg/OvmfXen.dsc
The Xen customizations are very light-weight in this
PlatformBootManagerLib instance. Isolating them statically, for the sake
of the first three DSC files, would save negligible binary code size, and
would likely worsen code complexity (by way of introducing new internal
interfaces) or blow up source code size (by duplicating almost the entire
lib instance source code). So for now, keep this one bit of Xen dynamism
even on QEMU.
However, because it's only PlatformBootManagerLib now that uses
XenPlatformLib (for the above-stated enlightenment), restrict the
XenPlatformLib class resolution in the first three DSC files to the only
DXE driver that consumes PlatformBootManagerLib (and therefore
XenPlatformLib): BdsDxe. This will cause a build failure later if someone
attempts to call a XenPlatformLib API (that is, tries to re-introduce Xen
enlightenment) in a different module in these non-Xen DSC files.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-44-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Remove the SmbiosTablePublishEntry() function from "SmbiosPlatformDxe.c".
"SmbiosPlatformDxe.c" becomes hypervisor-agnostic.
Add SmbiosTablePublishEntry() back, simplified for QEMU, to the existent
file "Qemu.c". The GetQemuSmbiosTables() function no longer needs to be
declared in "SmbiosPlatformDxe.h"; "SmbiosPlatformDxe.h" becomes
hypervisor-agnostic.
Add SmbiosTablePublishEntry() back, renamed and simplified for Xen, to the
new, arch-independent file "Xen.c". (The existent Xen-specific C files are
arch-dependent.)
Update both INF files; remove the dependencies that are now superfluous in
each.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-43-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
"OvmfPkg/SmbiosPlatformDxe" is structured somewhat differently from the
drivers duplicated and trimmed thus far in this series. The final QEMU and
Xen versions will share a relatively significant amount of code, therefore
duplicating the whole driver is less useful, even temporarily. Instead,
duplicate the INF file, in preparation for customizing the entry point
function.
Because ArmVirtXen doesn't actually include OvmfPkg/SmbiosPlatformDxe [*],
there is only one platform that's supposed to consume the new driver:
OvmfXen. Switch OvmfXen to the new driver at once.
[*] See commit 164cf40383 ("OvmfPkg: SmbiosPlatformDxe: restrict current
Xen code to IA32/X64", 2015-07-26).
This patch is best viewed with "git show --find-copies-harder".
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-42-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
According to the function-top comment, SmbiosTablePublishEntry() is
supposed to return an error code if no SMBIOS data is found, from either
GetXenSmbiosTables() or GetQemuSmbiosTables(). Currently the function
returns EFI_SUCCESS in this case however (propagated from
gBS->LocateProtocol()). Make the return code match the documentation.
(This issue is not too important, but it gets in the way of splitting the
entry point function next.)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-38-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
- Sort all sections in the INF file.
- Remove unused packages (MdeModulePkg) and lib classes (BaseMemoryLib)
from the INF file.
- Restrict some lib classes (BaseLib, HobLib) and GUIDs (gEfiXenInfoGuid)
to IA32 and X64, in the INF file; only the IA32/X64 Xen implementation
requires these.
- Don't make "SmbiosPlatformDxe.h" #include everything just as a
convenience. Spell out directly needed #includes in every file (annotate
each with an example identifier consumed), drop unused #includes.
- Keep #includes sorted.
- Remove the leading underscore from the #include guard macro name in
"SmbiosPlatformDxe.h".
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-37-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The "OvmfPkg/Library/PciHostBridgeLibScan/PciHostBridgeLibScan.inf"
instance is used in the following platforms in edk2:
OvmfPkg/Bhyve/BhyveX64.dsc
OvmfPkg/OvmfXen.dsc
Both platforms define "PcdPciDisableBusEnumeration" with Fixed-at-Build
access method, and TRUE value. Remove the PCD from the
PciHostBridgeLibScan instance, and everything else that is useful only
when the PCD is FALSE.
In practice, this removes the PciHostBridgeUtilityGetRootBridges()
function call, which is based on fw-cfg; see
"OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.c".
(Note that the dependency on PciHostBridgeUtilityLib remains in place,
given that the PciHostBridgeLibScan instance continues using lower-level
functions from the library that do not depend on fw-cfg.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-34-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The "OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf" instance is
used by the following platforms in edk2:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
All these platforms statically inherit PcdPciDisableBusEnumeration=FALSE
from "MdeModulePkg.dec". Remove the the PCD and everything that depends on
it from the PciHostBridgeLib instance. Namely, remove the logic that
determines the root bridge apertures by (a) scanning the entire bus,
device and function number space, and (b) parsing the BAR values that were
pre-set by the Bhyve or Xen machinery.
"XenSupport.c" used to be listed explicitly in "Maintainers.txt", remove
it from that spot too.
Cc: Andrew Fish <afish@apple.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-33-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
At this point, the IncompatiblePciDeviceSupportDxe driver is included in
the following platforms in edk2:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
All those platforms inherit FALSE for "PcdPciDisableBusEnumeration" from
"MdeModulePkg.dec".
This makes the PcdGetBool() call in the entry point of the driver
superfluous; remove it. Clean up now unused dependencies in the INF file
as well.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-28-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Because "PcdPciDisableBusEnumeration" is always TRUE in the OvmfXen
platform, we can remove the delayed ACPI table installation from
XenAcpiPlatformDxe. A number of dependencies become useless this way;
remove them too.
(Note that, conversely, in the QemuFwCfgAcpiPlatformDxe driver, we
*cannot* assume that "PcdPciDisableBusEnumeration" is always FALSE,
regardless of Xen: in the ArmVirtQemu platform, the PCD may carry either
FALSE or TRUE, dependent on whether or not the QEMU "virt" machine
configuration includes a PCIe host controller, respectively.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-21-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The "OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf" module is no longer
referenced in any platform DSC file; remove it.
That orphans the "AcpiPlatform.c", "Qemu.c" and "Xen.c" files in the
"OvmfPkg/AcpiPlatformDxe/" directory; remove them.
That in turn removes the only definitions of the InstallAcpiTable(),
QemuDetected(), QemuInstallAcpiTable(), InstallXenTables() functions in
the "OvmfPkg/AcpiPlatformDxe/" directory, so remove their declarations
from "AcpiPlatform.h".
Remove "OvmfPkg/AcpiPlatformDxe/Xen.c" from the "OvmfPkg: Xen-related
modules" section of "Maintainers.txt", as well.
Cc: Andrew Fish <afish@apple.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-13-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
- #include only such public headers in "AcpiPlatform.h" that are required
by the function declarations and type definitions introduced in
"AcpiPlatform.h". Don't use "AcpiPlatform.h" as a convenience #include
file.
- In every file, list every necessary public #include individually, with
an example identifier that's actually consumed.
- Remove unnecessary lib classes, add unlisted lib classes.
- Remove unnecessary #include directives, add unlisted #include
directives.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-11-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Switch the historical OvmfPkg* platforms from the AcpiPlatformDxe driver
to the QemuFwCfgAcpiPlatformDxe driver. (The latter is used by the
ArmVirtQemu* platforms as well.)
The change effectively replaces the following call tree:
InstallAcpiTables [AcpiPlatform.c]
XenDetected [XenPlatformLib] *
InstallXenTables [Xen.c] *
GetXenAcpiRsdp [Xen.c] *
InstallQemuFwCfgTables [QemuFwCfgAcpi.c]
...
InstallOvmfFvTables [AcpiPlatform.c] *
QemuDetected [Qemu.c] *
LocateFvInstanceWithTables [AcpiPlatform.c] *
QemuInstallAcpiTable [Qemu.c] *
QemuInstallAcpiMadtTable [Qemu.c] *
CountBits16 [Qemu.c] *
QemuInstallAcpiSsdtTable [Qemu.c] *
GetSuspendStates [Qemu.c] *
PopulateFwData [Qemu.c] *
with the one below:
InstallAcpiTables [QemuFwCfgAcpiPlatform.c]
InstallQemuFwCfgTables [QemuFwCfgAcpi.c]
...
eliminating the sub-trees highlighted with "*".
There are two consequences:
(1) Xen compatibility is removed from the ACPI platform driver of the
historical OvmfPkg* platforms.
(2) The ACPI tables that are statically built into OVMF (via
"OvmfPkg/AcpiTables/AcpiTables.inf") are never installed. In
particular, OVMF's own runtime preparation of the MADT and SSDT is
eliminated.
Because of (2), remove the "OvmfPkg/AcpiTables/AcpiTables.inf" module as
well -- and then the ACPITABLE build rule too.
Note that (2) only removes effectively dead code; the QEMU ACPI
linker-loader has taken priority since QEMU 1.7.1 (2014). References:
- https://wiki.qemu.org/Planning/1.7
- https://wiki.qemu.org/Features/ACPITableGeneration
- edk2 commit 96bbdbc856 ("OvmfPkg: AcpiPlatformDxe: download ACPI
tables from QEMU", 2014-03-31)
- edk2 commit 387536e472 ("OvmfPkg: AcpiPlatformDxe: implement QEMU's
full ACPI table loader interface", 2014-09-22)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1603
LLVM/CLANG8 formal release http://releases.llvm.org/download.html#8.0.0
It can be downloaded and installed in Windows/Linux/Mac OS.
CLANG8ELF tool chain is added to generate ELF image, and convert to PE/COFF.
On Windows OS, set CLANG_HOST_BIN=n, set CLANG8_BIN=LLVM installed directory
For example:
set CLANG_HOST_BIN=n # use windows nmake
set CLANG8_BIN=C:\Program Files\LLVM\bin\
On Linux/Mac, set CLANG8_BIN=LLVM installed directory
This tool chain can be used to compile the firmware code. On windows OS,
Visual Studio is still required to compile BaseTools C tools and nmake.exe.
On Linux/Mac OS, gcc is used to compile BaseTools C tools. make is used
for makefile.
This tool chain is verified on OVMF Ia32, X64 and Ia32X64 to boot Shell.
This tool chain is verified in Windows/Linux and Mac OS.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
LLVM/CLANG doesn't support resource section generation when ELF image generated.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
CLANG8ELF tool chain generated ELF image with the different attributes
in section. Update GenFw to handle them.
1. .text section with writable attribute (support)
2. .reloc section has the symbol for *ABS* (skip)
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
LLVM LLD linker doesn't support common-page-size option. So, max-page-size
is used. To not impact GCC tool chain, new ClangBase.lds is added.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
This error was found while compiling VirtioMmioDeviceLib for X64
with the GCC5 toolchain, where EFIAPI makes a difference.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20210602045935.762211-1-kraxel@redhat.com>
[lersek@redhat.com: prepend module name to subject, trim subject back to
allowed length]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
A NameSeg is made 4 chars.
Cf. ACPI 6.4 s20.2.2 "Name Objects Encoding":
NameSeg := <leadnamechar namechar namechar namechar>
Notice that NameSegs shorter than 4 characters are filled
with trailing underscores (‘_’s).
AML_NAME_SEG_SIZE is currently defined in:
- DynamicTablesPkg/Library/Common/AmlLib/AmlDefines.h
- MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
Since the value can be inferred from the ACPI specification
and to avoid multiple definitions, move it to
MdePkg/Include/IndustryStandard/
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3418
According to xhci spec, at USB packet level, a Control Transfer
consists of multiple transactions partitioned into stages: a
setup stage, an optional data stage, and a terminating status
stage. If Data Stage does not exist, the Transfer Type flag(TRT)
should be No Data Stage.
So if data length equals to 0, TRT is set to 0.
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: Wenyi Xie <xiewenyi2@huawei.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
GetWakeupTime should return full time information, including
the daylight/timezone. Make use of the existing non-volatile
variables for that purpose. Moreover add an error checking
of possibly invalid parameters.
This partially fixes FWTS and SCT Set/GetWakeupTime tests on
Marvell platforms.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3397
Current Ppi/MmControl.h file has structure definition of "struct
_PEI_MM_CONTROL_PPI". This name mismatches with its definition in PI
Specification v1.7 (Errata) as "struct _EFI_PEI_MM_CONTROL_PPI".
In addition, field types "PEI_MM_ACTIVATE" and "PEI_MM_DEACTIVATE" used
in "struct _PEI_MM_CONTROL_PPI" mismatches with the definition of
"EFI_PEI_MM_ACTIVATE" and "EFI_PEI_MM_DEACTIVATE" in the PI spec.
This change fixes these mismatches by using the PI spec defined names.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Fixes: 6f33f7a262
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3334
IntelFsp2WrapperPkg defines following PCDs:
PcdCpuMicrocodePatchAddress
PcdCpuMicrocodePatchRegionSize
PcdFlashMicrocodeOffset
But the PCD name caused confusion because UefiCpuPkg defines:
PcdCpuMicrocodePatchAddress
PcdCpuMicrocodePatchRegionSize
PcdCpuMicrocodePatchAddress in IntelFsp2WrapperPkg means the base
address of the FV that holds the microcode.
PcdCpuMicrocodePatchAddress in UefiCpuPkg means the address of the
microcode.
The relationship between the PCDs is:
IntelFsp2WrapperPkg.PcdCpuMicrocodePatchAddress
+ IntelFsp2WrapperPkg.PcdFlashMicrocodeOffset
== UefiCpuPkg.PcdCpuMicrocodePatchAddress
IntelFsp2WrapperPkg.PcdCpuMicrocodePatchRegionSize
- IntelFsp2WrapperPkg.PcdFlashMicrocodeOffset
== UefiCpuPkg.PcdCpuMicrocodePatchRegionSize
To avoid confusion and actually the PCDs in IntelFsp2WrapperPkg
are only used by a sample FSP-T wrapper, this patch removes
the 3 PCDs defined in IntelFsp2WrapperPkg.
The FSP-T wrapper is updated to directly use the ones in UefiCpuPkg.
Signed-off-by: Jason Lou <yun.lou@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3324
The SEV-ES stacks currently share a page with the reset code and data.
Separate the SEV-ES stacks from the reset vector code and data to avoid
possible stack overflows from overwriting the code and/or data.
When SEV-ES is enabled, invoke the GetWakeupBuffer() routine a second time
to allocate a new area, below the reset vector and data.
Both the PEI and DXE versions of GetWakeupBuffer() are changed so that
when PcdSevEsIsEnabled is true, they will track the previous reset buffer
allocation in order to ensure that the new buffer allocation is below the
previous allocation. When PcdSevEsIsEnabled is false, the original logic
is followed.
Fixes: 7b7508ad78
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Marvin Häuser <mhaeuser@posteo.de>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <3cae2ac836884b131725866264e0a0e1897052de.1621024125.git.thomas.lendacky@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Bugzilla: 3415 (https://bugzilla.tianocore.org/show_bug.cgi?id=3415)
The GICv3 architecture supports up to 1020 ordinary interrupt
lines. The actual number of interrupts supported is described by the
ITLinesNumber field in the GICD_TYPER register. The total number of
implemented registers is normally calculated as
32*(ITLinesNumber+1). However, maximum value (0x1f) is a special case
since that would indicate that 1024 interrupts are implemented.
Add handling for this special case in ArmGicGetMaxNumInterrupts.
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Commit a18a9bde36 ("MdeModulePkg/Variable/RuntimeDxe: Restore Variable
Lock Protocol behavior", 2020-12-15), for bug 3111, added two such sets of
debug messages that:
(a) are relevant for developers,
(b) yet should not necessarily poke end-users, because no functionality
suffers in practice.
Both message sets are in function VariableLockRequestToLock(): the first
is a generic interface deprecation warning; the second is the
double-locking situation, which we permit for compatibility (return status
EFI_SUCCESS).
Both message sets should be emitted with the DEBUG_WARN mask, not the most
serious DEBUG_ERROR mask. On some platforms, the serial console carries
both terminal traffic, and grave (DEBUG_ERROR-only) log messages. On such
platforms, both message sets may be perceived as a nuisance by end-users,
as there is nothing they can do, and there's nothing they *should* do --
in practice, nothing malfunctions.
(Such a platform is ArmVirtQemu, built with "-D
DEBUG_PRINT_ERROR_LEVEL=0x80000000".)
Cc: Bret Barkelew <bret.barkelew@microsoft.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>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3410
Fixes: a18a9bde36
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210521204037.11980-1-lersek@redhat.com>
Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Code mistake, VariableIndex is smaller normally than buffer+buffersize
so should not break loop.
Signed-off-by: Walon Li <walon.li@hpe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
`Status` can be used uninitialized:
/* Evaluates to FALSE */
if (ShellGetExecutionBreakFlag ()) {
Status = EFI_ABORTED;
break;
}
/* Evaluates to FALSE */
if (!Context->ContentDownloaded && !Context->ResponseToken.Event) {
Status = ...;
ASSERT_EFI_ERROR (Status);
} else {
ResponseMessage.Data.Response = NULL;
}
/* UNINITIALIZED USE */
if (EFI_ERROR (Status)) {
break;
}
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Sergei Dmitrouk <sergei@posteo.net>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
5-level paging can be enabled on CPU which supports up to 52 physical
address size. But when the feature was enabled, the 48 address size
limit was not removed and the 5-level paging testing didn't access
address >= 2^48. So the issue wasn't detected until recently an
address >= 2^48 is accessed.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2946
Currenly, when using the Brotli tool to compress data, the output
compressed binary file does not record complete compressed data
when size of input file is too large, which makes the data loss and
will trigger decompress-check issue.
The Brotli document mentioned:
The brotli tool use BrotliEncoderCompressStream method to compresses
input stream to output stream. Under some circumstances (e.g. lack of
output stream capacity) the BrotliEncoderOperation would require
several calls to BrotliEncoderCompressStream. The method must be
called again until both input stream is depleted and encoder has no
more output after the method is called.
This patch fixes this issue based on the Brotli document.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Add support for the ImageCapsuleSupport field, introduced in version 3
of the EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER structure. This
structure member is used to indicate if the corresponding payload has
support for authentication and dependency.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
AARCH64 support has been added to BaseRngLib via the optional
ARMv8.5 FEAT_RNG.
Refactor RngDxe to support AARCH64, note support for it in the
VALID_ARCHITECTURES line of RngDxe.inf and enable it in SecurityPkg.dsc.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Make BaseRngLib more generic by moving x86-specific functionality into
'Rand' and adding files under 'AArch64' to support the optional ARMv8.5
RNG instruction RNDR that is a part of FEAT_RNG.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The SCP-firmware has moved to full support for SCMIv2 which means that
the base protocol can be either compliant with SCMI v1 or v2.
Allow any version between SCMI v1.0 and SCMI v2.0 to be compatible
with the current implementation.
Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Tested-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3359
* Save/Restore global state in GetToolChainAndFamilyFromDsc()
This resolves an issue where the multi-arch build for
UefiPayloadPkg would skip the autogen and build of IA32
components.
* Expand tools wildcard.
This resolves the issue where autogen makefile contents
would have a BUIDLRULEFAMILY tools definitions with an
'*' in the tool field that breaks the build from invalid
makefile syntax.
* Build rule family higher priority than Family.
This resolves the issue where flags were appended from
both the BUILDRULEFAMILY and FAMILY when only
BUILDRULEFAMILY should be appended when present.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Andrew Fish <afish@apple.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3345
During PEI, the MMIO range for the TPM is marked as encrypted when running
as an SEV guest. While this isn't an issue for an SEV guest because of
the way the nested page fault is handled, it does result in an SEV-ES
guest terminating because of a mitigation check in the #VC handler to
prevent MMIO to an encrypted address. For an SEV-ES guest, this range
must be marked as unencrypted.
Create a new x86 PEIM for TPM support that will map the TPM MMIO range as
unencrypted when SEV-ES is active. The gOvmfTpmMmioAccessiblePpiGuid PPI
will be unconditionally installed before exiting. The PEIM will exit with
the EFI_ABORTED status so that the PEIM does not stay resident. This new
PEIM will depend on the installation of the permanent PEI RAM, by
PlatformPei, so that in case page table splitting is required during the
clearing of the encryption bit, the new page table(s) will be allocated
from permanent PEI RAM.
Update all OVMF Ia32 and X64 build packages to include this new PEIM.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <42794cec1f9d5bc24cbfb9dcdbe5e281ef259ef5.1619716333.git.thomas.lendacky@amd.com>
[lersek@redhat.com: refresh subject line]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3359
Update BaseTools to support new build targets, new tool chains,
and new architectures declared in DSC file [BuildOptions] sections.
* Do not expand * when tools_def.txt is parsed. Only expand when
both tools_def.txt and DSC [BuilsOptions] sections have been parsed.
This also requires more flexible matching of tool keys that contain *
in tool key fields.
* Pre-scan the platform DSC file for FAMILY and TOOLCHAIN declarations
DSC in [BuildOptions] sections before the FAMILY and TOOLCHAIN need
to be known.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
'Manufacturer' was spelled wrongly in a comment in
MiscChassisManufacturerData.c.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The calculation of the chassis SKU number field was being calculated
incorrectly, forgetting that there's one element already present in
the structure.
Fix the calculation and improve code readability by introducing a
SkuNumberField variable.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Add a new function to OemMiscLib to allow platforms to report their boot
status into the Type32 SMBIOS table.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Add OemMiscLib calls to allow platforms to provide the following
information about the chassis:
o Bootup state
o Power supply/supplies state
o Thermal state
o Security state
o Chassis height (in RMU)
o Number of power cords
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3293
Add constraints on the key strength of enrolled platform key(PK), which
must be greater than or equal to 2048 bit. PK key strength is required
by Intel SDL and MSFT, etc. This limitation prevents user from using
weak keys as PK.
The original code to check the certificate file type is placed in a new
function CheckX509Certificate(), which checks if the X.509 certificate
meets the requirements of encode type, RSA-Key strengh, etc.
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Jiaqi Gao <jiaqi.gao@intel.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3300
Current implementation of SetStaticPageTable routine in PiSmmCpuDxeSmm
driver will check a global variable mPhysicalAddressBits, and eventually
cap any value larger than 39 at 39.
This global variable is used in ConvertMemoryPageAttributes, which backs
SmmSetMemoryAttributes and SmmClearMemoryAttributes. Thus for a processor
that supports more than 39 bits width, trying to mark page table regions
higher than 39-bit will always return EFI_UNSUPPROTED.
This change updated the interface of SetStaticPageTable function to take
PhysicalAddressBits as an input parameter, in order to avoid changing/
accessing the global variable.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Fixes: 4eee0cc7cc
Signed-off-by: Kun Qin <kuqin12@gmail.com>
The DBG2 table generator set the access size for the UART to
DWORD (4 bytes) by default. However, according to Section B
Generic UART, Arm Base System Architecture 1.0, Platform
Design Document, a Generic UART can have BYTE, WORD or DWORD
access sizes. To address this an AccessSize field has been
introduced in CM_ARM_SERIAL_PORT_INFO object.
This patch updates the DBG2 generator to setup the AccessSize
field in the Generic Address Structure (GAS) for the UART in
the DBG2 table with information provided by the platform.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The SPCR table generator set the access size for the UART to
DWORD (4 bytes) by default. However, according to Section B
Generic UART, Arm Base System Architecture 1.0, Platform
Design Document, a Generic UART can have BYTE, WORD or DWORD
access sizes. To address this an AccessSize field has been
introduced in CM_ARM_SERIAL_PORT_INFO object.
This patch updates the SPCR generator to setup the AccessSize
field in the Generic Address Structure (GAS) for the UART in
the SPCR table with information provided by the platform.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add access size to CM_ARM_SERIAL_PORT_INFO so that this can be
passed down to the Generic Address Structure.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
8005:
Variable name does not follow the rules:
1. First character should be upper case
2. Must contain lower case characters
3. No white space characters
4. Global variable name must start with a 'g'
8007:
There should be no use of short (single character) variable names
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Complex types should be typedef-ed
The error is due to the a nested structure declaration.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Complex types should be typedef-ed
The error is due to the a nested structure declaration.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
All include file contents should be guarded by
a #ifndef statement.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
All include file contents should be guarded by
a #ifndef statement.
This patch replaces a "#if !defined [...]" statement
by a "#ifndef [...]" statement, preventing Ecc to
throw an error.
Edk2 coding standard stating that:
"Names starting with one or two underscores, such as
_MACRO_GUARD_FILE_NAME_H_, must not be used."
the include guard is also updated.
Ref:
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/
5_source_files/53_include_files#
5-3-5-all-include-file-contents-must-be-protected-by-a-include-guard
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Function name should be left justified,
followed by the beginning of the parameter list,
with the closing parenthesis on its own line,
indented two spaces
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Commit: 142fa386eb
removes the ArmGicSecLib. The file ArmGic/ArmGicSecLib.c
was exclusively used by this library. Thus, this file should
also be removed.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
No used module files found
The source files
[ArmPkg/Library/SemihostLib/SemihostPrivate.h]
is existing in module
ArmPkg/Library/SemihostLib/SemihostLib.inf
but is not described in the INF file.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
No used module files found
The source files
[ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h]
is existing in module
ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
but is not described in the INF file.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
No used module files found
The source files
[ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdog.h]
is existing in module
ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
but is not described in the INF file.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
No used module files found
The source files
[ArmPkg/Drivers/ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h]
[ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h]
[ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.h]
[ArmPkg/Drivers/ArmScmiDxe/ArmScmiBaseProtocolPrivate.h]
[ArmPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h]
are existing in module
ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
but are not described in INF the file.
The patch also re-orders the files in the
[Sources.common] section.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Module file has FILE_GUID collision with other
module file
The two .inf files with clashing GUID are:
ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
As ArmMmuBaseLib.inf is older than ArmMmuStandaloneMmLib.inf,
it has precedence.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
There should be no unnecessary inclusion of library
classes in the INF file
This comes with the additional information:
The Library Class [BootLogoLib]
is not used in any platform
The Library Class [DxeServicesLib]
is not used in any platform
The Library Class [UefiBootManagerLib]
is not used in any platform
The Library Class [PeCoffExtraActionLib]
is not used in any platform
ArmPkg/ArmPkg.dsc builds the modules requiring thses libraries,
but doesn't build the required libraries. This patch adds
the missing libraries to the [LibraryClasses.common] section.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Only Doxygen commands '@bug', '@todo', '@example', '@file',
'@attention', '@param', '@post', '@pre', '@retval', '@return',
'@sa', '@since', '@test', '@note', '@par', '@endcode', '@code',
'@{', '@}' are allowed to mark the code
This patch removes the ":" character following the "@param"
doxygen command.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Only capital letters are allowed to be used for #define
declarations
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Only capital letters are allowed to be used
for #define declarations
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
Only capital letters are allowed to be used
for #define declarations
Edk2 coding standard stating that:
"Names starting with one or two underscores, such as
_MACRO_GUARD_FILE_NAME_H_, must not be used."
the include guard of ArmCortexA5x.h is also updated.
Ref:
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/
5_source_files/53_include_files#
5-3-5-all-include-file-contents-must-be-protected-by-a-include-guard
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DependencyCheck available in .pytool detects an unnecessary
dependency of the NorFlashStandaloneMm.inf module over the
EmbeddedPkg package.
This patch removes this dependency.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Tested-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch fixes the following Ecc reported error:
INF/DEC/DSC/FDF file header comment should begin
with "## @file" or "# @file" at the very top file
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This patch fixes the following Ecc reported error:
File header doesn't exist File header comment missing
the ""Copyright""
Even though a copyright is present in the header file,
the leading '*' char prevents the Ecc tool from detecting it.
According to the edk2 coding specifcation, section 5.2.3
"File Heading", there should not be leading '*' char.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3308
The EDK II Build Specifications do not restrict the set of
CPU architectures that can be supported. Remove places in
the EDK II that assumes a fixed set of CPU architectures.
Update EFI_REMOVABLE_MEDIA_FILE_NAME to allow it to be
predefined in tools_def.txt or a DSC file [BuildOptions]
section using a *_*_*_CC_FLAGS statement.
Add support for the following two defines. If neither are
defines, then preserve the current behavior. If either is
defined, then compare these 16-bit values to Machine in the
EFI_IMAGE_MACHINE_TYPE_SUPPORTED(Machine) and
EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED(Machine) macros.
* EFI_IMAGE_MACHINE_TYPE_VALUE
* EFI_IMAGE_MACHINE_CROSS_TYPE_VALUE
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Abner Chang <abner.chang@hpe.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Abner Chang <abner.chang@hpe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In v2, BZ reference is added.
BZ#:3030
Fix the typo [in]/[out] of parameter DestroyStructure in
function header.
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3312
Update parsing of MAKE_FLAGS in DSC [BuildOptions] sections
to split the flags into a list to be compatible with
running the make command using Popen(). Parsing MAKE_FLAGS
from tools_def.txt already uses _SplitOption(). This change
uses the same _SplitOption() method for MAKE_FLAGS from a
DSC [BuildOptions] section.
Also update the parsing of MAKE_PATH to support MAKE_PATH
from tools_def.txt or the DSC [BuildOptions] section. MAKE_PATH
in DSC [BuildOptions] section is higher priority than MAKE_PATH
in tools_def.txt.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3325
1. AsmReadMsr64() in X64/GccInlinePriv.c
AsmReadMsr64 can return uninitialized value if FilterBeforeMsrRead
returns False. This causes build error with the CLANG toolchain.
2. AsmWriteMsr64() in X64/GccInlinePriv.c
In the case that FilterBeforeMsrWrite changes Value and returns True,
The original Value, not the changed Value, is written to the MSR.
This behavior is different from the one of AsmWriteMsr64() in
X64/WriteMsr64.c for the MSFT toolchain.
Signed-off-by: Takuto Naito <naitaku@gmail.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The EArmObjExtendedInterruptInfo doesn't exist. Remove any reference
to this enum.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The structure is not correctly placed in the file. Move it
so it follows the EARM_OBJECT_ID enum order.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.
Currently, nothing appear to use the value in PcdFSBClock before
XenPlatformPei had a chance to set it even though TimerLib is included
in modules run before XenPlatformPei.
XenPlatformPei doesn't use any of the functions that would use that
value. No other modules in the PEI phase seems to use the TimerLib
before PcdFSBClock is set. There are currently two other modules in
the PEI phase that needs the TimerLib:
- S3Resume2Pei, but only because LocalApicLib needs it, but nothing is
using the value from PcdFSBClock.
- CpuMpPei, but I believe it only runs after XenPlatformPei
Before the PEI phase, there's the SEC phase, and SecMain needs
TimerLib because of LocalApicLib. And it initialise the APIC timers
for the debug agent. But I don't think any of the DebugLib that
OvmfXen could use are actually using the *Delay functions in TimerLib,
and so would not use the value from PcdFSBClock which would be
uninitialised.
A simple runtime test showed that TimerLib doesn't use PcdFSBClock
value before it is set.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210412133003.146438-8-anthony.perard@citrix.com>
[lersek@redhat.com: cast Freq to UINT32 for PcdSet32S(), not for ASSERT()]
Calculate the frequency of the APIC timer that Xen provides.
Even though the frequency is currently hard-coded, it isn't part of
the public ABI that Xen provides and thus may change at any time. OVMF
needs to determine the frequency by an other mean.
Fortunately, Xen provides a way to determines the frequency of the
TSC, so we can use TSC to calibrate the frequency of the APIC timer.
That information is found in the shared_info page which we map and
unmap once done (XenBusDxe is going to map the page somewhere else).
The shared_info page is mapped at the highest physical address allowed
as it doesn't need to be in the RAM, thus there's a call to update the
page table.
The calculated frequency is only logged in this patch, it will be used
in a following patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210412133003.146438-7-anthony.perard@citrix.com>
Some information available in a Xen guest can be mapped anywhere in
the physical address space and they don't need to be backed by RAM.
For example, the shared info page.
While it's easier to put those pages anywhere, it is better to avoid
mapping it where the RAM is. It might split a nice 1G guest page table
into 4k pages and thus reducing performance of the guest when it
accesses its memory. Also mapping a page like the shared info page and
then unmapping it or mapping it somewhere else would leave a hole in
the RAM that the guest would propably not be able to use anymore.
So the patch introduces a new function which can be used to 1:1
mapping of guest physical memory above 4G during the PEI phase so we
can map the Xen shared pages outside of memory that can be used by
guest, and as high as possible.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210412133003.146438-6-anthony.perard@citrix.com>
According to ACPI 6.4, 6.1.5 _HID states:
- A valid PNP ID must be of the form "AAA####" where A is an uppercase
letter and # is a hex digit.
- A valid ACPI ID must be of the form "NNNN####" where N is an uppercase
letter or a digit ('0'-'9') and # is a hex digit.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
BZ:2919
The driver is used to manage EDK2 Redfish Configuration Handler
Protocol installed by EDK2 Redfish feature drivers.
This is the EDK2 Redfish client driver written based on the EDK2
Redfish foundation to initialize EDK2 Redfish feature drivers.
EDK2 Redfish feature drivers are used to provision/consume/update
the firmware owns Redfish properties during system power on
initialization.
RedfishConfigHandlerCommon.c has the common code for the driver
instances used in different EDK2 boot phases or used by different
driver models in the future contribution.
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Fan Wang <fan.wang@intel.com>
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
The SystemEnclosureTypeTable in QueryTable.c contained a couple
of errors: value 0x10 is "Lunch Box" not "Main Server Chassis", and
the Sub Notebook value was repeated as 0x13 when that entry is for
"SubChassis". The entries in-between needed adjusted.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2832
1. Remove PEI instance(PeiCpuTimerLib).
PeiCpuTimerLib is currently designed to save time by getting CPU TSC
frequency from Hob. BaseCpuTimerLib is designed to calculate TSC frequency
by using CPUID[15h] each time.
The time it takes to find CpuCrystalFrequencyHob (about 2000ns) is much
longer than it takes to calculate TSC frequency with CPUID[15h] (about
450ns), which means using BaseCpuTimerLib to trigger a delay is more
accurate than using PeiCpuTimerLib, recommend to use BaseCpuTimerLib
instead of PeiCpuTimerLib.
2. Remove DXE instance(DxeCpuTimerLib).
DxeCpuTimerLib is designed to calculate TSC frequency with CPUID[15h] in
its constructor function, then save it in a global variable. For this
design, once the driver containing this instance is running, this
constructor function is called, it will take extra time to calculate TSC
frequency.
The time it takes to get TSC frequency from global variable is shorter
than it takes to calculate TSC frequency with CPUID[15h], but 450ns is a
short time, the impact on the platform is very limited.
In addition, in order to simplify the code, recommend to use
BaseCpuTimerLib instead of DxeCpuTimerLib.
I did some experiments on one server platform and collected following data:
1. Average time required to find CpuCrystalFrequencyHob: about 2000 ns.
2. Average time required to find the last Hob: about 2700 ns.
2. Average time required to calculate TSC frequency: about 450 ns.
Reference code:
//
// Calculate average time required to find Hob.
//
DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib] GetPerformanceCounterFrequency - GetFirstGuidHob (1000 cycles)\n"));
Ticks1 = AsmReadTsc();
for (i = 0; i < 1000; i++) {
GuidHob = GetFirstGuidHob (&mCpuCrystalFrequencyHobGuid);
}
Ticks2 = AsmReadTsc();
if (GuidHob == NULL) {
DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib] - CpuCrystalFrequencyHob can not be found!\n"));
} else {
DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib] - Average time required to find Hob = %d ns\n", \
DivU64x32(DivU64x64Remainder(MultU64x32((Ticks2 - Ticks1), 1000000000), *CpuCrystalCounterFrequency, NULL), 1000)));
}
//
// Calculate average time required to calculate CPU frequency.
//
DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib] GetPerformanceCounterFrequency - CpuidCoreClockCalculateTscFrequency (1000 cycles)\n"));
Ticks1 = AsmReadTsc();
for (i = 0; i < 1000; i++) {
Freq = CpuidCoreClockCalculateTscFrequency ();
}
Ticks2 = AsmReadTsc();
DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib] - Average time required to calculate TSC frequency = %d ns\n", \
DivU64x32(DivU64x64Remainder(MultU64x32((Ticks2 - Ticks1), 1000000000), *CpuCrystalCounterFrequency, NULL), 1000)));
Signed-off-by: Jason Lou <yun.lou@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
CpuPause() might allow the CPU to go into a lower power state
state while we spin.
On X86, CpuPause() executes a PAUSE instruction which the Intel
and AMD specs describe as follows:
Intel:
"PAUSE: An additional function of the PAUSE instruction is to reduce
the power consumed by a processor while executing a spin loop. A
processor can execute a spin-wait loop extremely quickly, causing the
processor to consume a lot of power while it waits for the resource it
is spinning on to become available. Inserting a pause instruction in a
spin-wait loop greatly reduces the processor?s power consumption."
AMD:
"PAUSE: Improves the performance of spin loops, by providing a hint to
the processor that the current code is in a spin loop. The processor
may use this to optimize power consumption while in the spin loop.
Architecturally, this instruction behaves like a NOP instruction."
On RISC-V and ARM64, CpuPause() executes a NOP, which is no worse than
the tight loop we have.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The comments in PiSmmCommunicationPei.c describe the whole memory
layout of the SMRAM regarding the SMM communication.
But SHA-1: 8b1d149390
PiSmmCommunicationSmm: Deprecate SMM Communication ACPI Table
removed the code that produces the ACPI Table.
This change updates the accordingly comments.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Update openssl from 1.1.1g to 1.1.1j. Current OpenSSL version
1.1.1g contains the vulnerabilities of CVE-2021-23841 and
CVE-2021-23840. The related vulnerable API EVP_DecryptUpdate
are used in drivers.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3266
Besides, the opensslconf.h automatically generated by process_files.pl.
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Liu Wei <weix.c.liu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
The CommandLine and InitrdData may be set to NULL if the provided
size is too large. Because the zero page is mapped, this would not
cause an immediate crash but can lead to memory corruption instead.
This patch just adds validation and returns error if either allocation
has failed.
Signed-off-by: Martin Radev <martin.b.radev@gmail.com>
Message-Id: <YFPJsaGzVWQxoEU4@martin-ThinkPad-T440p>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
[lersek@redhat.com: drop unnecessary empty line from code; remove personal
(hence likely unstable) repo reference from commit message]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3233
GDT needs to be allocated below 4GB in 64bit environment
because AP needs it for entering to protected mode.
CPU running in big real mode cannot access above 4GB GDT.
But CpuDxe driver contains below code:
gdt = AllocateRuntimePool (sizeof (GdtTemplate) + 8);
.....
gdtPtr.Base = (UINT32)(UINTN)(VOID*) gdt;
The AllocateRuntimePool() may allocate memory above 4GB.
Thus, we cannot use AllocateRuntimePool (), instead,
we should use AllocatePages() to make sure GDT is below 4GB space.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
MpInitLib contains a function MicrocodeDetect() which is called by
all threads as an AP procedure.
Today this function contains below code:
if (CurrentRevision != LatestRevision) {
AcquireSpinLock(&CpuMpData->MpLock);
DEBUG ((
EFI_D_ERROR,
"Updated microcode signature [0x%08x] does not match \
loaded microcode signature [0x%08x]\n",
CurrentRevision, LatestRevision
));
ReleaseSpinLock(&CpuMpData->MpLock);
}
When the if-check is passed, the code may call into PEI services:
1. AcquireSpinLock
When the PcdSpinTimeout is not 0, TimerLib
GetPerformanceCounterProperties() is called. And some of the
TimerLib implementations would get the information cached in
HOB. But AP procedure cannot call PEI services to retrieve the
HOB list.
2. DEBUG
Certain DebugLib relies on ReportStatusCode services and the
ReportStatusCode PPI is retrieved through the PEI services.
DebugLibSerialPort should be used.
But when SerialPortLib is implemented to depend on PEI services,
even using DebugLibSerialPort can still cause AP calls PEI
services resulting hang.
It causes a lot of debugging effort on the platform side.
There are 2 options to fix the problem:
1. make sure platform DSC chooses the proper DebugLib and set the
PcdSpinTimeout to 0. So that AcquireSpinLock and DEBUG don't call
PEI services.
2. remove the AcquireSpinLock and DEBUG call from the procedure.
Option #2 is preferred because it's not practical to ask every
platform DSC to be written properly.
Following option #2, there are two sub-options:
2.A. Just remove the if-check.
2.B. Capture the CurrentRevision and ExpectedRevision in the memory
for each AP and print them together from BSP.
The patch follows option 2.B.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Add logic in EjectCpu() to do the actual the CPU ejection.
On the BSP, ejection happens by first selecting the CPU via
its QemuSelector and then sending the QEMU "eject" command.
QEMU in-turn signals the remote VCPU thread which context-switches
the CPU out of the SMI handler.
Meanwhile the CPU being ejected, waits around in its holding
area until it is context-switched out. Note that it is possible
that a slow CPU gets ejected before it reaches the wait loop.
However, this would never happen before it has executed the
"AllCpusInSync" loop in SmiRendezvous().
It can mean that an ejected CPU does not execute code after
that point but given that the CPU state will be destroyed by
QEMU, the missed cleanup is no great loss.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Aaron Young <aaron.young@oracle.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Message-Id: <20210312062656.2477515-10-ankur.a.arora@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: unneeded inner QemuSelector declaration in EjectCpu()
triggers VS warning #4456 (local variable shadowed); remove it]
EDK2 port of DMTF libredfish project. We clone the necessary files
from open source project libredfish (https://github.com/DMTF/
libredfish) tag v1.0.0 and revise it to incorporate with edk2
firmware code base.
The reason of cloning the necessary files instead of using extern
submodule of libredfish project:
libredfish as a C library which is executed under Windows and
Linux. It could be binded with other programming languages such as
java and python. The library uses curl library as the communication service with Redfish, which is not easy to be abstracted and
replaced with EFI specific protocols (e.g. EFI_REST_EX_PROTOCOL or
payload encode/decode library) and EFI data types. We had the
conversation with DMTF community and they think edk2 is a firmware
solution but not the programming language,
therefore they rejected to have edk2 as a binding to libredfish.
According to above, we decide to clone the necessary files from
libredfish modify it to incorporate with edk2.
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Ting Ye <ting.ye@intel.com>
Signed-off-by: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Fan Wang <fan.wang@intel.com>
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3199
When Token points to mSmmStartupThisApToken, this routine is called
from SmmStartupThisAp() in non-blocking mode due to
PcdCpuSmmBlockStartupThisAp == FALSE.
In this case, caller wants to startup AP procedure in non-blocking
mode and cannot get the completion status from the Token because there
is no way to return the Token to caller from SmmStartupThisAp().
Caller needs to use its specific way to query the completion status.
There is no need to allocate a token for such case so the 3 overheads
can be avoided:
1. Call AllocateTokenBuffer() when there is no free token.
2. Get a free token from the token buffer.
3. Call ReleaseToken() in APHandler().
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3218
Adds an INF for StandaloneMmCpuFeaturesLib, which supports building
the SmmCpuFeaturesLib code for Standalone MM. Minimal code changes
are made to allow reuse of existing code for Standalone MM.
The original INF file names are left intact (continue to use SMM
terminology) to retain backward compatibility with platforms that
use those INFs. Similarly, the pre-existing C file names are
unchanged to be consistent with the INF file names.
Note that all references in library source files to PiSmm.h have
been changed to PiMm.h for consistency.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Message-Id: <20210217213227.1277-6-mikuback@linux.microsoft.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
There's currently two library instances:
1. SmmCpuFeaturesLib
2. SmmCpuFeaturesLibStm
There's two constructor functions:
1. SmmCpuFeaturesLibConstructor()
2. SmmCpuFeaturesLibStmConstructor()
SmmCpuFeaturesLibConstructor() is called by
SmmCpuFeaturesLibStmConstructor() since the functionality in that
function is required by both library instances.
The declaration for SmmCpuFeaturesLibConstructor() is embedded in
"SmmStm.c" instead of being declared in a header file. Further,
that constructor function is called by the STM specific constructor.
This change moves the common code to a function called
CpuFeaturesLibInitialization() which is declared in an internal
library header file "CpuFeaturesLib.h". Each constructor simply
calls this function to perform the common functionality.
Additionally, SmmCpuFeaturesLibConstructor() is moved from
SmmCpuFeaturesLibNoStm.c into a instance-specific file allowing
SmmCpuFeaturesLibNoStm.c to contain no STM implementation agnostic
to a particular library instance.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210217213227.1277-4-mikuback@linux.microsoft.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
FinishSmmCpuFeaturesInitializeProcessor() is a multi-instance
internal library function that is currently not declared in a
header file but embedded in "SmmCpuFeaturesLib.c".
This change cleans up the declaration moving it to a new header
file "CpuFeaturesLib.h" and removing the local declaration in
"SmmCpuFeaturesLib.c".
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210217213227.1277-2-mikuback@linux.microsoft.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
[lersek@redhat.com: replace the guard macro "_CPU_FEATURES_LIB_H_" with
"CPU_FEATURES_LIB_H_", for fixing ECC 8003, per commit 6ffbb3581a]
The message "LibGetTime: RtcEpochSeconds non volatile variable was not
found - Using compilation time epoch." can be printed a very large
number of times, causing log files to become excessively large. This is
because the RtcEpochSeconds variable only gets set if LibSetTime is
called, for example by running 'time 12:00' in the UEFI Shell.
Avoid this by setting RtcEpochSeconds to BUILD_EPOCH (EpochSeconds)
after printing the message. It's set to a volatile variable so the
message will be displayed on future boots and not hidden.
Commit 44ae214591 reduced the verbosity of
the message to DEBUG_VERBOSE. Revert it back to DEBUG_INFO so it's more
prominent now that it doesn't get printed so frequently.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Currently StructurePcd.dsc have the list order issue. For a Pcd
with several elements, the list indexs are used to distinguish
these elements like this:
PcdName.name.offset_name[0]|0x0
PcdName.name.offset_name[10]|0x0
PcdName.name.offset_name[11]|0x0
...
PcdName.name.offset_name[2]|0x0
...
However, the index is not strictly sorted by decimal numerical order,
which is not user friendly. One more sort rule for index is added to
the current rules to support for decimal numerical order in this patch.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3168
This interface provides an abstration layer to allow MM modules to access
requested areas that are outside of MMRAM. On MM model that blocks all
non-MMRAM accesses, areas requested through this API will be mapped or
unblocked for accessibility inside MM environment.
For MM modules that need to access regions outside of MMRAMs, the agents
that set up these regions are responsible for invoking this API in order
for these memory areas to be accessible from inside MM.
Example usages:
1. To enable runtime cache feature for variable service, Variable MM
module will need to access the allocated runtime buffer. Thus the agent
sets up these buffers, VariableSmmRuntimeDxe, will need to invoke this
API to make these regions accessible by Variable MM.
2. For TPM ACPI table to communicate to physical presence handler, the
corresponding NVS region has to be accessible from inside MM. Once the
NVS region are assigned, it needs to be unblocked thourgh this API.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Kun Qin <kun.q@outlook.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Message-Id: <MWHPR06MB31028AF0D0785B93E4E7CF63F3969@MWHPR06MB3102.namprd06.prod.outlook.com>
* Copyright (c) 2011 - 2020, Arm Limited. All rights reserved.<BR>
* Copyright (c) 2016, Linaro Limited. All rights reserved.
*
* SPDX-License-Identifier: BSD-2-Clause-Patent
*
Copyright (c) 2011 - 2020, Arm Limited. All rights reserved.<BR>
Copyright (c) 2016, Linaro Limited. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
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.
