Qin Long [Thu, 23 Mar 2017 12:19:39 +0000 (20:19 +0800)]
CryptoPkg: Clean-up CRT Library Wrapper.
Cleaning-up CRT Library Wrapper for the third-party cryptography
library building. The changes includes
1. Rename OpenSslSupport.h to CrtLibSupport.h for future alternative
crypto provider support.
2. Remove all un-referenced CRT APIs and headers.
(NOTE: More cleans-up could be possible after OpenSSL integrate the
extra PR request: https://github.com/openssl/openssl/pull/2961)
Cc: Ting Ye <ting.ye@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qin Long <qin.long@intel.com> Reviewed-by: Ting Ye <ting.ye@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com>
Qin Long [Thu, 23 Mar 2017 12:09:17 +0000 (20:09 +0800)]
CryptoPkg: Fix handling of &strcmp function pointers
In a couple of places, OpenSSL code uses the address of the
strcmp() function, and assigns it to another comparator function
pointer.
Unfortunately, this falls foul of the inconsistent function ABI
that we use in EDKII. We '#define strcmp AsciiStrCmp' but AsciiStrCmp
is an EFIAPI function with the Microsoft ABI. And we're assigning its
address to a non-EFIAPI function, which may well have a different ABI.
Fix this by providing an actual strcmp() function in the default ABI.
We already *had* a prototype for it in OpenSslSupport.h, which was
then superseded by the #define strcmp AsciiStrCmp.
Now, OpenSSL code *can* use &strcmp without problems.
Cc: Ting Ye <ting.ye@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Qin Long <qin.long@intel.com> Reviewed-by: Ting Ye <ting.ye@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com>
Qin Long [Thu, 23 Mar 2017 12:06:00 +0000 (20:06 +0800)]
CryptoPkg/OpensslLib: Add new OpenSSL-HOWTO document.
Add one new OpenSSL-HOWTO.txt to introduce how to clone / download
the latest OpenSSL release source for build.
ALso update buildinf.h to reflect the latest update time.
Cc: Ting Ye <ting.ye@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Qin Long <qin.long@intel.com> Reviewed-by: Ting Ye <ting.ye@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com>
Qin Long [Thu, 23 Mar 2017 11:37:00 +0000 (19:37 +0800)]
CryptoPkg/OpensslLib: Add new Perl script for file list generation.
OpenSSL-1.1.0xx configure mechanism was updated with new configdata.
This patch update process_file.sh script to new Perl-based script for
auto generation of file list and openssl config file (opensslconf.h).
This only needs to be done once by a developer when updating to a new
version of OpenSSL (or changing options, etc.). Normal users do not
need to do this, since the results are already stored in the EDK2 git
repository.
Cc: Ting Ye <ting.ye@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Qin Long <qin.long@intel.com> Reviewed-by: Ting Ye <ting.ye@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
Qin Long [Thu, 23 Mar 2017 08:21:31 +0000 (16:21 +0800)]
CryptoPkg: Update .gitignore for OpenSSL source masking
Updates .gitignore that masks the OpenSSL source:
1. Remove "Include/openssl" from .gitignore since we needn't duplicate
openssl headers now
2. Update "openssl-*" to "openssl*", since we use "openssl" instead of
"openssl-x.x.xx" as main source directory.
Cc: Ting Ye <ting.ye@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qin Long <qin.long@intel.com> Reviewed-by: Ting Ye <ting.ye@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
Qin Long [Thu, 23 Mar 2017 08:14:16 +0000 (16:14 +0800)]
CryptoPkg/OpensslLib: Update INF files to support OpenSSL-1.1.0x build
Update OpensslLib INF files to support OpenSSL-1.1.0x source build.
The file list was generated from the latest OpenSSL-1.1.0e release.
Main changes to support OpensslLib build in this patch include:
1. Use "openssl" instead of "openssl-x.x.xx" as main source directory,
Also update include path in CryptoPkg.dec
2. Enable warnings in GCC builds;
3. Update Visual Studio build options to silence current possible build
warnings.
4. Move the default opensslconf.h to Include/openssl, and add one dummy
dso_conf.h for native UEFI build.
The OpensslLib module build was validated as
build -t VSXXXX -a XX -p CryptoPkg/CryptoPkg.dsc
-m CryptoPkg/Library/OpensslLib/OpensslLib.inf
(NOTE: The extra build options for ARM/RVCT/XCODE were kept, which expect
further optimizations from community)
Cc: Ting Ye <ting.ye@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Ronald Cron <ronald.cron@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Qin Long <qin.long@intel.com> Reviewed-by: Ting Ye <ting.ye@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com>
Ard Biesheuvel [Mon, 27 Mar 2017 09:57:31 +0000 (10:57 +0100)]
EmbeddedPkg: add DT platform driver to select between DT and ACPI
As a follow up to the changes proposed by Laszlo to make ACPI and DT
mutually exclusive on ArmVirtQemu, this patch proposes a DT platform
DXE driver that either installs the NULL protocol PlatformHasAcpiGuid,
or installs the FV embedded DTB binary as a configuration table under
the appropriate GUID, depending on a preference setting recorded as
a UEFI variable, and configurable via a HII screen.
The DTB binary can be embedded in the firmware image by adding the
following to the platform .fdf file:
FILE FREEFORM = 25462CDA-221F-47DF-AC1D-259CFAA4E326 {
SECTION RAW = SomePkg/path/to/foo.dtb
}
Laszlo Ersek [Fri, 17 Mar 2017 16:50:24 +0000 (17:50 +0100)]
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI
This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
the guest. Showing both is never needed (it is actually detrimental to the
adoption of standards, such as SBSA / SBBR).
* Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)
> Found FwCfg @ 0x9020008/0x9020000
> Found FwCfg DMA @ 0x9020010
> InstallProtocolInterface: [EdkiiPlatformHasAcpi] 0
plus the usual messages. Later the guest kernel logs
In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches no files, while the "/sys/firmware/acpi/tables/*" pattern matches
the ACPI tables.
* With "-no-acpi", the firmware logs:
> PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000
> PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010
> PlatformHasAcpiDtDxe | InstallProtocolInterface:
> PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTree] 0
> FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @
> FdtClientDxe | 0x13FFBF000 to OS
> ...
> DXE_CORE | Driver [AcpiTableDxe] was discovered but not
> DXE_CORE | loaded!!
> DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but
> DXE_CORE | not loaded!!
> ...
> RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI
> RamDiskDxe | Table Protocol, unable to publish RAM disks to
> RamDiskDxe | NFIT.
(BootGraphicsResourceTableDxe's ReadyToBoot callback --
InstallBootGraphicsResourceTable() -- handles the lack of
EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs
In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches the directory "/sys/firmware/devicetree/base", which contains a
large number of DT nodes, while the "/sys/firmware/acpi/tables/*" pattern
matches no files.
Laszlo Ersek [Fri, 17 Mar 2017 15:56:04 +0000 (16:56 +0100)]
ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol notify
Replace the dependency on PcdPureAcpiBoot with a Platform Has Device Tree
notification callback. Move the sysconfig table installation from the
entry point function to the callback.
Laszlo Ersek [Fri, 17 Mar 2017 14:46:40 +0000 (15:46 +0100)]
ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically
In this patch, the ACPI protocol / driver chain is enabled dynamically,
when appropriate. This is being done in one larger patch, because
ArmVirt.dsc.inc, where AcpiTableDxe is built, is used by all the platform
DSCs.
No change in behavior should be observable after this patch on any
ArmVirtPkg platform.
Laszlo Ersek [Fri, 17 Mar 2017 14:12:28 +0000 (15:12 +0100)]
ArmVirtPkg: add XenPlatformHasAcpiDtDxe
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on Xen,
according to ARM vs. AARCH64. At this point it differs from the QEMU
driver PlatformHasAcpiDtDxe in that this one always installs the DT.
Laszlo Ersek [Fri, 17 Mar 2017 14:12:28 +0000 (15:12 +0100)]
ArmVirtPkg: add PlatformHasAcpiDtDxe
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on QEMU,
according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot.
Laszlo Ersek [Fri, 17 Mar 2017 12:47:35 +0000 (13:47 +0100)]
EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID
The presence of this GUID in the PPI database, and/or in the DXE protocol
database (as dictated by the platform's needs in these firmware phases)
implies that the platform provides the operating system with a Device
Tree-based hardware description. This is not necessarily exclusive with
other types of hardware description (for example, an ACPI-based one).
A platform PEIM and/or DXE driver is supposed to produce a single instance
of the PPI and/or protocol (with NULL contents), if appropriate. The
decision to produce the PPI and/or protocol is platform specific; for
example, in the DXE phase, it could depend on an HII checkbox / underlying
non-volatile UEFI variable.
In the DXE phase, the protocol is meant to be consumed by the platform
driver that
- owns the Device Tree description of the hardware, and
- is responsible for installing it as a system configuration table.
Said FDT-owner driver can wait for the protocol via DEPEX or protocol
notify.
Because this GUID is not standard, it is prefixed with EDKII / Edkii, as
seen elsewhere (for example in MdeModulePkg and SecurityPkg).
Laszlo Ersek [Fri, 17 Mar 2017 12:47:35 +0000 (13:47 +0100)]
EmbeddedPkg: introduce PlatformHasAcpiLib
Add the shorter-term library instance outlined in the previous patch to
EmbeddedPkg, so that we can imbue AcpiTableDxe with a protocol dependency
on EDKII_PLATFORM_HAS_ACPI_GUID.
Laszlo Ersek [Fri, 17 Mar 2017 12:47:35 +0000 (13:47 +0100)]
EmbeddedPkg: introduce EDKII Platform Has ACPI GUID
The presence of this GUID in the PPI database, and/or in the DXE protocol
database (as dictated by the platform's needs in these firmware phases)
implies that the platform provides the operating system with an ACPI-based
hardware description. This is not necessarily exclusive with other types
of hardware description (for example, a Device Tree-based one).
A platform PEIM and/or DXE driver is supposed to produce a single instance
of the PPI and/or protocol (with NULL contents), if appropriate. The
decision to produce the PPI and/or protocol is platform specific; for
example, in the DXE phase, it could depend on an HII checkbox / underlying
non-volatile UEFI variable.
In the DXE phase, the protocol is meant to be depended-upon by
"MdeModulePkg/Universal/Acpi/AcpiTableDxe", indirectly:
* In the long term, interested platforms will establish this dependency by
hooking an (upcoming) NULL-class DepexLib instance into AcpiTableDxe in
their DSC files, pointing DepexLib's DEPEX through a FixedAtBuild PCD to
the GUID introduced here. (For the prerequisite BaseTools feature, refer
to <https://bugzilla.tianocore.org/show_bug.cgi?id=443>).
* In the short term, an interested platform may hook a private NULL-class
library instance (called e.g. "PlatformHasAcpiLib") into AcpiTableDxe.
Such a library instance would be a specialization of the above described
generic DepexLib, with the DEPEX open-coded on the GUID introduced here.
Either way, the platform makes EFI_ACPI_TABLE_PROTOCOL and (if enabled)
EFI_ACPI_SDT_PROTOCOL dependent on the platform's dynamic decision to
produce or not to produce a NULL protocol instance with this GUID.
In turn, other (platform and universal) DXE drivers that produce ACPI
tables will wait for EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL, via
DEPEX, protocol notify, or a simple gBS->LocateProtocol() in a "late
enough" callback (such as Ready To Boot).
Because this GUID is not standard, it is prefixed with EDKII / Edkii, as
seen elsewhere in MdeModulePkg and SecurityPkg. In addition, an effort is
made to avoid the phrase "AcpiPlatform", as that belongs to drivers /
libraries that produce platform specific ACPI content (as opposed to
deciding whether the entire firmware will have access to
EFI_ACPI_TABLE_PROTOCOL, or any similar facilities in the PEI phase).
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
Jeff Fan [Mon, 27 Mar 2017 07:00:00 +0000 (15:00 +0800)]
UefiCpuPkg/MpLib.c: Add checking CR0 PG bit
If CR0 PG bit is not set, it means paging is not enabled on BSP. Thus, Execute
Disable feature is not working actually. Thus, we cannot enable it on APs.
v2:
Correct the commit log.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Ard Biesheuvel [Wed, 15 Mar 2017 16:26:41 +0000 (16:26 +0000)]
ArmPkg/ArmExceptionLib: use EL0 stack for synchronous exceptions
In order to be able to produce meaningful diagnostic output when taking
synchronous exceptions that have been caused by corruption of the stack
pointer, prepare the EL0 stack pointer and switch to it when handling the
'Sync exception using SPx' exception class.
Jeff Fan [Thu, 23 Mar 2017 05:19:49 +0000 (13:19 +0800)]
UefiCpuPkg/AcpiCpuData.h: Support >4GB MMIO address
The current CPU_REGISTER_TABLE_ENTRY structure only defined UINT32 Index to
indicate MSR/MMIO address. It's ok for MSR because MSR address is UINT32 type
actually. But for MMIO address, UINT32 limits MMIO address exceeds 4GB.
This update on CPU_REGISTER_TABLE_ENTRY is to add additional UINT32 field
HighIndex to indicate the high 32bit MMIO address and original Index still
indicate the low 32bit MMIO address.
This update makes use of original padding space between ValidBitLength and
Value to add HighIndex.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Jeff Fan [Thu, 23 Mar 2017 04:55:26 +0000 (12:55 +0800)]
UefiCpuPkg/RegisterCpuFeaturesLib: Define Index to UINT64
The input parameter Index of PreSmmCpuRegisterTableWrite() and
CpuRegisterTableWrite() is defined as UINT32. Index is MSR/MMIO address that
will be saved in CPU register table. UINT32 blocks the MMIO address > 4GB.
This fix is to define Index to UINT64 instead of UINT32.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Derek Lin [Fri, 24 Feb 2017 07:26:19 +0000 (15:26 +0800)]
BaseTools: Skip module AutoGen by comparing timestamp.
[Introduction]
The BaseTool Build.py AutoGen parse INF meta-file and generate
AutoGen.c/AutoGen.h/makefile. When we only change .c .h code, the
AutoGen might be not necessary, but Build.py spend a lot of time on it.
There's a -u flag to skip all module's AutoGen. In my environment, it save
35%~50% of time in rebuild a ROM.
However, if user change one .INF meta-file, then -u flag is not available.
[Idea]
AutoGen can compare meta-file's timestamp and decide if the module's
AutoGen can be skipped. With this, when a module's INF is changed, we
only run this module's AutoGen, we don't need to run other module's.
[Implementation]
In the end of a module's AutoGen, we create a AutoGenTimeStamp.
The file save a file list that related to this module's AutoGen.
In other word, the file list in AutoGenTimeStamp is INPUT files of
module AutoGen, AutoGenTimeStamp file is OUTPUT.
During rebuild, we compare time stamp between INPUT and OUTPUT, and
decide if we can skip it.
Below is the Input/Output of a module's AutoGen.
[Input]
1. All the DSC/DEC/FDF used by the platform.
2. Macro and PCD defined by Build Options such as "build -D AAA=TRUE
--pcd BbbPcd=0".
3. INF file of a module.
4. Source files of a module, list in [Sources] section of INF.
5. All the library link by the module.
6. All the .h files included by the module's sources.
This patch save my build time. When I make a change without touching
DSC/DEC/FDF, it is absolutely much faster than original rebuild,
35%~50% time saving in my environment
(compare to original tool rebuild time).
If I change any DSC/DEC/FDF, there's no performance improve, because it
can't skip any module's AutoGen.
Please note that if your environment will generate DSC/FDF during prebuild,
it will not skip any AutoGen because of DSC timestamp is changed. This will
require prebuild script not to update metafile when content is not changed.
Ruiyu Ni [Thu, 23 Mar 2017 05:09:45 +0000 (13:09 +0800)]
MdePkg/DevicePathLib: Fix FromText bug for multi-instance devicepath
UefiDevicePathLibConvertTextToDevicePath correctly detects when it
has hit a ',' splicing together multiple paths. However, the code
that tries to cope with it:
{code}
if (IsInstanceEnd) {
DeviceNode = (EFI_DEVICE_PATH_PROTOCOL *) AllocatePool (
END_DEVICE_PATH_LENGTH);
ASSERT (DeviceNode != NULL);
SetDevicePathEndNode (DeviceNode);
NewDevicePath = AppendDevicePathNode (DevicePath, DeviceNode);
FreePool (DevicePath);
FreePool (DeviceNode);
DevicePath = NewDevicePath;
}
{code}
causes a problem. The END node that's appended it the node for the
entire list. So when the node is appended in AppendDevicePathNode,
it winds up disappearing. This leads to the path
'PciRoot(0x0),PciRoot(0x0)' parsing as if 'PciRoot(0x0)/PciRoot(0x0)'
were specified. These are two very different things.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Warner Losh <imp@bsdimp.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Chen A Chen [Thu, 16 Mar 2017 05:22:40 +0000 (13:22 +0800)]
ShellPkg: Add Shell invocation option '-exit'
According to Shell spec 2.2 '-exit' invocation option is used to specify
that after running the command line when launched, the UEFI Shell must
immediately exit.
Jiaxin Wu [Wed, 22 Mar 2017 01:22:07 +0000 (09:22 +0800)]
NetworkPkg/IScsiDxe: Fix the incorrect error handling in DriverEntryPoint
Currently, error handling in IScsiDriverEntryPoint is incorrect. For
example, if IScsiCreateAttempts() return error due to the limited max
variable size, iSCSI will not unload the configuration entries.
Jeff Fan [Thu, 23 Mar 2017 01:37:47 +0000 (09:37 +0800)]
UefiCpuPkg/RegisterCpuFeaturesLib: Set CpuFeatureEntry initial value
CpuFeatureEntry will be set before using it. But VS2012 build reported the build
warning "potentially uninitialized local variable 'CpuFeatureEntry' used".
This fix is to set CpuFeatureEntry initial value and add ASSERT check later.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Ard Biesheuvel [Thu, 16 Mar 2017 13:23:42 +0000 (13:23 +0000)]
ArmPkg/DefaultExceptionHandlerLib: walk call stack unconditionally
Currently, we only attempt to walk the call stack and print a backtrace
if the program counter refers to a location covered by a PE/COFF image.
However, regardless of the value of PC, the frame pointer may still have
a meaningful value, and so we can still produce the remainder of the
backtrace.
Ard Biesheuvel [Sat, 18 Mar 2017 21:20:46 +0000 (21:20 +0000)]
ArmPkg/PlatformBootManagerLib: move to BootLogoLib for boot splash support
Replace the duplicated and outdated code in QuietBoot.c with a reference
to BootLogoLib, which provides the same functionality. This also allows
us to drop all references to IntelFrameworkModulePkg in this module.
Ard Biesheuvel [Wed, 22 Mar 2017 13:49:24 +0000 (13:49 +0000)]
ArmVirtPkg/ArmVirtQemu: refer to Shell app via its declared GUID
Currently, the file GUID reference of the UEFI Shell app is indirected
via the PCD gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile,
which is set to a fixed value for our platforms.
So instead, use the new symbolic GUID added for this purpose, and drop
the reference to this PCD, and to the IntelFrameworkModulePkg package
entirely.
Ard Biesheuvel [Sat, 18 Mar 2017 21:18:42 +0000 (21:18 +0000)]
ArmPkg/PlatformBootManagerLib: refer to Shell FILE_GUID directly
Instead of indirecting the reference to the Shell binary via a PCD
that is defined in IntelFrameworkModulePkg, and which invariably
gets set to the same value by all users of this library, refer to
the UEFI Shell application by its declared symbolic GUID.
Ard Biesheuvel [Wed, 22 Mar 2017 13:34:13 +0000 (13:34 +0000)]
ShellPkg: add GUID declaration for FILE_GUID of UEFI Shell app to package
In QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c,
there is a definition of mUefiShellFileGuid which is a constant reference
to the FILE_GUID as defined in ShellPkg/Application/Shell/Shell.inf.
To prevent the need for duplicating it to other modules, promote it to
a proper global GUID, and add it to the ShellPkg.dec package declaration.
Jeff Fan [Tue, 7 Mar 2017 08:56:15 +0000 (16:56 +0800)]
UefiCpuPkg: Add NULL CPU Common Features Library instance
This NULL CPU common Features Library instance will register some CPU features
defined in Intel(R) 64 and IA-32 Architectures Software Developer's Manual,
Volume 3, September 2016, Chapter 35 Model-Specific-Registers (MSR).
Add PCD PcdCpuClockModulationDutyCycle and PcdIsPowerOnReset consumed by NULL
CPU Common Features Library instance.
v2:
1. Using MSR_IA32_EFER to enable/disable NX feature instead of using
MSR_IA32_MISC_ENABLE.
2. Fix bug that SMX and VMX feature is swapped.
v3:
1. Add AesniGetConfigData() to get current register state.
v5:
Move MSR reading from AesniGetConfigData() to AesniSupport().
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Jeff Fan [Tue, 7 Mar 2017 08:49:35 +0000 (16:49 +0800)]
UefiCpuPkg: Add PEI/DXE Register CPU Features Library instances
PEI Register CPU Features Library instance is used to register/manager/program
CPU features on PEI phase.
DXE Register CPU Features Library instance is used to register/manager/program
CPU features on DXE phase.
v2:
Format debug messages.
v3:
Trim white space at end of line.
v4:
Remove unused local variable.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Jeff Fan [Tue, 7 Mar 2017 08:35:40 +0000 (16:35 +0800)]
UefiCpuPkg/Include/Library: Add Register CPU Features Library
Register CPU Features Library is used to register/manage/program CPU features.
NULL CPU features library instance could consume it register CPU features
functions.
CPU Feature module could consume this library to detect/analysis/program CPU
features on BSP/APs.
v4:
Fix GCC build issue.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
GUID gEdkiiCpuFeaturesInitDoneGuid is used to indicate if CPU features have been
initialized.
On PEI phase, one gEdkiiCpuFeaturesInitDoneGuid PPI will be installed after CPU
features initialized.
On DXE phase, one gEdkiiCpuFeaturesInitDoneGuid Protocol will be installed after
CPU features initialized.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Jeff Fan [Tue, 7 Mar 2017 07:59:22 +0000 (15:59 +0800)]
UefiCpuPkg: Add GUID gEdkiiCpuFeaturesSetDoneGuid
GUID gEdkiiCpuFeaturesSetDoneGuid is used to indicate if CPU feature related
setting are set finished. For example, PCD PcdCpuFeaturesUserConfiguration.
On PEI phase, one gEdkiiCpuFeaturesSetDoneGuid PPI will be installed after
platform set CPU feature setting.
On DXE phase, one gEdkiiCpuFeaturesSetDoneGuid Protocol will be installed after
platform set CPU feature setting.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Jeff Fan [Tue, 7 Mar 2017 03:14:35 +0000 (11:14 +0800)]
UefiCpuPkg/Msr: Add CPUID signature check MACROs
All model-specific MSRs are related to processor signatures that are defined in
each section in Chapter 35 Model-Specific-Registers (MSR), Intel(R) 64 and
IA-32 Architectures Software Developer's Manual, Volume 3, September 2016.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Jeff Fan [Tue, 7 Mar 2017 11:39:27 +0000 (19:39 +0800)]
UefiCpuPkg/CpuS3DataDxe: Consume the existing PcdCpuS3DataAddress
If PCD PcdCpuS3DataAddress is set before, CpuS3DataDxe should get RegisterTable
and PreSmmRegisterTable from existing PCD pointed buffer and needn't to allocate
new buffer for RegisterTable and PreSmmRegisterTable.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Jeff Fan [Tue, 7 Mar 2017 06:32:28 +0000 (14:32 +0800)]
UefiCpuPkg/AcpiCpuData: Update RegisterTableEntry type
Current RegisterTableEntry filed in CPU_REGISTER_TABLE is one pointer to
CPU_REGISTER_TABLE_ENTRY. If CPU register table wants to be passed from 32bit
PEI to x64 DXE/SMM, x64 DXE/SMM cannot get the correct RegisterTableEntry.
This update is to update RegisterTableEntry type to EFI_PHYSICAL_ADDRESS and
make RegisterTableEntry is fixed length.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Ard Biesheuvel [Tue, 21 Mar 2017 13:49:08 +0000 (13:49 +0000)]
MdeModulePkg/MemoryProtection: split protect and unprotect paths
Currently, the PE/COFF image memory protection code uses the same code
paths for protecting and unprotecting an image. This is strange, since
unprotecting an image involves a single call into the CPU arch protocol
to clear the permission attributes of the entire range, and there is no
need to parse the PE/COFF headers again.
So let's store the ImageRecord entries in a linked list, so we can find
it again at unprotect time, and simply clear the permissions.
Note that this fixes a DEBUG hang on an ASSERT() that occurs when the
PE/COFF image fails to load, which causes UnprotectUefiImage() to be
invoked before the image is fully loaded.
Ard Biesheuvel [Tue, 21 Mar 2017 09:12:56 +0000 (09:12 +0000)]
ArmVirtPkg/HighMemDxe: check new regions against GCD memory space map
Instead of looking at the PCD gArmTokenSpaceGuid.PcdSystemMemoryBase
to decide which DT node covers the memory we are already using, query
the GCD memory space map, which is the authoritative source for this
kind of information
This fixes a problem observed by Michael on platforms where this PCD
is of the 'Patchable' type, which means updates to its value do not
propagate to other modules.
Ard Biesheuvel [Tue, 21 Mar 2017 08:47:23 +0000 (08:47 +0000)]
ArmVirtPkg/HighMemDxe: use CPU arch protocol to apply memprotect policy
Instead of invoking gDS->SetMemorySpaceAttributes to set the EFI_MEMORY_XP
attribute on newly added regions, which is guaranteed to fail if the same
attribute was not declared as a capability of the region when it as added,
invoke the CPU arch protocol directly to set the EFI_MEMORY_XP attribute
if our memory protection policy demands it.
The BGRT table has an 8 byte field for the memory address of the image
data, and yet the driver explicitly allocates below 4 GB. This results
in an ASSERT() on systems that do not have any memory below 4 GB to begin
with.
Since neither the PI, the UEFI or the ACPI spec contain any mention of
why this data should reside below 4 GB, replace the allocation call
with an ordinary AllocatePages() call.
Ard Biesheuvel [Mon, 20 Mar 2017 14:51:36 +0000 (14:51 +0000)]
MdeModulePkg/AcpiTableDxe: consider version mask when removing tables
Invocations of EFI_ACPI_TABLE_PROTOCOL::UninstallAcpiTable() may
result in a crash when the value of PcdAcpiExposedTableVersions does
not include EFI_ACPI_TABLE_VERSION_1_0B.
The reason is that EFI_ACPI_TABLE_PROTOCOL::InstallAcpiTable() will
only populate the Rsdt1/Rsdt3 pointers when EFI_ACPI_TABLE_VERSION_1_0B
is set, whereas EFI_ACPI_TABLE_PROTOCOL::UninstallAcpiTable() will
invoke PublishTables with EFI_ACPI_TABLE_VERSION_1_0B alawys set,
resulting in a NULL pointer dereference of the Rsdt1/Rsdt3 pointers.
So take PcdAcpiExposedTableVersions into account for UninstallAcpiTable
as well.
Add -NR (no-reset) option support, once the option is specified,
no reset will be trigger for the capsule with flag
CAPSULE_FLAGS_PERSIST_ACROSS_RESET and no CAPSULE_FLAGS_INITIATE_RESET.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Xiaofeng Wang <winggundum82@163.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Suman Prakash [Mon, 20 Mar 2017 08:34:55 +0000 (16:34 +0800)]
MdeModulePkg/NvmExpressDxe: Memory leak fix in async code flow
For async commands, the buffer allocated for Prp list is
not getting freed, which will cause memory leak for async
read write command. For example testing async command flow
with custom application to send multiple read write commands
were resulting in decrease of available memory page in memmap,
which eventually resulted in system hang. Hence freeing
AsyncRequest->MapData, AsyncRequest->MapMeta, AsyncRequest->MapPrpList and
AsyncRequest->PrpListHost when async command is completed.
Laszlo Ersek [Mon, 20 Mar 2017 10:24:23 +0000 (11:24 +0100)]
MdeModulePkg/Core/Dxe: downgrade "CodeSegmentCount is 0" msg to DEBUG_WARN
UEFI executables that consist of a single read+write+exec PE/COFF section
trigger this message, but such a binary layout isn't actually an error.
The image can be launched alright, only image protection cannot be applied
to it fully.
One example that elicits the message is (some) Linux kernels (with the EFI
stub of course).
Laszlo Ersek [Fri, 17 Mar 2017 18:57:09 +0000 (19:57 +0100)]
MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback
function. If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not
found, then informational messages are logged, and the RAM disks are not
published to the (nonexistent) NFIT table.
The logic is fine, but the info messages are not concatenated correctly
from multiple string literals -- the second parts are passed as (unused)
arguments to DEBUG(). Fix the typos.
Ard Biesheuvel [Thu, 16 Mar 2017 11:35:28 +0000 (11:35 +0000)]
MdeModulePkg/DxeCore: deal with allocations spanning several memmap entries
When attempting to perform page allocations using AllocateAddress, we
fail to check whether the entire region is free before splitting the
region. This may lead to memory being leaked further into the routine,
when it turns out that one of the memory map entries intersected by the
region is already occupied. In this case, prior conversions are not rolled
back.
For instance, starting from this situation
0x000040000000-0x00004007ffff [ConventionalMemory ]
0x000040080000-0x00004009ffff [Boot Data ]
0x0000400a0000-0x000047ffffff [ConventionalMemory ]
a failed EfiLoaderData allocation @ 0x40000000 that covers the BootData
region will fail, but leave the first part of the allocation converted,
so we end up with
0x000040000000-0x00004007ffff [Loader Data ]
0x000040080000-0x00004009ffff [Boot Data ]
0x0000400a0000-0x000047ffffff [ConventionalMemory ]
even though the AllocatePages() call returned an error.
So let's check beforehand that AllocateAddress allocations are covered
by a single memory map entry, so that it either succeeds or fails
completely, rather than leaking allocations.
The architectural MSR MSR_IA32_MISC_ENABLE is not supported by AMD processors.
Because reading CPUID.80000001H:EDK[20] is enough to check if XD feature is
supported or not, we just remove checking MSR_IA32_MISC_ENABLE(0x1A0).
Cc: Anthony PERARD <anthony.perard@citrix.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Tested-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Star Zeng [Thu, 16 Mar 2017 07:26:03 +0000 (15:26 +0800)]
MdeModulePkg/AcpiTableDxe: Not make FADT.{DSDT,X_DSDT} mutual exclusion
198a46d768fb90d2f9b16e26451b4814e7469eaf improved the DSDT and X_DSDT
fields mutual exclusion by checking FADT revision, but that breaks
some OS that has assumption to only consume X_DSDT field even the
DSDT address is < 4G.
To have better compatibility, this patch is to update the code to not
make FADT.{DSDT,X_DSDT} mutual exclusion, but always set both DSDT and
X_DSDT fields in the FADT when the DSDT address is < 4G.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Jeff Fan <jeff.fan@intel.com>
Jeff Westfahl [Tue, 14 Mar 2017 21:02:01 +0000 (05:02 +0800)]
ShellPkg/HandleParsingLib: Correct format specifier for LoadedImage
The format specifier for the LoadOptions field of the LoadedImage protocol
is "%s". However, the data in LoadOptions is often generic binary data. A
format specifier of "%x" is more appropriate for this field.
Using "dh -v" with format specifier "%s" on BIOS images based on EDK II
source before commit 891d844 can cause a crash.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Ruiyu Ni [Thu, 16 Mar 2017 05:14:25 +0000 (13:14 +0800)]
MdeModulePkg/ConPlatform: Support GOP created as PCI's grandson
The original logic assumes GOP hande is son of PCI handle but it
is not always true.
Below wordings are from UEFI Spec:
If a graphics device supports multiple frame buffers, then
handles for the frame buffers must be created first, and then the
handles for the video output devices can be created as children of
the frame buffer handles.
So the GOP handle could be grandson of the PCI handle.
EfiBootManagerGetGopDevicePath(VideoController) is used to fix
this bug.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Zhang Lubo [Thu, 16 Mar 2017 09:52:51 +0000 (17:52 +0800)]
NetworkPkg: Fix service binding issue in TCP dxe.
v2: Handle error case in SockCreateChild and fix typo issue
when we destroy the socket Sock and its associated
protocol control block, we need to first close the
parent protocol, then remove the protocol from childHandle
and last to free any data structures that allocated in
CreateChild. But currently, we free the socket data (Socket ConfigureState)
before removing the protocol form the childhandle. So if the up layer
perform the driverbing stop to abort tcp session and send the tcp reset
packet, it will failed.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo <lubo.zhang@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Zhang Lubo [Thu, 16 Mar 2017 10:03:36 +0000 (18:03 +0800)]
MdeModulePkg: Fix service binding issue in TCP4 and Ip4 dxe.
v2: Handle error case in SockCreateChild and fix typo issue
when we destroy the socket Sock and its associated
protocol control block, we need to first close the
parent protocol, then remove the protocol from childHandle
and last to free any data structures that allocated in
CreateChild. But currently, we free the socket data
(Socket ConfigureState) before removing the protocol
form the childhandle. So if the up layer want to send the
tcp reset packet in it's driver binding stop function, it will failed.
The IpInstance destroy state is redundant and may cause
ip transmit failed if up layer want to send ip packet.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo <lubo.zhang@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Jiaxin Wu [Thu, 16 Mar 2017 01:39:34 +0000 (09:39 +0800)]
MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for Ip4Config2
v2:
* Add the check in Ip4Config2SetDefaultIf to avoid the DHCP configuration
case.
Ip4config2 doesn't check the validity of Ip/Netmask pair, which
leads to the invalid combination of Ip and Netmask setting.
This patch is to resolve the issue.
Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Cc: Subramanian Sriram <sriram-s@hpe.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Sriram Subramanian <sriram-s@hpe.com> Reviewed-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
IntelFsp2Pkg: Raise exception for invalid BSF option
Raise exception for invalid BSF option in GenCfgOpt.py
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Richard Thomaiyar <richard.marian.thomaiyar@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
projects / mirror_edk2.git / log