UefiCpuPkg/PiSmmCpuDxeSmm depends on this library (the
RegisterCpuInterruptHandler() function specifically) to set up its
specialized page fault handler (SmiPFHandler() -> DumpModuleInfoByIp()).
It doesn't hurt to resolve this library class for all DXE_SMM_DRIVER
modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19050 6f19259b-4bc3-4df7-8a09-765794883524
PiSmmCpuDxeSmm depends on this library class, and it's okay to resolve it
generally for all DXE_SMM_DRIVER modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19049 6f19259b-4bc3-4df7-8a09-765794883524
During DXE, drivers save data in the LockBox. A save operation is layered
as follows:
- The unprivileged driver wishing to store data in the LockBox links
against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf"
library instance.
The library allows the unprivileged driver to format requests for the
privileged SMM LockBox driver (see below), and to parse responses.
We apply this resolution for DXE_DRIVER modules.
- The privileged SMM LockBox driver is built from
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver
has module type DXE_SMM_DRIVER and can access SMRAM.
The driver delegates command parsing and response formatting to
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf".
Therefore we include this DXE_SMM_DRIVER in the build, and apply said
resolution specifically to it.
(Including the driver requires us to resolve a few of other library
classes for DXE_SMM_DRIVER modules.)
- In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei)
retrieves data from the LockBox. It is capable of searching SMRAM
itself.
We resolve LockBoxLib to
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically
for this one PEIM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19048 6f19259b-4bc3-4df7-8a09-765794883524
Since our fake LockBox must not be selected with -D SMM_REQUIRE (see the
previous patch), it makes sense to set aside memory for it only if -D
SMM_REQUIRE is absent. Modify InitializeRamRegions() accordingly.
This patch completes the -D SMM_REQUIRE-related tweaking of the special
OVMF memory areas.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19047 6f19259b-4bc3-4df7-8a09-765794883524
When the user builds OVMF with -D SMM_REQUIRE, our LockBox implementation
must not be used, since it doesn't actually protect data in the LockBox
from the runtime guest OS. Add an according assert to
LockBoxLibInitialize().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19046 6f19259b-4bc3-4df7-8a09-765794883524
In SVN r15306 (git commit d4ba06df), "OvmfPkg: S3 Resume: fake LockBox
protocol for BootScriptExecutorDxe", we installed a fake LockBox protocol
in OVMF's AcpiS3SaveDxe clone. While our other AcpiS3SaveDxe
customizations remain valid (or harmless), said change is invalid when
OVMF is built with -D SMM_REQUIRE and includes the real protocol provider,
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19045 6f19259b-4bc3-4df7-8a09-765794883524
This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends
on in its gEfiDxeSmmReadyToLockProtocolGuid callback
(SmmReadyToLockHandler(), "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c").
Approached on a higher level, this driver provides the SmmIo member of the
EFI_SMM_SYSTEM_TABLE2 (SMST).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19044 6f19259b-4bc3-4df7-8a09-765794883524
"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" (a DXE_RUNTIME_DRIVER)
implements the SMM Initial Program Loader. It produces
EFI_SMM_BASE2_PROTOCOL and EFI_SMM_COMMUNICATION_PROTOCOL, relying on:
- EFI_SMM_ACCESS2_PROTOCOL
(provided by OvmfPkg/SmmAccess/SmmAccess2Dxe.inf),
- EFI_SMM_CONTROL2_PROTOCOL
(provided by OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf).
(The SMM IPL also depends on EFI_SMM_CONFIGURATION_PROTOCOL_GUID, but this
dependency is not enforced in the entry point. A protocol notify callback
is registered instead, hence we can delay providing that protocol via the
PiSmmCpuDxeSmm driver that is (to be) imported from UefiCpuPkg/.)
The SMM IPL loads the SMM core into SMRAM and executes it from there.
Therefore we add the SMM core to the build as well.
For the SMM core, a number of library classes need to be resolved.
Furthermore, each FDF file must provide the GenFds.py BaseTools utility
with a build rule for SMM_CORE; we copy the DXE_CORE's rule.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19043 6f19259b-4bc3-4df7-8a09-765794883524
The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the
SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the
mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() function
[MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c].
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19042 6f19259b-4bc3-4df7-8a09-765794883524
The SMM core depends on EFI_SMM_ACCESS2_PROTOCOL. This small driver (which
is a thin wrapper around "OvmfPkg/SmmAccess/SmramInternal.c" that was
added in the previous patch) provides that protocol.
Notably, EFI_SMM_ACCESS2_PROTOCOL is for boot time only, therefore
our MODULE_TYPE is not DXE_RUNTIME_DRIVER.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19041 6f19259b-4bc3-4df7-8a09-765794883524
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the
LockBoxLib instance with SMRAM access for the PEI phase.
Said library instance must, and can, access the LockBox data in SMRAM
directly if it is invoked before SMBASE relocation / SMI handler
installation. In that case, it only needs PEI_SMM_ACCESS_PPI from the
platform, and it doesn't depend on EFI_PEI_SMM_COMMUNICATION_PPI.
OVMF satisfies the description in SVN r18823 ("MdeModulePkg:
SmmLockBoxPeiLib: work without EFI_PEI_SMM_COMMUNICATION_PPI"): in OVMF,
only S3Resume2Pei links against SmmLockBoxPeiLib.
Therefore, introduce a PEIM that produces the PEI_SMM_ACCESS_PPI
interface, enabling SmmLockBoxPeiLib to work; we can omit including
"UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf".
The load / installation order of S3Resume2Pei and SmmAccessPei is
indifferent. SmmAccessPei produces the gEfiAcpiVariableGuid HOB during its
installation (which happens during PEI), but S3Resume2Pei accesses the HOB
only when the DXE IPL calls its S3RestoreConfig2 PPI member, as last act
of PEI.
MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way they are, in
SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order to
prevent VS20xx from warning about the (otherwise fully intentional)
truncation in the UINT8 casts. (Warnings reported by Michael Kinney.)
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19040 6f19259b-4bc3-4df7-8a09-765794883524
PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations:
- PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed
so that it ends with the RAM below 4GB,
- QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are
created for the RAM below 4GB; plus MTRR attributes are set
(independently of S3 vs. normal boot)
- MemMapInitialization(): an MMIO resource descriptor HOB is created for
PCI resource allocation, on normal boot, starting at max(RAM below 4GB,
2GB).
The first two of these is adjusted for the configured TSEG size, if
PcdSmmSmramRequire is set:
- In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG.
- In QemuInitializeRam(), we must keep the DXE out of TSEG.
One idea would be to simply trim the [1MB .. LowerMemorySize] memory
resource descriptor HOB, leaving a hole for TSEG in the memory space
map.
The SMM IPL will however want to massage the caching attributes of the
SMRAM range that it loads the SMM core into, with
gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So,
instead of trimming this range, split the TSEG area off, and report it
as a cacheable reserved memory resource.
Finally, since reserved memory can be allocated too, pre-allocate TSEG
in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that
this step alone does not suffice without the resource descriptor HOB
trickery: if we omit that, then the DXE IPL PEIM fails to load and start
the DXE core.)
- In MemMapInitialization(), the start of the PCI MMIO range is not
affected.
We choose the largest option (8MB) for the default TSEG size. Michael
Kinney pointed out that the SMBASE relocation in PiSmmCpuDxeSmm consumes
SMRAM proportionally to the number of CPUs. From the three options
available, he reported that 8MB was both necessary and sufficient for the
SMBASE relocation to succeed with 255 CPUs:
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3137
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3177
Cc: Michael Kinney <michael.d.kinney@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>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19039 6f19259b-4bc3-4df7-8a09-765794883524
AddReservedMemoryBaseSizeHob() should be able to set the same resource
attributes for reserved memory as AddMemoryBaseSizeHob() sets for system
memory. Add a new parameter called "Cacheable" to
AddReservedMemoryBaseSizeHob(), and set it to FALSE in the only caller we
have at the moment.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19038 6f19259b-4bc3-4df7-8a09-765794883524
If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is
not trusted and we should defend against it tampering with the firmware's
data.
One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is
decompressed on the first boot by SEC, then the OS preserves it across S3
suspend-resume cycles; at S3 resume SEC just reuses the originally
decompressed PEIFV.
However, if we don't trust the OS, then SEC must decompress PEIFV from the
pristine flash every time, lest we execute OS-injected code or work with
OS-injected data.
Due to how FVMAIN_COMPACT is organized, we can't decompress just PEIFV;
the decompression brings DXEFV with itself, plus it uses a temporary
output buffer and a scratch buffer too, which even reach above the end of
the finally installed DXEFV. For this reason we must keep away a
non-malicious OS from DXEFV too, plus the memory up to
PcdOvmfDecomprScratchEnd.
The delay introduced by the LZMA decompression on S3 resume is negligible.
If -D SMM_REQUIRE is not specified, then PcdSmmSmramRequire remains FALSE
(from the DEC file), and then this patch has no effect (not counting some
changed debug messages).
If QEMU doesn't support S3 (or the user disabled it on the QEMU command
line), then this patch has no effect also.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19037 6f19259b-4bc3-4df7-8a09-765794883524
The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
memory, temporarily, than what PEIFV and DXEFV will ultimately need.
First, it uses an output buffer for decompression, second, the
decompression itself needs a scratch buffer (and this scratch buffer is
the highest area that SEC uses).
DecompressMemFvs() used to be called on normal boots only (ie. not on S3
resume), which is why the decompression output buffer and the scratch
buffer were allowed to scribble over RAM. However, we'll soon start to
worry during S3 resume that the runtime OS might tamper with the
pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3
resume too, from pristine flash. For this we'll need to know the end of
the scratch buffer in advance, so we can prepare a non-malicious OS for
it.
Calculate the end of the scratch buffer statically in the FDF files, and
assert in DecompressMemFvs() that the runtime decompression will match it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19036 6f19259b-4bc3-4df7-8a09-765794883524
BaseExtractGuidedSectionLib uses a table at the static physical address
PcdGuidedExtractHandlerTableAddress, and modules that are linked against
BaseExtractGuidedSectionLib are expected to work together on that table.
Namely, some modules can register handlers for GUIDed sections, some other
modules can decode such sections with the pre-registered handlers. The
table carries persistent information between these modules.
BaseExtractGuidedSectionLib checks a table signature whenever it is used
(by whichever module that is linked against it), and at the first use
(identified by a signature mismatch) it initializes the table.
One of the module types that BaseExtractGuidedSectionLib can be used with
is SEC, if the SEC module in question runs with the platform's RAM already
available.
In such cases the question emerges whether the initial contents of the RAM
(ie. contents that predate the very first signature check) can be trusted.
Normally RAM starts out with all zeroes (leading to a signature mismatch
on the first check); however a malicious runtime OS can populate the area
with some payload, then force a warm platform reset or an S3
suspend-and-resume. In such cases the signature check in the SEC module
might not fire, and ExtractGuidedSectionDecode() might run code injected
by the runtime OS, as part of SEC (ie. with high privileges).
Therefore we clear the handler table in SEC.
See also git commit ad43bc6b2e (SVN rev 15433) -- this patch secures the
(d) and (e) code paths examined in that commit. Furthermore, a
non-malicious runtime OS will observe no change in behavior; see case (c)
in said commit.
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[michael.d.kinney@intel.com: prevent VS20xx loop intrinsic with volatile]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19035 6f19259b-4bc3-4df7-8a09-765794883524
This build time flag and corresponding Feature PCD will control whether
OVMF supports (and, equivalently, requires) SMM/SMRAM support from QEMU.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19034 6f19259b-4bc3-4df7-8a09-765794883524
Before introducing the SMM driver interface, clean up #include directives
and [LibraryClasses] by:
- removing what's not directly used (HobLib and UefiLib),
- adding what's used but not spelled out (DevicePathLib),
- sorting the result.
This helps with seeing each source file's dependencies and with
determining the library classes for the SMM driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18672 6f19259b-4bc3-4df7-8a09-765794883524
In preparation for introducing an SMM interface to this driver, move the
following traits to separate files, so that we can replace them in the new
SMM INF file:
- Protocol installations. The SMM driver will install protocol interfaces
in the SMM protocol database, using SMM services.
- Virtual address change handler and pointer conversions. SMM drivers run
with physical mappings and pointers must not be converted.
There are further restrictions and changes for an SMM driver, but the rest
of the code either complies with those already, or will handle the changes
transparently. For example:
- SMM drivers have access to both UEFI and SMM protocols in their entry
points (see the PI spec 1.4, "1.7 SMM Driver Initialization"),
- MemoryAllocationLib has an SMM instance that serves allocation requests
with the gSmst->SmmAllocatePool() service transparently, allocating
runtime-marked SMRAM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18671 6f19259b-4bc3-4df7-8a09-765794883524
Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:
- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]
In every case, the entry at subscript zero is meant as "physical address",
while the entry at subscript one is meant as "virtual address" -- a
pointer to the same object. The virtual address entry is originally
initialized to the physical address, and then it is converted to the
virtual mapping in FvbVirtualddressChangeEvent().
Functions that (a) read the listed fields and (b) run both before and
after the virtual address change event -- since this is a runtime DXE
driver -- derive the correct array subscript by calling the
EfiGoneVirtual() function from UefiRuntimeLib.
The problem with the above infrastructure is that it's entirely
superfluous.
EfiGoneVirtual() "knows" whether EFI has gone virtual only because the
UefiRuntimeLib constructor registers the exact same kind of virtual
address change callback, and the callback flips a static variabe to TRUE,
and EfiGoneVirtual() queries that static variable.
In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a
virtual address change, convert the entries with subscript one from
physical to virtual, and from then on use the entries with subscript one".
This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed
the original (physical) addresses (ie. the entries with subscript zero)
after the virtual address change, but that is not the case.
Replace the arrays with single elements. The subscript zero elements
simply disappear, and the single elements take the role of the prior
subscript one elements.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18670 6f19259b-4bc3-4df7-8a09-765794883524
The ESAL_FWB_GLOBAL.FvbScratchSpace array is never initialized (it
contains garbage from AllocateRuntimePool()). Its element at subscript one
(=FVB_VIRTUAL), containing garbage as well, is converted to virtual
mapping. Then the array is never used again.
Remove it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18669 6f19259b-4bc3-4df7-8a09-765794883524
The EFI_FW_VOL_INSTANCE.FvbDevLock member is initialized and then never
used. Remove it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18668 6f19259b-4bc3-4df7-8a09-765794883524
We build this driver for X64 as well -- the comment isn't overly
important, but it shouldn't be misleading.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18667 6f19259b-4bc3-4df7-8a09-765794883524
Some of the line lengths in this driver are atrocious. While we have to
put up with the status quo outside of OvmfPkg, we can at least rewrap this
driver before refactoring it.
In the FvbInitialize() function there's no way around introducing two
local variables, just for the sake of sensibly rewrapping the code.
Furthermore, in "FwBlockService.c" the function comment blocks are now
indented; their original position causes diff to print bogus function
names at the top of hunks.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18666 6f19259b-4bc3-4df7-8a09-765794883524
Empty cdroms are not going to connect, avoid waiting for the backend to
switch to state 4, which is never going to happen, and return
error instead from XenPvBlockFrontInitialization(). Detect an
empty cdrom by looking at the "params" node on xenstore, which is set to
"" or "aio:" for empty drives by libxl.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18651 6f19259b-4bc3-4df7-8a09-765794883524
(1) VirtioLib allocates the virtio ring in EfiBootServicesData memory.
(This is intentional.) Code that executes after ExitBootServices() is
permitted to reuse such memory.
(2) The hypervisor is allowed to look at, and act upon, a live virtio ring
at any time, even without explicit virtio kicks from the guest.
Should boot loader code or kernel code, running between ExitBootServices()
and the kernel's own virtio drivers resetting the device, overwrite the
pages that used to contain the virtio ring before ExitBootServices(), QEMU
could theoretically interpret that unrelated data as garbage ring
contents, and abort the guest.
Although we have seen no such reports, better be prudent and reset the
device in an ExitBootServices() event handler. Among other things, this
causes QEMU to forget about the device's virtio ring.
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18624 6f19259b-4bc3-4df7-8a09-765794883524
(1) VirtioLib allocates the virtio ring in EfiBootServicesData memory.
(This is intentional.) Code that executes after ExitBootServices() is
permitted to reuse such memory.
(2) The hypervisor is allowed to look at, and act upon, a live virtio ring
at any time, even without explicit virtio kicks from the guest.
Should boot loader code or kernel code, running between ExitBootServices()
and the kernel's own virtio drivers resetting the device, overwrite the
pages that used to contain the virtio ring before ExitBootServices(), QEMU
could theoretically interpret that unrelated data as garbage ring
contents, and abort the guest.
Although we have seen no such reports, better be prudent and reset the
device in an ExitBootServices() event handler. Among other things, this
causes QEMU to forget about the device's virtio ring.
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18623 6f19259b-4bc3-4df7-8a09-765794883524
The update to the LocalApicLib instances to make sure the Local APIC is
initialized before use (SVN r18595 / git commit 6d72ff7d9d) generates an
ASSERT() when SOURCE_DEBUG_ENABLE is enabled for OVMF.
The fix is to initialize the Local APIC Timer and mask it before
initializing the DebugAgent.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: rewrap code comment, rewrap commit msg, add precise
commit ref]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18622 6f19259b-4bc3-4df7-8a09-765794883524
With gcc5 and enabling SECURE_BOOT and NETWORK_IP6, the build
failed with this error:
GenFv: ERROR 3000: Invalid
the required fv image size 0x814c18 exceeds the set fv image size 0x800000
Raise the DXEFV size to 9 MB to fix the build error.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18577 6f19259b-4bc3-4df7-8a09-765794883524
Increase the section alignment to 4 KB for DXE_RUNTIME_DRIVER modules.
This allows the OS to map them with tightened permissions (i.e., R-X for
.text and RW- for .data). This is a prerequisite for enabling the
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA (sic)
feature that was introduced in UEFIv2.5.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18564 6f19259b-4bc3-4df7-8a09-765794883524
The TFTP command is easy to use, it has very nice documentation
(accessible with "HELP TFTP" in the shell), and it's a very versatile tool
for downloading files from the host to the guest, via virtual network,
while the guest is in the UEFI shell.
Even better, enabling this command in the shell increases the uncompressed
DXEFV size only by 12896 bytes, in my X64 build, and the final size
increase (after LZMA compression) that is visible in the FVMAIN_COMPACT
volume is merely 2576 bytes.
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18554 6f19259b-4bc3-4df7-8a09-765794883524
In this patch, we replace the traditional IDE driver stack that comes from
PcAtChipsetPkg and IntelFrameworkModulePkg with more featureful drivers
from OvmfPkg and MdeModulePkg. The resultant driver stack is compatible
with the previous one, but provides more protocols, on more kinds of
virtual hardware.
Remove:
- PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf
(removing EFI_IDE_CONTROLLER_INIT_PROTOCOL [1])
Remove the dependent:
- IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
(removing EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3])
As replacement, add:
- OvmfPkg/SataControllerDxe/SataControllerDxe.inf
(supplying EFI_IDE_CONTROLLER_INIT_PROTOCOL [1])
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
(providing EFI_ATA_PASS_THRU_PROTOCOL,
EFI_EXT_SCSI_PASS_THRU_PROTOCOL)
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
(supplying EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3],
providing EFI_BLOCK_IO2PROTOCOL,
EFI_STORAGE_SECURITY_COMMAND_PROTOCOL)
Cc: Alexander Graf <agraf@suse.de>
Cc: Reza Jelveh <reza.jelveh@tuhh.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de>
[lersek@redhat.com: rewrote commit message]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18532 6f19259b-4bc3-4df7-8a09-765794883524
The OpenFirmware device paths that QEMU generates for these disks and
CD-ROMs are very similar to those generated for the i440fx IDE disks and
CD-ROMs (including the same number of devpath nodes necessary for unique
parsing). The interpretations and the translation to UEFI devpath
fragments are different, of course.
(The spaces after "ide@1,1" are inserted below only for illustration
purposes.)
primary or secondary
| master or slave
v v
i440fx IDE: /pci@i0cf8/ide@1,1 /drive@0/disk@0
Q35 SATA: /pci@i0cf8/pci8086,2922@1f,2/drive@1/disk@0
^ ^
| device number
| (fixed 0)
channel (port) number
The similarity is reflected in the translation output (spaces again
inserted for illustration only):
i440fx IDE: PciRoot(0x0)/Pci(0x1,0x1) /Ata(Primary,Master,0x0)
Q35 SATA: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)
^ ^ ^
| | LUN;
| | always 0 on Q35
| port multiplier port
| number; always 0 on Q35
channel (port) number
Cc: Alexander Graf <agraf@suse.de>
Cc: Reza Jelveh <reza.jelveh@tuhh.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18531 6f19259b-4bc3-4df7-8a09-765794883524
When we bind the SATA controller in SataControllerStart(), we read the NP
("Number of Ports") bitfield from the CAP ("HBA Capabilities") register of
the controller. (See the AHCI 1.3.1 spec.)
This register is memory mapped. If we'd like to access it, we must at
least enable memory space access for the device. In addition, Feng Tian
recommended enabling Bus Master DMA in
<http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10545/focus=10659>.
We also enable IO space access for completeness.
Further, because we change the PCI attributes of the device with the above
when binding it, we must also restore its original PCI attributes when
unbinding it. See the Driver Writer's Guide for UEFI 2.3.1 v1.01, section
18.3 "PCI drivers" | 18.3.2 "Start() and Stop()".
(OvmfPkg's copy of SataControllerDxe differs from the same in DuetPkg
because Duet inherits a pre-configured SATA controller from the BIOS, as
explained by Feng. Technically, DuetPkg's SataControllerDxe could also
apply the technique seen in this patch.)
Cc: Alexander Graf <agraf@suse.de>
Cc: Reza Jelveh <reza.jelveh@tuhh.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Cc: Feng Tian <feng.tian@intel.com>
Suggested-by: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18528 6f19259b-4bc3-4df7-8a09-765794883524
In the next patch we'll add another PCI operation to
SataControllerStart(), which, on error, has to be rolled back similarly to
other actions already being done in SataControllerStart(). Since that PCI
operation won't provide a non-NULL pointer on success, its rollback isn't
really suitable for the current error handling in SataControllerStart().
Employ the traditional cascading labels instead.
Cc: Alexander Graf <agraf@suse.de>
Cc: Reza Jelveh <reza.jelveh@tuhh.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18527 6f19259b-4bc3-4df7-8a09-765794883524
Edk2 maintainers reached the consensus that SataControllerDxe was
inherently platform specific, for which reason it was not appropriate for
either PcAtChipsetPkg nor MdeModulePkg. Hence, if OvmfPkg wanted to use
it, it should either reference it directly from under DuetPkg, or copy it.
Given that DuetPkg is another "leaf" platform in edk2, and that in the
upcoming patches we'll actually modify the driver, the ultimate decision
(reached months ago on the list, after Reza's v2 posting) is that OvmfPkg
shall copy the driver.
This patch does that; the only difference being a fresh FILE_GUID in the
INF file.
Cc: Alexander Graf <agraf@suse.de>
Cc: Reza Jelveh <reza.jelveh@tuhh.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de>
[lersek@redhat.com: updated commit message, generated fresh FILE_GUID]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18526 6f19259b-4bc3-4df7-8a09-765794883524
(PcdSetNxForStack == TRUE) breaks a number of GRUB versions that, it turns
out, are still widely in use. Disable PcdSetNxForStack by default for now.
QEMU users can enable it dynamically using the micro-feature added in the
previous patch.
Reported-by: Anthony Perard <anthony.perard@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18472 6f19259b-4bc3-4df7-8a09-765794883524
Control them with:
-fw_cfg name=opt/ovmf/PcdPropertiesTableEnable,file=no.txt \
-fw_cfg name=opt/ovmf/PcdSetNxForStack,file=yes.txt
where the contents of the text files can be
[0nN1yY](\n|\r\n)?
The macro trickery is not optimal, but it is caused by PcdSetBool(), which
is itself a macro, and can only take open-coded PCD names (ie. no
variables, like function parameters).
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18471 6f19259b-4bc3-4df7-8a09-765794883524
Since PcdPropertiesTableEnable is used by the DXE Core (in the
InstallPropertiesTable() function, which runs at End-of-Dxe), we must also
change the PcdLib class resolution for that module, from the default
BasePcdLibNull to DxePcdLib.
Traditionally we've considered the DXE Core to be incapable of accessing
dynamic PCDs -- the PCD PPI is not available any longer to the DXE Core,
and the PCD Protocol is not available to it *yet*. There are exceptions
however: if the DXE Core can ensure, by whatever means, that the PCD
Protocol *is* available, then DxePcdLib will just work (the latter even
lists DXE_CORE as an allowed client module type). Namely, DxePcdLib looks
up the PCD Protocol dynamically, on the first library call that actually
needs it (for accessing a dynamic PCD); the lookup doesn't occur in a
library constructor.
And because the DXE Core fetches PcdPropertiesTableEnable at End-of-Dxe,
the PCD Protocol is definitely available then.
In addition, we change the default value of PcdPropertiesTableEnable from
the inherited TRUE to FALSE. It makes no difference at this point (our
runtime DXE drivers are not built with the required 4KB section alignment
anyway), but it's better to be clear about this. The properties table
feature requires OS compatibility, and it breaks Windows 7 minimally.
Therefore the default should be FALSE.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Star Zeng <star.zeng@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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18470 6f19259b-4bc3-4df7-8a09-765794883524
Plus, because PcdSetNxForStack is used by the DXE IPL PEIM (in the
HandOffToDxeCore() function, and in the CreateIdentityMappingPageTables()
function called by the former), we must change the PcdLib class resolution
for that module, from the default BasePcdLibNull to PeiPcdLib.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Star Zeng <star.zeng@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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18469 6f19259b-4bc3-4df7-8a09-765794883524
The logic we have in place for i440fx does not work reliably on q35. For
example, if the guest has 2GB of RAM, we allow the PCI root bridge driver
to allocate the legacy video RAM BAR from the [2048 MB, 2816 MB] range,
which falls strictly outside of the Q35 PCI host MMIO aperture that QEMU
configures, and advertizes in ACPI.
In turn, PCI BARs that exist outside of the PCI host aperture that is
exposed in ACPI break Windows guests.
Allocating PCI MMIO resources at or above 3GB on Q35 ensures that we stay
within QEMU's aperture. (See the "w32.begin" assignments in
"hw/pci-host/q35.c".) Furthermore, in pc_q35_init() (file
"hw/i386/pc_q35.c"), QEMU ensures that the low RAM never "leaks" above
3GB.
The i440fx logic is left unchanged.
The Windows guest malfunction on Q35 was reported by Jon Panozzo of Lime
Technology, Inc.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jon Panozzo <jonp@lime-technology.com>
Cc: "Gabriel L. Somlo" <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Jonathan Panozzo <jonp@lime-technology.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18393 6f19259b-4bc3-4df7-8a09-765794883524
Bruce Cran reported the following issue:
With iasl version 20150410-64 building OvmfX64 (using OvmfPkg/build.sh
-a X64 -t GCC49 -b RELEASE) results in a couple of warnings about
methods that should be serialized:
.../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.iiii
95: Method (_CRS, 0) {
Remark 2120 - Control Method should be made Serialized ^ (due to
creation of named objects within)
.../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.iiii
235: Method (PCRS, 1, NotSerialized) {
Remark 2120 - Control Method should be made Serialized ^ (due to
creation of named objects within)
The ACPI 6.0 spec justifies the above warnings in "19.6.82 Method (Declare
Control Method)":
[...] The serialize rule can be used to prevent reentering of a method.
This is especially useful if the method creates namespace objects.
Without the serialize rule, the reentering of a method will fail when it
attempts to create the same namespace object. [...]
Cc: Bruce Cran <bruce@cran.org.uk>
Reported-by: Bruce Cran <bruce@cran.org.uk>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18392 6f19259b-4bc3-4df7-8a09-765794883524
We have an old bug in BootModeInitialization(): firmware is supposed to
clear the CMOS register 0xF after reading it for the last time. QEMU only
sets this register to 0xFE in "hw/timer/mc146818rtc.c", function
rtc_notify_suspend(), and never clears it. However, SeaBIOS does clear it
in "src/post.c" and "src/resume.c", so let's follow suit.
We've never noticed this until now because the register gets mysteriously
cleared on non-resume reboots when OVMF runs on qemu-system-x86_64. But on
qemu-system-i386, this bug breaks a (suspend, resume, reboot) triplet:
after the last step OVMF thinks it's resuming because when it actually
resumed (in the middle step), it failed to clear the register.
BootModeInitialization() is the perfect function to clear the register,
right after setting mBootMode: the function is executed on both normal
boot and on S3 resume; it succeeds DebugDumpCmos() -- so the dump is not
affected by this patch --; and everything that relies on S3 vs. normal
boot after we clear the register uses mBootMode anyway.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18391 6f19259b-4bc3-4df7-8a09-765794883524
SVN rev 18166 ("MdeModulePkg DxeIpl: Add stack NX support") enables
platforms to request non-executable stack for the DXE phase, by setting
PcdSetNxForStack to TRUE.
The PCD defaults to FALSE, because:
(a) A non-executable DXE stack is a new feature and causes changes in
behavior. Some platform could rely on executing code from the stack.
(b) The code enabling NX in the DXE IPL PEIM enforces the
PcdSetNxForStack ==> PcdDxeIplBuildPageTables
implication for "64-bit PEI + 64-bit DXE" platforms, with a new
ASSERT(). Some platform might not comply with this requirement
immediately.
Regarding (a), in none of the OVMF builds do we try to execute code from
the stack.
Regarding (b):
- In the OvmfPkgX64.dsc build (which is where (b) applies) we simply
inherit the PcdDxeIplBuildPageTables|TRUE default from
"MdeModulePkg/MdeModulePkg.dec". Therefore we can set PcdSetNxForStack
to TRUE.
- In OvmfPkgIa32X64.dsc, page tables are built by default for DXE. Hence
we can set PcdSetNxForStack to TRUE.
- In OvmfPkgIa32.dsc, page tables used not to be necessary until now.
After we set PcdSetNxForStack to TRUE in this patch, the DXE IPL will
construct page tables even when it is built as part of OvmfPkgIa32.dsc,
provided the (virtual) hardware supports both PAE mode and the XD bit.
Should this setting cause problems in a GPU (or other device) passthru
scenario, with a UEFI_DRIVER in the PCI option rom attempting to execute
code from the stack, the feature can be dynamically disabled on the QEMU
command line, with "-cpu <MODEL>,-nx".
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: "Zeng, Star" <star.zeng@intel.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18360 6f19259b-4bc3-4df7-8a09-765794883524
Since SVN r18316 / git 5ca29abe52, the HTTP driver needs the HTTP
utilities driver to parse the headers of HTTP requests. Add the driver
into OVMF so that the HTTP driver can work properly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18359 6f19259b-4bc3-4df7-8a09-765794883524
Since Variable driver has been updated to consume the separated VarCheckLib.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18281 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek
Star Zeng
Stefano Stabellini
Michael Kinney
Gary Ching-Pang Lin
Ard Biesheuvel
Reza Jelveh
Jordan Justen