Loh, Tien Hock [Fri, 22 Feb 2019 07:58:03 +0000 (15:58 +0800)]
EmbeddedPkg/MmcDxe: Enable 4-bit mode even if SD_HIGH_SPEED is not supported
If SD doesn't support SD_HIGH_SPEED, function should still continue to
setup SD to go into 4 bits more if it is supported. Currently, the code
inadvertently exits early, but with a EFI_SUCCESS return code, and so
execution proceeds without ever attempting to enable 4-bit mode.
Since not having SD_HIGH_SPEED support is not an error, downgrade the
message that reports this to DEBUG_INFO.
mjohn4 [Fri, 2 Nov 2018 02:02:10 +0000 (10:02 +0800)]
BaseTools: Explicitly close files after readlines
Rework some file open().readlines to open, readlines, close.
This prevents excessive file handles being open at the same time,
which may be a problem with alternative python environments.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael Johnson <michael.johnson@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
This option is added to disable the include path check
for outside of package.
The original purpose of thie check is to make sure EDK II
modules must not reference header files outside of the packages
they depend on or within the module's directory tree.
However, we do see the usage to build EDKII as executable running
in the operating system which requires include path to outside.
For example, EmulatorPkg. The current solution (soft link) is
weird hack - EmulatorPkg\Unix\Host\X11IncludeHack.
With this solution, this can be supported easily.
The patch is validated with and without --disable-include-path-check.
If user does not use --disable-include-path-check, the build will fail
with outside path in the include path.
If user uses --disable-include-path-check, the build will pass
with outside path in the include path.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Add DSDT and SSDT description in the help information. Depend
on the implement of UefiShellAcpiViewCommandLib, the "acpiview"
command support to show all present type in the system not only
support the listed type in the help information. So change the
help information of this command.
Cc: Zailiang Sun <zailiang.sun@intel.com> Cc: Yi Qian <yi.qian@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Zailiang Sun <zailiang.sun@intel.com>
Shi, Steven [Wed, 30 Jan 2019 04:18:02 +0000 (12:18 +0800)]
BaseTools: Enable compiler cache support in edk2 build
https://bugzilla.tianocore.org/show_bug.cgi?id=1499
Compiler cache can greatly improve the build performance and
guarantee the build result safe. In our testing, the compiler
cache can improve the overall clean build time usually by 30+%
in linux and 10+% in windows. The compiler cache are very fit
to improve the Continuous Integration (CI) build performance.
For linux compiler cache (ccache) enabling, there is no need
to update edk2 code.
Below link has the ccache enabling referencd steps:
https://github.com/shijunjing/edk2/wiki/
Edk2-compiler-cache-enabling-steps-on-Linux
For windows compiler cache (clcache) enabling, we need update
the .PDB debugging file producing option from /Zi to /Z7,
which is to let the C object file contain its full symbolic
debugging information rather than produces a separated PDB file
for all obj files per folder. "PDB files are generated by a different
process (mspdbsrv). They arrive or are updated on disk after
cl completes a compilation or linking operation. One huge problem
with caching them is that the pdb files are input files as well as
outputs. mspdbsrv updates the file with new debug information if
the file exists beforehand. If there are several compilations going
on at once targetting the same pdb then the order the pdb gets
updated is unpredictable. All this makes caching very hard."
The /Zi issue more detail disccusion can be found:
https://github.com/frerich/clcache/issues/30
Please be aware that this change has no any impact to edk2 module
level PDB file generation, and we still can get the PDB debug file
for a .efi module. The /Z7 only impact intermediate obj files level
PDB file, which is current one PDB file (vc140.pdb) per obj folder.
Below link has the clcache enabling referencd steps:
https://github.com/shijunjing/edk2/wiki/
Edk2-compiler-cache-enabling-steps-on-Windows
Have tested below tools which consume the .PDB file:
*Edk2 source code debugger
*Various hardware and software debuggers
*Uefi code coverage tools
Only update and test below most commonly used four msvc toolchains:
VS2012x86 VS2013x86 VS2015x86 VS2017
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Steven Shi <steven.shi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Ard Biesheuvel [Mon, 21 Jan 2019 13:14:16 +0000 (14:14 +0100)]
StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable
The PCD PcdStandaloneMmEnable is unused, and shouldn't exist in the
first place since the value is implied by the context (it is never
valid to set it to FALSE for standalone MM or TRUE for traditional
MM). So drop it.
Ard Biesheuvel [Mon, 4 Mar 2019 17:17:06 +0000 (18:17 +0100)]
StandaloneMmPkg/Core: dispatch all drivers at init time
Instead of deferring dispatch of the remaining MM drivers once the
CPU driver has been dispatched, proceed and dispatch all drivers.
This makes sense for standalone MM, since all dispatchable drivers
should be present in the initial firmware volume anyway: dispatch
of additional FVs originating in the non-secure side is not supported.
Standalone MM requires 4 KB section alignment for all images, so that
strict permissions can be applied. Unfortunately, this results in a
lot of wasted space, which is usually costly in the secure world
environment that standalone MM is expected to operate in.
So let's permit the standalone MM drivers (but not the core) to be
delivered in a compressed firmware volume.
Ard Biesheuvel [Mon, 21 Jan 2019 15:05:23 +0000 (16:05 +0100)]
StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit SerialPortLib call
Sending DEBUG output to the serial port should only be done via
DebugLib calls, which is in charge of initializing the serial
port when appropriate. So drop the explicit SerialPortInitialize ()
invocation, and rely on normal constructor ordering to get the
serial port into the appropriate state at the right time.
Ard Biesheuvel [Mon, 21 Jan 2019 13:19:50 +0000 (14:19 +0100)]
StandaloneMmPkg: switch to NULL DebugLib resolution
Building StandaloneMmPkg from its .DSC is mainly intended for build
coverage, and so platform specific configuration such as UART addresses
don't belong here.
In a system implementing the variable store in MM, there are no variable
arch protocol and variable write arch protocol installed into the
DXE_SMM protocol database. On such systems, it is not required to
locate these protocols by the DXE runtime variable drivers because
it can be assumed that these protocols are already installed in the
MM context. But then such an implementation will deviate from the
existing traditional MM based variable driver implementation.
So in order to maintain consistency with the traditional MM variable
driver implementation, allow platforms to install these protocols into
the DXE protocol database but these protocol will not be consumed
by non-secure variable service runtime driver.
The Platform which uses StandaloneMM based secure variable storage
have to include this library
Example
In edk2-platforms/Platform/ARM/SgiPkg/SgiPlatform.dsc
StdLib: Update resolv.conf to use Google's DNS servers
The current servers listed appear to be unusable. I suspect most
people will get correct DNS servers via DHCP, but the defaults
should work for anyone.
Laszlo Ersek [Wed, 27 Feb 2019 21:10:45 +0000 (22:10 +0100)]
Maintainers.txt: clarify Reviewer requirements and responsibilities
The current language for "Package Reviewer" only vaguely hints that
Package Reviewers should be able to provide guidance and directions.
Make this more obvious.
Cc: Andrew Fish <afish@apple.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Andrew Fish <afish@apple.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
For 4bit BMP, there are only 2^4 = 16 colors in the palette.
But when a corrupted BMP contains more than 16 colors in the palette,
today's implementation wrongly copies all colors to the local
PaletteValue[16] array which causes stack overflow.
The similar issue also exists in the logic to handle 8bit BMP.
The patch fixes the issue by only copies the first 16 or 256 colors
in the palette depending on the BMP type.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Should make sure the TotalSize of Microcode is aligned with 4 bytes
before calling CalculateSum32 function.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chen A Chen <chen.a.chen@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com>
The Microcode region indicated by MicrocodePatchAddress PCD may contain
more than one Microcode entry. We should save InCompleteCheckSum32 value
for each payload. Move the logic for calculate InCompleteCheckSum32 from
the outsize of the do-while loop to the inside.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chen A Chen <chen.a.chen@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
The root cause of this issue is that non-stop mode of Heap Guard and
NULL Detection set TF bit (single-step) in EFLAG unconditionally in
the common handler in CpuExceptionLib.
If PcdCpuSmmStaticPageTable is FALSE, the SMM will only create page
table for memory below 4G. If SMM tries to access memory beyond 4G,
a page fault exception will be triggered and the memory to access
will be added to page table so that SMM code can continue the access.
Because of above issue, the TF bit is set after the page fault is
handled and then fall into another DEBUG exception. Since non-stop
mode of Heap Guard and NULL Detection are not enabled, no special
DEBUG exception handler is registered. The default handler just
prints exception context and go into dead loop.
Actually EFLAGS can be changed in any standard exception handler.
There's no need to do single-step setup in assembly code. So the fix
is to move the logic to C code part of page fault exception handler
so that we can fully validate the configuration and prevent TF bit
from being set unexpectedly.
Fixes: dcc026217fdc363f55c217039fc43d344f69fed6 16b918bbaf51211a32ae04d9d8a5ba6ccca25a6a
Test:
- Pass special test of accessing memory beyond 4G in SMM mode
- Boot to OS with Qemu emulator platform (Fedora27, Ubuntu18.04,
Windows7, Windows10)
Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
In WiFi Connection Manager scan process, the result received
from WiFi device driver will be freed twice, and will cause
unexpected errors, and even system crash.
This issue also exists in some other places potentially, this
patch is to fix these issues and also add Timer Cancelling
before Close to avoid potential NULL reference.
Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Wang Fan <fan.wang@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Liming Gao [Mon, 25 Feb 2019 00:15:25 +0000 (08:15 +0800)]
Revert "BaseTools:BaseTools supports to the driver combination."
This reverts commit 838bc257bae3f9fc6723f41f3980f6cfbedb77e5.
After further evaluation, there are the unclear behavior in for the
driver combination feature. To not impact Q1 stable tag, remove it first.
1. If the drivers to be combined have the different PCD or library instance
setting, build should not combine them and report build break. But this
commit doesn't consider this case.
2. When start the sub driver fail, continue to start other sub driver. This
behavior is required to be clarifed in build spec.
3. Unload the sub driver when the combined driver start fail. This case need
to call the sub driver unload function for the driver start fail only.
Wang Fan [Fri, 22 Feb 2019 07:48:25 +0000 (15:48 +0800)]
NetworkPkg: Add WiFi Connection Manager to NetworkPkg
* V2
* Remove Arch dependency in Inf file
* Add a global guid for WiFi formset and set other guids to module levels
* Open supplicant and EapConfig by BY_DRIVER
* Remove token free function to avoid potential NULL reference
* Update WifiMgrUpdateConnectMessage() to only display message for Current Nic
* Fix the potential NULL reference in AIP call
Add WiFi Connection Manager in NetworkPkg to provide UI for users to scan
networks, connect or disconnect to networks.
This connection manager won't include the UNDI driver, supplicant driver,
or other device specific drivers and is therefor not a complete solution
stack for UEFI Wi-Fi, users can seek help for Wireless card vendors.
Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Wang Fan <fan.wang@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
We scan the SMM code with ROPgadget.
http://shell-storm.org/project/ROPgadget/
https://github.com/JonathanSalwan/ROPgadget/tree/master
This tool reports the gadget in SMM driver.
This patch enabled CET ShadowStack for X86 SMM.
If CET is supported, SMM will enable CET ShadowStack.
SMM CET will save the OS CET context at SmmEntry and
restore OS CET context at SmmExit.
Test:
1) test Intel internal platform (x64 only, CET enabled/disabled)
Boot test:
CET supported or not supported CPU
on CET supported platform
CET enabled/disabled
PcdCpuSmmCetEnable enabled/disabled
Single core/Multiple core
PcdCpuSmmStackGuard enabled/disabled
PcdCpuSmmProfileEnable enabled/disabled
PcdCpuSmmStaticPageTable enabled/disabled
CET exception test:
#CF generated with PcdCpuSmmStackGuard enabled/disabled.
Other exception test:
#PF for normal stack overflow
#PF for NX protection
#PF for RO protection
CET env test:
Launch SMM in CET enabled/disabled environment (DXE) - no impact to DXE
The test case can be found at
https://github.com/jyao1/SecurityEx/tree/master/ControlFlowPkg
2) test ovmf (both IA32 and X64 SMM, CET disabled only)
test OvmfIa32/Ovmf3264, with -D SMM_REQUIRE.
qemu-system-x86_64.exe -machine q35,smm=on -smp 4
-serial file:serial.log
-drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd
QEMU emulator version 3.1.0 (v3.1.0-11736-g7a30e7adb0-dirty)
3) not tested
IA32 CET enabled platform
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yao Jiewen <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Add information dump for Control Protection exception.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yao Jiewen <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
This patch adds SSP - shadow stack pointer to JumpBuffer.
It will be used for the platform that enabled CET/ShadowStack.
We add gEfiMdePkgTokenSpaceGuid.PcdControlFlowEnforcementPropertyMask
to control the global enable/disable.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yao Jiewen <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
This is to add CET related instruction in Nasm
because CET instruction is not supported yet.
See https://www.nasm.us/xdoc/2.14.02/html/nasmdocb.html
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yao Jiewen <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
The DNS driver only checks the received packet size against the
minimum DNS header size in DnsOnPacketReceived(), later it accesses
the QueryName and QuerySection beyond the header scope, which might
cause the pointer within DNS driver points to an invalid entry or
modifies the memory content beyond the header scope.
This patch is to fix above problem.
Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Wang Fan <fan.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Originally, the block size of created Ram disks is hard-coded to 512
bytes. However, if the total size of the Ram disk is not a multiple of 512
bytes, there will be potential memory access issues when dealing with the
last block of the Ram disk.
This commit will adjust the block size of the Ram disks to ensure that the
total size is a multiple of the block size.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Sami Mujawar [Fri, 22 Feb 2019 19:43:28 +0000 (19:43 +0000)]
ArmPkg: Fix writes to GICv3 GICD_IROUTER<n> reg
According to ARM Generic Interrupt Controller Architecture
Specification, GIC architecture version 3.0 and version 4.0,
GICD_IROUTER<n> is a 64-bit register.
Fixed code to use 64 bit MMIO write operations so that the
Aff3 value (bits [39:32]) is written to GICD_IROUTER<n>.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Reported-by: Carl van Schaik <carl@cog.systems> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
LibGetTime():
- Two variables were used for the epoch, where only one should have been [*].
- Also harmonize variable name to match the one used in LibSetTime.
LibSetTime():
- Address possible underflows if time is set to start of epoch.
- Ensure that time being read does actually match time that was manually
set (plus the time elapsed since), by subtracting number of seconds
since reset.
[*] This fixes a build breakage, since one of these variables was set but
never used, triggering a compiler diagnostic at some optimization levels.
Feng, Bob C [Mon, 25 Feb 2019 09:19:02 +0000 (17:19 +0800)]
BaseTools: Fix a Eot issue.
FirmwareVolume.UnDispatchedFfsDict is mutated during iteration,
convert the FirmwareVolume.UnDispatchedFfsDict.keys() to a new list
to resolve this problem.
Feng, Bob C [Mon, 25 Feb 2019 09:00:31 +0000 (17:00 +0800)]
BaseTools: Eot failed when enable python3
The Eot will report error when python3 enabled.
We replaced sdict with collections.OrderedDict in python3
patch set, but the sdict implement "append" method which is not
implemented in collections.OrderedDict.
Sami Mujawar [Tue, 19 Feb 2019 11:22:17 +0000 (11:22 +0000)]
DynamicTablesPkg: Remove GIC Distributor Id field
According to ACPI 6.2 Specification - Errata A, 'One,
and only one, GIC distributor structure must be present
in the MADT for an ARM based system'. Therefore,
the GIC Distributor ID field in the ACPI MADT GICD
substructure can be set to zero and there is no need
for the Configuration Manager to provide this information.
Update the CM_ARM_GICD_INFO structure to remove the GicId
field. Similarly update the MADT Generator to set the GicId
field in the GICD substructure to zero.
The DBG2_DEBUG_PORT_DDI() macro supports adding only one
Generic Base Address Register. Therefore, removed the
superfluous parameter NumReg and updated the macro to
use DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS which has
a value 1.
DynamicTableManagerDxe initialization fails if
gEdkiiDynamicTableFactoryProtocolGuid,
gEdkiiConfigurationManagerProtocolGuid and
gEfiAcpiTableProtocolGuid are not already available.
Consume PlatformBmPrintScLib, added earlier in this series. When
BdsDxe+UefiBootManagerLib report LoadImage() / StartImage() preparations
and return statuses, print the reports to the UEFI console. This allows
end-users better visibility into the boot process.
Laszlo Ersek [Wed, 20 Feb 2019 03:45:20 +0000 (04:45 +0100)]
ArmVirtPkg/ArmVirtQemu*: enable minimal Status Code Routing in DXE
The EFI_RETURN_STATUS_EXTENDED_DATA feature from PI-1.7
(<https://mantis.uefi.org/mantis/view.php?id=1885>) enables platform code
to learn about boot option failures (loading and launching) via status
codes reported by the UEFI Boot Manager.
In commit 59541d41633c, we removed all status code support from
ArmVirtPkg. Reenable that support now, minimally, just to the extent so we
can benefit from the PI-1.7 feature mentioned above:
(1) Include the ReportStatusCodeRouterRuntimeDxe driver.
This driver produces two protocols, EFI_STATUS_CODE_PROTOCOL and
EFI_RSC_HANDLER_PROTOCOL. The former allows DXE phase modules and
runtime modules to report (produce) status codes. The latter allows
the same types of modules to register callbacks for status code
handling (consumption).
(Handler registration occurs only at boot time. Status codes are
delivered to each handler at runtime as well, unless the handler is
unregistered at ExitBootServices().)
(2) Resolve ReportStatusCodeLib to a non-Null instance, for DXE_DRIVER
modules only. This way DXE_DRIVER modules that use the
REPORT_STATUS_CODE_EX() macro and friends will reach
EFI_STATUS_CODE_PROTOCOL from point (1).
(3) Set PcdReportStatusCodePropertyMask to 3 (the default value is 0).
This causes the REPORT_STATUS_CODE_EX() macro and friends to let
Progress Codes (bit#0) and Error Codes (bit#1) through to point (1).
Debug Codes (bit#2) are filtered out.
(4) Include no driver, for now, that registers any status code handler via
EFI_RSC_HANDLER_PROTOCOL, from point (1). Status codes that reach
ReportStatusCodeRouterRuntimeDxe will be thrown away.
(5) Modify only the ArmVirtQemu* platforms. A status code handler will
be added to "ArmVirtPkg/Library/PlatformBootManagerLib" in the next patch,
and this library instance is not consumed by ArmVirtXen.
Consume PlatformBmPrintScLib, added earlier in this series. When
BdsDxe+UefiBootManagerLib report LoadImage() / StartImage() preparations
and return statuses, print the reports to the UEFI console. This allows
end-users better visibility into the boot process.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Laszlo Ersek [Wed, 22 Nov 2017 20:37:07 +0000 (21:37 +0100)]
OvmfPkg: add library to track boot option loading/starting on the console
Introduce the Platform Boot Manager Print Status Code Library (for short,
PlatformBmPrintScLib) class for catching and printing the LoadImage() /
StartImage() preparations, and return statuses, that are reported by
UefiBootManagerLib.
In the primary library instance, catch only such status codes that
UefiBootManagerLib reports from the same module that contains
PlatformBmPrintScLib. The intent is to establish a reporting-printing
channel within BdsDxe, between UefiBootManagerLib and
PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
from UiApp's copy of UefiBootManagerLib.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Laszlo Ersek [Wed, 20 Feb 2019 02:31:28 +0000 (03:31 +0100)]
MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.
In the EFI_RETURN_STATUS_EXTENDED_DATA structure from PI-1.7, there may be
padding between the DataHeader and ReturnStatus members. The
REPORT_STATUS_CODE_EX() macro starts populating the structure immediately
after DataHeader, therefore the source data must provide for the padding.
Extract the BmReportLoadFailure() function from EfiBootManagerBoot(),
prepare a zero padding (if any) in a temporary
EFI_RETURN_STATUS_EXTENDED_DATA object, and fix the
REPORT_STATUS_CODE_EX() macro invocation.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Star Zeng <star.zeng@intel.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1539 Fixes: c2cf8720a5aad74230767a1f11bade2d86de3745
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
To avoid the confusion caused by function name,
rename EfiBootManagerGetNextFullDevicePath to
EfiBootManagerGetNextLoadOptionDevicePath.
As an API function should add EFIAPI prefix for this function.
Cc: Ray Ni <ray.ni@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chen A Chen <chen.a.chen@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Ray Ni <ray.ni@intel.com> Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chen A Chen <chen.a.chen@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Feng, Bob C [Tue, 19 Feb 2019 13:29:49 +0000 (21:29 +0800)]
BaseTools: Fix a bug about Structure PCD
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1535
If there is Hii Structure Pcd, build will fail, root cause is that
there is an incorrect variable access method used in code.
Fan, ZhijuX [Thu, 21 Feb 2019 01:33:55 +0000 (09:33 +0800)]
BaseTools:Build fail if define [DEPEX] in library inf
When define [DEPEX] in lib inf to build, it will fail and report"
gUefiOvmfPkgTokenSpaceGuid.test1 used in [Depex] section should be
used as FixedAtBuild type and VOID* datum type in the module."
But we define this PCD to FixedAtBuild type and VOID* datum type indeed.
1) The GenC tool does not include the constructor/destructor for
USER_DEFINED module. It should be included.
Only constructor/destructor with BASE type is included here.
The constructor/destructor with PEI/DXE/SMM type is still excluded
to keep original behavior.
2) The GenC tool includes the UnloadImage code for BASE module.
It should NOT be included.
3) The GenC tool uses EFI_STATUS and ASSERT_EFI_ERROR for BASE type.
It should use RETURN_STATUS and ASSERT_RETURN_ERROR.
4) The GenC tool miss DebugLib.h for BASE or USER_DEFINED module
AutoGen.c. Only Base.h is there. It should add Library/DebugLib.h.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Implement a runtime library instance of ResetSystemLib. It would
use a internal point instead of gRT and convert it depend on
gEfiEventVirtualAddressChangeGuid.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Change the function name form ResetSystem to RuntimeServiceResetSystem.
Because ResetSystem and EfiResetSystem would be used in ResetSystemLib
and RuntimeLib.
This commit will add the 'Security feature set' support for ATA devices.
According to the AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS)
specification, the Security feature set is an optional feature. In
summary, the feature is a password system that restricts access to user
data stored on an ATA device. A more detailed introduction of this feature
can be referred from the ATA8-ACS spec.
The HddPassword driver is composed of 2 parts:
* A DXE driver and
* A PEI driver
The DXE driver consumes EFI_ATA_PASS_THRU_PROTOCOL instances and installs
an HII GUI to manage the devices. If the managing device supports Security
feature set, the HII page will provide the user with the ability to
set/update/disable the password for this device. Also, if a password is
being set via the Security feature set, a popup window will show during
boot requesting the user to input password.
Another feature supported by this driver is that for those managing
devices with password set, they will be automatically unlocked during the
S3 resume. This is done by the co-work of the DXE driver and the PEI
driver:
The DXE driver will save the password and the identification information
for these devices into a LockBox, which is only allowed to restore during
S3 resume.
The PEI driver, during S3 resume, will restore the content in the LockBox
and will consume EDKII_PEI_ATA_PASS_THRU_PPI instances to unlock devices.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
For the current implementation of OpalPassword drivers, it has a feature
to support devices being automatically unlocked in the S3 resume. For this
feature, two types of devices are supported:
* ATA hard disks working under AHCI mode
* NVM Express devices
The support of this feature requires the above 2 types of device to be
initialized at the PEI phase during S3 resume, which is done by the
co-work of the OpalPasswordDxe driver and the OpalPasswordPei driver.
More specifically, the OpalPasswordDxe will handle:
* Pre-allocate MMIO resource and save it in a driver internal LockBox for
OpalPasswordPei to retrieve;
* Save the PCI configuration space of ATA controllers into boot script.
Meanwhile, the OpalPasswordPei will handle:
* Rely on the boot script for the PCI configuration space program of ATA
controllers;
* Restore the driver internal LockBox to get the MMIO resource;
* Complete the PCI configuration space program for ATA and NVME
controllers;
* Initialize ATA and NVME controllers and devices.
This commit will remove these hardware initialization related codes from
the OpalPassword drivers. The hardware initialization will be covered by
PEI storage device drivers (e.g. NvmExpressPei & AhciPei in the
MdeModulePkg).
After such codes removal, the OpalPasswordDxe will only handle:
* Construct/update the S3StorageDeviceInitList LockBox with the managing
ATA and NVME devices.
And the OpalPasswordPei will only handle:
* Locate Storage Security Command PPI instances to perform the device
automatic unlock during the S3 resume.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
This commit will add the support to enlarge a LockBox when using the
LockBoxLib API UpdateLockBox().
Please note that the new support will ONLY work for LockBox with attribute
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY set.
The functional uni-test for the commit is available at:
https://github.com/hwu25/edk2/tree/lockbox_unitest
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Hao Wu [Mon, 24 Dec 2018 06:49:01 +0000 (14:49 +0800)]
MdeModulePkg/SmmLockBox(PEI): Remove an ASSERT in RestoreLockBox()
This commit is out of the scope for BZ-1409. It is a refinement for the
PEI library instance within SmmLockBoxLib.
For the below ASSERT statement within function RestoreLockBox():
Status = SmmCommunicationPpi->Communicate (
SmmCommunicationPpi,
&CommBuffer[0],
&CommSize
);
if (Status == EFI_NOT_STARTED) {
//
// Pei SMM communication not ready yet, so we access SMRAM directly
//
DEBUG ((DEBUG_INFO, "SmmLockBoxPeiLib Communicate - (%r)\n", Status));
Status = InternalRestoreLockBoxFromSmram (Guid, Buffer, Length);
LockBoxParameterRestore->Header.ReturnStatus = (UINT64)Status;
if (Length != NULL) {
LockBoxParameterRestore->Length = (UINT64)*Length;
}
}
ASSERT_EFI_ERROR (Status);
It is possible for previous codes to return an error status that is
possible for happen. One example is that, when the 'if' statement
'if (Status == EFI_NOT_STARTED) {' is entered, function
InternalRestoreLockBoxFromSmram() is possible to return 'BUFFER_TOO_SMALL'
if the caller of RestoreLockBox() provides a buffer that is too small to
hold the content of LockBox.
Thus, this commit will remove the ASSERT here.
Please note that the current implementation of RestoreLockBox() is
handling the above-mentioned error case properly, so no additional error
handling codes are needed here.
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Hao Wu [Mon, 3 Dec 2018 08:31:23 +0000 (16:31 +0800)]
MdeModulePkg/SmmLockBoxLib: Use 'DEBUG_' prefix instead of 'EFI_D_'
This commit is out of the scope for BZ-1409. It is a coding style
refinement for the SmmLockBoxLib.
More specifically, the commit will remove all the debug message display
level macros starting with 'EFI_D_' and replace them with macros starting
with 'DEBUG_'.
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
This commit will add the AHCI mode ATA device support in the PEI phase.
More specifically, the newly add AhciPei driver will consume the ATA AHCI
host controller PPI for ATA controllers working under AHCI code within the
system. And then produces the below PPIs for each controller:
EDKII PEI ATA PassThru PPI
Storage Security Command PPI
Also, the driver will consume the S3StorageDeviceInitList LockBox in S3
phase. The purpose is to perform an on-demand (partial) ATA device
enumeration/initialization on each controller to benefit the S3 resume
performance.
The implementation of this driver is currently based on the below
specifications:
Serial ATA Revision 2.6
Serial ATA Advanced Host Controller Interface (AHCI) 1.3.1
AT Attachment with Packet Interface - 6 (ATA/ATAPI-6)
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
For the NvmExpressPei driver, this commit will update the driver to
consume the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to
perform an on-demand (partial) NVM Express device
enumeration/initialization to benefit the S3 resume performance.
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
For the NvmExpressPei driver, this commit will add codes to produce the
Storage Security Command PPI if the underlying NVM Express controller
supports the Security Send and Security Receive commands.
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Hao Wu [Mon, 27 Aug 2018 08:51:45 +0000 (16:51 +0800)]
MdeModulePkg/NvmExpressPei: Avoid updating the module-level variable
This commit is out of the scope for BZ-1409. The commit will remove the
call of RegisterForShadow() at the entry point of the driver. By doing so,
the driver is now possible to be executed without being re-loaded into
permanent memory.
Thus, this commit will update the NvmExpressPei driver to avoid updating
the content of a global variable.
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
This commit will add the GUID definitions for LockBox which is used to
save a list of storage devices that need to get initialized during the S3
resume.
The content of the LockBox will be a DevicePath structure that contains
zero or more DevicePath instances. Each instance denotes a storage device
that needs to get initialized during the S3 resume.
The producers of the content of this LockBox will be drivers like
OpalPassword DXE driver. This kind of drivers requires some specific
storage devices to be initialized during the PEI phase of in S3 resume.
(For the OpalPassword case, it requires the managing devices to be
automatically unlocked during the S3 resume).
The attribute of the LockBox should be set to
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY.
The consumers of the content of this LockBox will be PEI storage device
controller/bus drivers (e.g. NvmExpressPei) during S3 resume. This kind of
drivers can use the DevicePath instances stored in the LockBox to get a
list of devices that need to get initialized. In such way, an on-demand
(partial) device enumeration/initialization can be performed to benefit
the S3 resume performance.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
This commit will add the definitions for Storage Security Command (SSC)
PPI. This PPI will be be used to abstract mass storage devices to allow
code running in the PEI phase to send security protocol commands to mass
storage devices without specific knowledge of the type of device or
controller that manages the device.
More specifically, the PPI will provide services to:
* Get the number of mass storage devices managed by a instance of the SSC
PPI (by service 'GetNumberofDevices');
* Get the identification information (DevicePath) of a managing mass
storage devices (by service 'GetDevicePath');
* Send security protocol commands to mass storage devices (by services
'ReceiveData' and 'SendData').
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
This commit will add the definitions for EDKII PEI ATA PassThru PPI. This
PPI will provide services that allow ATA commands to be sent to ATA
devices attached to an ATA controller in the PEI phase.
More specifically, the PPI will provide services to:
* Send ATA commands to an ATA device (by service 'PassThru');
* Get the list of the attached ATA device on a controller (by services
'GetNextPort' and 'GetNextDevice');
* Get the identification information (DevicePath) of the underlying ATA
host controller (by service 'GetDevicePath').
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
projects / mirror_edk2.git / log