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>
Star Zeng [Tue, 28 Feb 2017 04:48:39 +0000 (12:48 +0800)]
MdeModulePkg PCD: Allow SkuId to be changed only once
Current PI spec has no clear description about whether the
SkuId could be changed multiple times or not during one boot.
If the SkuId could be changed multiple times during one boot,
different modules may get inconsistent PCD values.
And DynamicHii PCD maps to UEFI variable, once one DynamicHii
PCD(UEFI variable) is set for one SkuId, then the PCD value
will be always from UEFI variable but not PCD database, even
the SkuId is set to other value.
This patch is to update PCD drivers to allow SkuId to be
changed only once during one boot.
Ard Biesheuvel [Tue, 14 Mar 2017 19:52:11 +0000 (19:52 +0000)]
ArmPkg/UncachedMemoryAllocationLib: set XP bit via CPU arch protocol
Commit e7b24ec9785d ("ArmPkg/UncachedMemoryAllocationLib: map uncached
allocations non-executable") adds code that manipulates the GCD memory
space attributes of a newly allocated uncached region without checking
whether this region expose these attributes in its capabilities mask.
Given that the intent is to remove executable permissions from the region,
this is a fairly pointless exercise to begin with, regardless of whether
it is correct or not. The reason is that RO/XP memory attributes in the
GCD memory space map or the UEFI memory map are completely disconnected
from the actual mapping permissions used in the page tables.
So instead, invoke the CPU arch protocol directly, and add the non-exec
attributes in the page tables directly.
Zhang, Lubo [Thu, 9 Mar 2017 08:17:56 +0000 (16:17 +0800)]
NetworkPkg: Fix potential bug if the iSCSI use dns protocol.
Since we use the Attempt and index as the attempt variable name instead of
the MAC address plus index, we need to update this to check the whether
the Controller handle is configured to use DNS protocol
Jiaxin Wu [Fri, 10 Mar 2017 06:45:12 +0000 (14:45 +0800)]
MdePkg/UefiDevicePathLib: Fix the wrong MAC address length
Network interface type should be checked before the conversion between
text device path node and MAC device path. Otherwise, the MAC text string
can't be converted to the representation of a device node, which leads to
the series failure of network HII configuration(e.g. IP, VLAN, HTTP Boot
configuration in Network Device List).
Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.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: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Laszlo Ersek [Wed, 22 Feb 2017 23:22:17 +0000 (00:22 +0100)]
OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script with QemuFwCfgS3Lib
Drop the explicit S3SaveState protocol and opcode management; instead,
create ACPI S3 Boot Script opcodes for the WRITE_POINTER commands with
QemuFwCfgS3Lib functions.
In this case, we have a dynamically allocated Context structure, hence the
patch demonstrates how the FW_CFG_BOOT_SCRIPT_CALLBACK_FUNCTION takes
ownership of Context.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Wed, 22 Feb 2017 21:48:00 +0000 (22:48 +0100)]
OvmfPkg/SmmControl2Dxe: save fw_cfg boot script with QemuFwCfgS3Lib
We cannot entirely eliminate the manual boot script building in this
driver, as it also programs lower-level chipset registers (SMI_EN,
GEN_PMCON_1) at S3 resume, not just registers exposed via fw_cfg.
We can nonetheless replace the manually built opcodes for the latter class
of registers with QemuFwCfgS3Lib function calls. We preserve the ordering
between the two sets of registers (low-level chipset first, fw_cfg
second).
This patch demonstrates that manual handling of S3SaveState protocol
installation can be combined with QemuFwCfgS3Lib, even without upsetting
the original order between boot script fragments. An S3SaveState notify
function running at TPL_CALLBACK can safely queue another S3SaveState
notify function at TPL_CALLBACK with QemuFwCfgS3CallWhenBootScriptReady().
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Wed, 22 Feb 2017 16:46:43 +0000 (17:46 +0100)]
OvmfPkg/QemuFwCfgS3Lib: implement opcode APIs for DXE fw_cfg instance
In the DXE fw_cfg instance:
- QemuFwCfgS3Enabled() queries S3 enablement via fw_cfg. This behavior is
shared with the PEI fw_cfg instance, and the DXE fw_cfg instance already
pulls in the function from "QemuFwCfgS3PeiDxe.c".
- If QemuFwCfgS3Enabled() returns TRUE, the client module is permitted to
call QemuFwCfgS3CallWhenBootScriptReady().
We provide a fully functional implementation for
QemuFwCfgS3CallWhenBootScriptReady(). A protocol notify is installed at
TPL_CALLBACK for EFI_S3_SAVE_STATE_PROTOCOL. If / once the protocol is
available, the client module's Callback() function is called, which is
expected to produce ACPI S3 Boot Script opcodes using the helper
functions listed below. In QemuFwCfgS3CallWhenBootScriptReady(), we also
allocate a reserved memory buffer, sized & typed by the client module,
for the opcodes and (internally) the fw_cfg DMA operations to work upon,
during S3 resume.
This behavior is unique to the DXE fw_cfg instance. Thus, add the
function to "QemuFwCfgS3Dxe.c".
- The QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(),
QemuFwCfgS3ScriptSkipBytes(), and QemuFwCfgS3ScriptCheckValue()
functions are also implemented usefully, since the client module's
Callback() function is expected to invoke them.
Each of the first three functions produces MEM_WRITE, IO_WRITE, and
MEM_POLL opcodes, to set up the DMA command in reserved memory, to start
the DMA transfer, and to check the DMA result, respectively.
The QemuFwCfgS3ScriptCheckValue() function produces a MEM_POLL opcode to
validate an unsigned integer field in data that was read via
QemuFwCfgS3ScriptReadBytes().
This behavior is again unique to the DXE fw_cfg instance, so add the
functions to "QemuFwCfgS3Dxe.c".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Wed, 22 Feb 2017 09:34:48 +0000 (10:34 +0100)]
OvmfPkg/QemuFwCfgS3Lib: implement opcode APIs for PEI fw_cfg instance
In the PEI fw_cfg instance:
- QemuFwCfgS3Enabled() queries S3 enablement via fw_cfg. This behavior is
shared with the DXE fw_cfg instance, and the PEI fw_cfg instance already
pulls in the function from "QemuFwCfgS3PeiDxe.c".
- If QemuFwCfgS3Enabled() returns TRUE, the client module is permitted to
call QemuFwCfgS3CallWhenBootScriptReady(). However, in the PEI phase we
have no support for capturing ACPI S3 Boot Script opcodes, hence we
return RETURN_UNSUPPORTED unconditionally. This behavior is unique to
the PEI fw_cfg instance, so add the function to "QemuFwCfgS3Pei.c".
- Consequently, the QemuFwCfgS3ScriptWriteBytes(),
QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), and
QemuFwCfgS3ScriptCheckValue() functions must never be called. (They
could only be called from the client module's callback, but
QemuFwCfgS3CallWhenBootScriptReady() will never install such callback in
the PEI fw_cfg instance -- see above.)
This behavior is not unique to the PEI fw_cfg instance (it is shared
with the Base Null instance), so pull in these functions from
"QemuFwCfgS3BasePei.c".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Wed, 22 Feb 2017 09:34:48 +0000 (10:34 +0100)]
OvmfPkg/QemuFwCfgS3Lib: implement opcode APIs for Base Null instance
In the Base Null instance:
- QemuFwCfgS3Enabled() returns constant FALSE. This is unique to the Base
Null instance, and the function is already present in
"QemuFwCfgS3Base.c".
- The QemuFwCfgS3CallWhenBootScriptReady() function must never be called
(according to the documentation, given the above). This is also unique
to the Base Null instance, so implement the function in
"QemuFwCfgS3Base.c".
- Consequently, the QemuFwCfgS3ScriptWriteBytes(),
QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), and
QemuFwCfgS3ScriptCheckValue() functions must never be called either.
This behavior is not unique to the Base Null instance (it will be shared
with the PEI fw_cfg instance), so add these functions to
"QemuFwCfgS3BasePei.c".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Wed, 22 Feb 2017 05:58:55 +0000 (06:58 +0100)]
OvmfPkg/QemuFwCfgS3Lib: add boot script opcode generation APIs to libclass
Introduce the following APIs:
- QemuFwCfgS3CallWhenBootScriptReady(): central function that registers a
callback function, with a context parameter, for when ACPI S3 Boot
Script opcodes can be produced. This function also allocates reserved
memory for the opcodes to operate upon.
The client module is supposed to produce the boot script fragment in the
callback function.
- QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(),
QemuFwCfgS3ScriptSkipBytes(), QemuFwCfgS3ScriptCheckValue(): helper
functions, available only to the above callback function, for composing
the boot script fragment. QemuFwCfgS3ScriptSkipBytes() can double as a
plain "select" whenever necessary.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Extend all modules that call the function with a new QemuFwCfgS3Lib class
dependency. Thanks to the previously added library class, instances, and
class resolutions, we can do this switch now as tightly as possible.
Laszlo Ersek [Wed, 22 Feb 2017 02:11:07 +0000 (03:11 +0100)]
OvmfPkg: resolve QemuFwCfgS3Lib
QemuFwCfgS3Enabled() in "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c"
queries the "etc/system-states" fw_cfg file.
The same implementation is now available factored-out in
"OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3PeiDxe.c". It is available to
PEIMs through the PeiQemuFwCfgS3LibFwCfg instance, and to DXE_DRIVER and
DXE_RUNTIME_DRIVER modules through the DxeQemuFwCfgS3LibFwCfg instance.
Resolve QemuFwCfgS3Lib accordingly.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Wed, 22 Feb 2017 01:40:32 +0000 (02:40 +0100)]
OvmfPkg/QemuFwCfgS3Lib: add initial PEI and DXE fw_cfg library instances
This patch introduces PeiQemuFwCfgS3LibFwCfg, a limited functionality
QemuFwCfgS3Lib instance, for PEI phase modules.
The patch also introduces DxeQemuFwCfgS3LibFwCfg, a full functionality
QemuFwCfgS3Lib instance, for DXE_DRIVER and DXE_RUNTIME_DRIVER modules.
These library instances share the QemuFwCfgS3Enabled() function. The
function actually uses fw_cfg; the implementation is copied from
"OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c".
The library instances will diverge in the following patches.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Wed, 22 Feb 2017 01:09:47 +0000 (02:09 +0100)]
OvmfPkg/QemuFwCfgS3Lib: add initial Base Null library instance
This library instance returns constant FALSE from QemuFwCfgS3Enabled(),
and all other library functions trigger assertion failures. It is suitable
for QEMU targets and machine types that never enable S3.
The QemuFwCfgS3Enabled() implementation is copied from
"ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c". Stubs for further
QemuFwCfgS3Lib APIs (with assertion failures, see above) will be added
later.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Wed, 22 Feb 2017 00:59:41 +0000 (01:59 +0100)]
OvmfPkg: introduce QemuFwCfgS3Lib class
This library class will enable driver modules (a) to query whether S3
support was enabled on the QEMU command line, (b) to produce fw_cfg DMA
operations that are to be replayed at S3 resume time.
Declare the library class in OvmfPkg/OvmfPkg.dec, and add the library
class header under OvmfPkg/Include/Library/. At the moment, the only API
we expose is QemuFwCfgS3Enabled(), which we'll first migrate from
QemuFwCfgLib. Further interfaces will be added in later patches.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Ard Biesheuvel [Tue, 14 Mar 2017 08:01:04 +0000 (08:01 +0000)]
EmbeddedPkg/PrePiLib: allocate code pages for DxeCore
The recently introduced memory protection features inadvertently broke
the boot on all PrePi platforms, because the changes to explicitly use
EfiBootServicesCode for loading the DxeCore PE/COFF image need to be
applied in a different way for PrePi. So add a simple helper function
that sets the type of an allocation to EfiBootServicesCode, and invoke
it to allocate the space for DxeCore.
Marvin Häuser [Sat, 11 Mar 2017 22:05:26 +0000 (22:05 +0000)]
ArmPkg: Fix modsi3.S compilation across toolchains.
modsi3.S references the symbol '__divsi3' by '___divsi3' which assumes
the prefix is always required and supported. Use ASM_PFX() instead
to support all compilers.
Jiewen Yao [Fri, 10 Mar 2017 03:42:53 +0000 (11:42 +0800)]
MdePkg/SmiHandlerProfile: Add Context support in Unregister
The reason is that we observe that a platform may use same Handler
for different context.
In order to support Unregister such handler, we have to input
context information as well.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Jiewen Yao [Thu, 9 Mar 2017 02:32:15 +0000 (10:32 +0800)]
IntelFsp2WrapperPkg: Add Readme.md
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Richard Thomaiyar <richard.marian.thomaiyar@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Jiewen Yao [Thu, 9 Mar 2017 02:31:57 +0000 (10:31 +0800)]
IntelFsp2Pkg: Add Readme.md
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Richard Thomaiyar <richard.marian.thomaiyar@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Ard Biesheuvel [Thu, 9 Mar 2017 15:59:34 +0000 (16:59 +0100)]
ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent
Instead of having a build time switch to prevent the FDT configuration
table from being installed, make this behavior dependent on whether we
are passing ACPI tables to the OS. This is done by looking for the
ACPI 2.0 configuration table, and only installing the FDT one if the
ACPI one cannot be found.
Ard Biesheuvel [Thu, 9 Mar 2017 15:45:07 +0000 (16:45 +0100)]
ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot
Defer FDT configuration table installation until ReadyToBoot is signaled.
This allows any driver to make modifications in the mean time, and will
also allow us to defer the decision of whether to install it in the first
place to later on in the boot.
Disable the PL031 RTC DT node unconditionally rather than only when
the DT will be exposed to the OS. This allows us to defer the decision
whether to expose it to the OS to a later time without creating an
additional dependency on the FDT client code by the RTC driver.
The ACPI specification, up to and including revision 5.1 Errata A, allows
the DSDT and X_DSDT fields to be both set in the FADT. (Obviously, this
only makes sense if the DSDT address is representable in 4 bytes.)
Starting with 5.1 Errata B, specifically for Mantis 1393
<https://mantis.uefi.org/mantis/view.php?id=1393>, the spec requires at
most one of DSDT and X_DSDT to be set to a nonzero value.
MdeModulePkg/AcpiTableDxe handles this mutual exclusion somewhat
inconsistently.
- If the caller of EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() installs the
tables in "DSDT, FADT" order, then we enforce the exclusion between the
DSDT and X_DSDT fields:
DSDT under 4GB FADT.DSDT FADT.X_DSDT [VARIANT B]
-------------- --------- -----------
yes set clear
no clear set
This behavior conforms to 5.1 Errata B. (And it's not required by
earlier versions of the spec.)
- If the caller passes in the tables in "FADT, DSDT" relative order, then
we do not enforce the exclusion:
DSDT under 4GB FADT.DSDT FADT.X_DSDT [VARIANT A]
-------------- --------- -----------
yes set set
no clear set
This satisfies 5.1 Errata A and earlier, but breaks 5.1 Errata B and
later.
Unify the handling of both relative orders. In particular, check the major
and minor version numbers in the FADT. If the FADT version is strictly
before 5.1, then implement [VARIANT A]. If the FADT version is equal to or
larger than 5.1, then implement [VARIANT B].
We make three observations:
- We can't check the FADT table version precisely against "5.1 Errata B";
erratum levels are not captured in the table. We err in the safe
direction, namely we enforce the exclusion for "5.1" and "5.1 Errata A".
- The same applies to "6.0" versus "6.0 Errata A". Because we cannot
distinguish these two, we consider "6.0" to be "equal to or larger than
5.1", and apply [VARIANT B], enforcing the exclusion.
- While a blanket [VARIANT B] would be simpler, there is a significant
benefit to [VARIANT A], under the spec versions that permit it:
compatibility with a wider range of OSPMs (typically, older ones).
For example, Igor reported about a "DELL R430 system with rev4 FADT
where DSDT and X_DSDT are pointing to the same address". Michael also
reported about several systems that exhibit the same.
Regression tested with the following KVM guests (QEMU built at
ata0def594286d, "Merge remote-tracking branch
'remotes/bonzini/tags/for-upstream' into staging", 2017-01-30):
- OVMF: boot and S3 suspend/resume
- Ia32, Q35, SMM
- Fedlet 20141209
- Ia32X64, Q35, SMM
- Fedora 22
- Windows 7
- Windows 8.1
- Windows 10
- Windows Server 2008 R2
- Windows Server 2012 R2
- Windows Server 2016 Tech Preview 4
- X64, I440FX, no SMM
- Fedora 24
- RHEL-6.7
- RHEL-7.2-ish
- ArmVirtQemu: boot test with virtio-gpu
- AARCH64
- Fedora 24
- RHELSA-7.3
- openSUSE Tumbleweed (4.8.4-based)
This change is connected to ASWG ticket
<https://mantis.uefi.org/mantis/view.php?id=1757>, which is now
closed/fixed.
Cc: Al Stone <ahs3@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Feng Tian <feng.tian@intel.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Michael Tsirkin <mtsirkin@redhat.com> Cc: Phil Dennis-Jordan <phil@philjordan.eu> Cc: Star Zeng <star.zeng@intel.com> Reported-by: Phil Dennis-Jordan <phil@philjordan.eu> Suggested-by: Igor Mammedov <imammedo@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Hess Chen [Tue, 7 Mar 2017 08:01:25 +0000 (16:01 +0800)]
BaseTools/UPT: Fix an issue of adding Event twice
Fix the issue of after installing a package the Event information is duplicated. The tool checks if the EVENT information existing in UserExtension or not. If already existing in UserExtension the tool will not add additional information.
Ard Biesheuvel [Wed, 8 Mar 2017 11:46:38 +0000 (12:46 +0100)]
ArmPkg/CpuDxe: handle implied attributes in EfiAttributeToArmAttribute
Some memory attributes are implied by the memory type, e.g., device memory
is always mapped non-executable and cached memory should have the inner
shareable attribute.
In order to prevent unnecessary memory attribute updates of mappings
created early on, make EfiAttributeToArmAttribute() return these implied
attributes in the same way as ArmMmuLib does already. This avoids false
positives when looking for differences between current and desired mapping
attributes.
Ard Biesheuvel [Tue, 7 Mar 2017 11:24:57 +0000 (12:24 +0100)]
ArmVirtPkg: apply PE/COFF memory protection to DxeCore as well
Include DXE_CORE in the BuildOptions that are set to force 4 KB section
alignment for PE/COFF images in order to allow them to be mapped with
strict memory permissions.
The primary use case for UncachedMemoryAllocationLib is non-coherent DMA,
which implies that such regions are not used to fetch instructions from.
So let's map them as non-executable, to avoid creating a security hole
when the rest of the platform may be enforcing strict memory permissions
on ordinary allocations.
Ard Biesheuvel [Tue, 28 Feb 2017 12:13:11 +0000 (12:13 +0000)]
ArmPkg/UncachedMemoryAllocationLib: use CWG value to align pool allocations
Uncached pool allocations are aligned to the data cache line length under
the assumption that this is sufficient to prevent cache maintenance from
corrupting adjacent allocations. However, the value to use in such cases
is architecturally called the Cache Writeback Granule (CWG), which is
essentially the maximum Dcache line length rather than the minimum.
Note that this is mostly a cosmetical fix, given that the pool allocation
is turned into a page allocation later, and rounded up accordingly.
Ard Biesheuvel [Tue, 28 Feb 2017 12:13:10 +0000 (12:13 +0000)]
ArmPkg/UncachedMemoryAllocationLib: restore mapping attributes after free
In order to play nice with platforms that use strict memory permission
policies, restore the original mapping attributes when freeing uncached
allocations.
Dandan Bi [Tue, 7 Mar 2017 02:13:58 +0000 (10:13 +0800)]
EmulatorPkg: Add the UefiBootManagerLib library
Since shell has consumed the APIs in UefiBootManagerLib.
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
In file MpService.c line 786:
Pte[Index] = (UINT64)((UINTN)PageTable + EFI_PAGE_SIZE * (Index + 1)) |
mAddressEncMask ...
(Where PageTable is of type VOID*, Index is of type UINTN, mAddressEncMask
is of type UINT64 and Pte[Index] is of type UINT64.)
Since in this case, the code logic ensures that the expression will not
exceed the range of UINTN, the commit will remove the explicit type cast
'(UINT64)'.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:43 +0000 (16:31 +0000)]
ArmVirtPkg: enable non-executable DXE stack for all platforms
Now that ARM has grown support for managing memory permissions in
ArmMmuLib, we can enable the non-executable DXE stack for all virt
platforms. Note that this includes the AARCH64 Xen platform as well.
Note that this is not [entirely] redundant: the non-executable stack
is configured before DxeCore is invoked. The image and memory protection
features configured during DXE only take affect when the CPU arch
protocol implementation is registered.
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:42 +0000 (16:31 +0000)]
ArmPkg/ArmMmuLib ARM: implement memory permission control routines
Now that we have the prerequisite functionality available in ArmMmuLib,
wire it up into ArmSetMemoryRegionNoExec, ArmClearMemoryRegionNoExec,
ArmSetMemoryRegionReadOnly and ArmClearMemoryRegionReadOnly. This is
used by the non-executable stack feature that is configured by DxeIpl.
NOTE: The current implementation will not combine RO and XP attributes,
i.e., setting/clearing a region no-exec will unconditionally
clear the read-only attribute, and vice versa. Currently, we
only use ArmSetMemoryRegionNoExec(), so for now, we should be
able to live with this.
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:41 +0000 (16:31 +0000)]
ArmPkg/ArmMmuLib: remove VirtualMask arg from ArmSetMemoryAttributes
We no longer make use of the ArmMmuLib 'feature' to create aliased
memory ranges with mismatched attributes, and in fact, it was only
wired up in the ARM version to begin with.
So remove the VirtualMask argument from ArmSetMemoryAttributes()'s
prototype, and remove the dead code that referred to it.
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:40 +0000 (16:31 +0000)]
ArmPkg: move ARM version of SetMemoryAttributes to ArmMmuLib
... where it belongs, since AARCH64 already keeps it there, and
non DXE users of ArmMmuLib (such as DxeIpl, for the non-executable
stack) may need its functionality as well.
While at it, rename SetMemoryAttributes to ArmSetMemoryAttributes,
and make any functions that are not exported STATIC. Also, replace
an explicit gBS->AllocatePages() call [which is DXE specific] with
MemoryAllocationLib::AllocatePages().
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:39 +0000 (16:31 +0000)]
ArmPkg/ArmMmuLib: use correct return type for exported functions
The routines ArmConfigureMmu(), SetMemoryAttributes() [*] and the
various set/clear read-only/no-exec routines are declared as returning
EFI_STATUS in the respective header files, so align the definitions with
that.
* SetMemoryAttributes() is declared in the wrong header (and defined in
ArmMmuLib for AARCH64 and in CpuDxe for ARM)
Ard Biesheuvel [Thu, 2 Mar 2017 10:36:15 +0000 (10:36 +0000)]
ArmPkg/CpuDxe ARM: honour RO/XP attributes in SetMemoryAttributes()
Enable the use of strict memory permissions on ARM by processing the
EFI_MEMORY_RO and EFI_MEMORY_XP rather than ignoring them. As before,
calls to CpuArchProtocol::SetMemoryAttributes that only set RO/XP
bits will preserve the cacheability attributes. Permissions attributes
are not preserved when setting the memory type only: the way the memory
permission attributes are defined does not allows for that, and so this
situation does not deviate from other architectures.
Page and section entries in the page tables are updated using the
helper ArmUpdateTranslationTableEntry(), which cleans the page
table entry to the PoC, and invalidates the TLB entry covering
the page described by the entry being updated.
Since we may be updating section entries, we might be leaving stale
TLB entries at this point (for all pages in the section except the
first one), which will be invalidated wholesale at the end of
SetMemoryAttributes(). At that point, all caches are cleaned *and*
invalidated as well.
This cache maintenance is costly and unnecessary. The TLB maintenance
is only necessary if we updated any section entries, since any page
by page entries that have been updated will have been invalidated
individually by ArmUpdateTranslationTableEntry().
So drop the clean/invalidate of the caches, and only perform the
full TLB flush if UpdateSectionEntries() was called, or if sections
were split by UpdatePageEntries(). Finally, make the cache maintenance
on the remapped regions themselves conditional on whether any memory
type attributes were modified.
Currently, any range passed to CpuArchProtocol::SetMemoryAttributes is
fully broken down into page mappings if the start or the size of the
region happens to be misaliged relative to the section size of 1 MB.
This is going to result in memory being wasted on second level page tables
when we enable strict memory permissions, given that we remap the entire
RAM space non-executable (modulo the code bits) when the CpuArchProtocol
is installed.
So refactor the code to iterate over the range in a way that ensures
that all naturally aligned section sized subregions are not broken up.
Architectures such as AArch64 may run the OS with 16 KB or 64 KB sized
pages, and for this reason, the UEFI spec mandates a minimal allocation
granularity of 64 KB for regions that may require different memory
attributes at OS runtime.
So make PeiCore's implementation of AllocatePages () take this into
account as well.
Ard Biesheuvel [Fri, 3 Mar 2017 15:11:31 +0000 (15:11 +0000)]
MdePkg/ProcessorBind: add defines for page allocation granularity
The UEFI spec differs between architectures in the minimum alignment
and granularity of page allocations that are visible to the OS as
EFI_MEMORY_RUNTIME regions.
So define macros that carry these values to the respective ProcessorBind.h
header files.
Leo Duran [Thu, 2 Mar 2017 23:36:03 +0000 (07:36 +0800)]
UefiCpuPkg/CpuDxe: Add support for PCD PcdPteMemoryEncryptionAddressOrMask
This PCD holds the address mask for page table entries when memory
encryption is enabled on AMD processors supporting the Secure Encrypted
Virtualization (SEV) feature.
The mask is applied when page tables entries are created or modified.
CC: Jeff Fan <jeff.fan@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Hao Wu [Fri, 17 Feb 2017 03:54:10 +0000 (11:54 +0800)]
UefiCpuPkg: Refine casting expression result to bigger size
There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.
An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);
Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.
The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;
2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;
3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);
4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}
For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
projects / mirror_edk2.git / log