summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)AuthorFilesLines
2016-01-07OvmfPkg: execute option ROM images regardless of Secure BootLaszlo Ersek3-0/+12
Change the image verification policy for option ROM images to 0x00 (ALWAYS_EXECUTE). While this may not be a good idea for physical platforms (see e.g. <https://trmm.net/Thunderstrike>), on the QEMU platform the benefits seem to outweigh the drawbacks: - For QEMU's virtual PCI devices, and for some assigned PCI devices, the option ROMs come from host-side files, which can never be rewritten from within the guest. Since the host admin has full control over a guest anyway, executing option ROMs that originate from host-side files presents no additional threat to the guest. - For assigned physical PCI devices with option ROMs, the argument is not so clear-cut. In theory a setup could exist where: - the host-side UEFI firmware (with DENY_EXECUTE_ON_SECURITY_VIOLATION) rejects the option ROM of a malicious physical PCI device, but - when the device is assigned to the guest, OVMF executes the option ROM in the guest, - the option ROM breaks out of the guest (using an assumed QEMU vulnerability) and gains QEMU user privileges on the host. However, in order to escalate as far as it would happen on the bare metal with ALWAYS_EXECUTE (i.e., in order to gain firmware-level access on the host), the malicious option ROM would have to break through (1) QEMU, (2) traditional UID and GID based privilege separation on the host, (3) sVirt (SELinux) on the host, (4) the host OS - host firmware boundary. This is not impossible, but not likely enough to discourage the use cases below. - This patch makes it possible to use unsigned iPXE network drivers that QEMU presents in the option ROMs of virtual NICs and assigned SR-IOV VFs, even if Secure Boot is in User Mode or Deployed Mode. - The change also makes it possible to execute unsigned, outdated (revoked), or downright malicious option ROMs of assigned physical devices in guests, for corporate, entertainment, academia, or security research purposes. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Chao Zhang <chao.b.zhang@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: Chao Zhang <chao.b.zhang@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19614 6f19259b-4bc3-4df7-8a09-765794883524
2016-01-07OvmfPkg: inherit Image Verification Policy defaults from SecurityPkgLaszlo Ersek3-21/+0
Secure Boot support was originally addded to OvmfPkg on 2012-Mar-09, in SVN r13093 (git 8cee3de7e9f4), titled OvmfPkg: Enable secure-boot support when SECURE_BOOT_ENABLE==TRUE At that time the image verification policies in SecurityPkg/SecurityPkg.dec were: - option ROM image: 0x00 (ALWAYS_EXECUTE) - removable media image: 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) - fixed media image: 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) The author of SVN r13093 apparently didn't want to depend on the SecurityPkg defaults for the latter two image origins, plus the ALWAYS_EXECUTE policy for option ROM images must have been deemed too lax. For this reason SVN r13093 immediately spelled out 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) within OvmfPkg for all three image origins. Fast forward to 2013-Aug-28: policy 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) had been forbidden in the UEFI spec, and SVN r14607 (git db44ea6c4e09) reflected this in the source code: - The policies for the latter two image origins were switched from 0x05 to 0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION) in SecurityPkg, - the patch changed the default policy for option ROM images too, from 0x00 (ALWAYS_EXECUTE) to 0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION), - any other client DSC files, including OvmfPkg's, underwent a whole-sale 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) -> 0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION) replacement too. The practical result of that patch for OvmfPkg was that the explicit 0x04 settings would equal the strict SecurityPkg defaults exactly. And that's what we have today: the "override the default values from SecurityPkg" comments in OvmfPkg's DSC files are stale, in practice. It is extremely unlikely that SecurityPkg would change the defaults from 0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION) any time in the future, so let's just inherit those in OvmfPkg. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19613 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-17OvfmPkg/XenHypercallLib: add missing GCC_ASM_EXPORT to XenHypercall2Ard Biesheuvel1-1/+2
GCC_ASM_EXPORT() not only exports a symbol as a function, it also emits a .type <xxx>, %function directive, which is used by the ARM linker to decide whether to emit interworking branches. So replace the explicit .global with GCC_ASM_EXPORT(), or the code will not be callable from Thumb-2 code. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19329 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-04OvmfPkg: Fix VS2015 warning C4459 in XenBusDxeLiming Gao1-7/+7
warning C4459: declaration of 'xs' hides global declaration. Update code to rename local variable xs to xsp to be different. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19116 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: replace README fine print about X64 SMM S3 with PlatformPei checkLaszlo Ersek3-5/+24
At the moment, the "UefiCpuPkg/Universal/Acpi/S3Resume2Pei" module doesn't support S3 resume if the platform has SMM enabled and the PEI phase is built for X64. We document this in the README, but it is not conspicuous enough. Replace the "fine print" in the README with a runtime check in PlatformPei. Cc: Jordan Justen <jordan.l.justen@intel.com> 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19070 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: README: document SMM statusLaszlo Ersek1-0/+57
Cc: Paolo Bonzini <pbonzini@redhat.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@19066 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: pull in SMM-based variable driver stackLaszlo Ersek6-12/+90
When -D SMM_REQUIRE is given, replace both - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and - OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf with - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf. The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and the rest: - the privileged half of the variable driver, VariableSmm, - the fault tolerant write driver, FaultTolerantWriteSmm, - and the FVB driver, FvbServicesSmm, work in SMM purely. We also resolve the BaseCryptLib class for DXE_SMM_DRIVER modules, for the authenticated VariableSmm driver's sake. 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@19065 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: consolidate variable driver stack in DSC and FDF filesLaszlo Ersek6-42/+66
The following modules constitute the variable driver stack: - QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime alternatives for providing the Firmware Volume Block(2) Protocol, dependent on qemu pflash presence, - FaultTolerantWriteDxe, providing the Fault Tolerant Write Protocol, - MdeModulePkg/Universal/Variable/RuntimeDxe, independently of -D SECURE_BOOT_ENABLE, providing the Variable and Variable Write Architectural Protocols. Let's move these drivers closer to each other in the DSC and FDF files, so that we can switch the variable driver stack to SMM with more local changes. 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@19064 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: QemuFlashFvbServicesRuntimeDxe: adhere to -D SMM_REQUIRELaszlo Ersek5-0/+11
When the user requires "security" by passing -D SMM_REQUIRE, and consequently by setting PcdSmmSmramRequire, enforce flash-based variables. Furthermore, add two ASSERT()s to catch if the wrong module were pulled into the build. 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@19063 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: QemuFlashFvbServicesRuntimeDxe: add DXE_SMM_DRIVER buildLaszlo Ersek2-0/+155
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@19062 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRELaszlo Ersek6-0/+18
At this point we can enable building PiSmmCpuDxeSmm. CPU specific features, like SMRR detection, and functions that are used to initialize SMM and process SMIs, are abstracted through the SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our own implementation under OvmfPkg -- it allows PiSmmCpuDxeSmm to work with QEMU's and KVM's 64-bit state save map format, which follows the definition from AMD's programmer manual. SmmCpuPlatformHookLib provides platform specific functions that are used to initialize SMM and process SMIs. Resolve it to the one Null instance provided by UefiCpuPkg, which is expected to work for most platforms. Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [pbonzini@redhat.com: resolve the SmmCpuFeaturesLib class to OVMF's own instance] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19061 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: build CpuS3DataDxe for -D SMM_REQUIRELaszlo Ersek6-0/+6
The PiSmmCpuDxeSmm driver from UefiCpuPkg depends on the ACPI_CPU_DATA structure -- created by a platform- and CPU-specific driver -- in order to support ACPI S3. The address of this structure is communicated through the dynamic PCD PcdCpuS3DataAddress. The "UefiCpuPkg/Include/AcpiCpuData.h" header file documents the fields of this structure in detail. The simple/generic "UefiCpuPkg/CpuS3DataDxe" driver creates and populates the structure in a conformant way, and it co-operates well with PiSmmCpuDxeSmm, for OVMF's purposes. PlatformBdsLib CpuS3DataDxe PiSmmCpuDxeSmm S3Resume2Pei (DXE_DRIVER) (DXE_DRIVER) (DXE_SMM_DRIVER) (PEIM) -------------- --------------- ---------------- -------------- normal collects data boot except MTRR settings into ACPI_CPU_DATA sets PcdCpuS3Da... signals End-of-Dxe | +----------> collects MTRR settings into ACPI_CPU_DATA installs [Dxe]Smm ReadyToLock | +---------------------------> fetches PcdCpuS3Dat... copies ACPI_CPU_DATA into SMRAM runtime S3 suspend S3 transfers resume control to PiSmmCpuDxe... | uses <----+ ACPI_CPU_DATA from SMRAM Cc: Jordan Justen <jordan.l.justen@intel.com> 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: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19060 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: any AP in SMM should not wait for the BSP for more than 100 msLaszlo Ersek3-0/+3
This patch complements the previous one, "OvmfPkg: use relaxed AP SMM synchronization mode". While that patch focuses on the case when the SMI is raised synchronously by the BSP, on the BSP: BSPHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] SmmWaitForApArrival() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c] this patch concerns itself with the case when it is one of the APs that raises (and sees delivered) the synchronous SMI: APHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c] Namely, in APHandler() the AP waits for the BSP to enter SMM regardless of PcdCpuSmmSyncMode, for PcdCpuSmmApSyncTimeout microseconds (the default value is 1 second). If the BSP doesn't show up in SMM within that interval, then the AP brings it in with a directed SMI, and waits for the BSP again for PcdCpuSmmApSyncTimeout microseconds. Although during boot services, SmmControl2DxeTrigger() is only called by the BSP, at runtime the OS can invoke runtime services from an AP (it can even be forced with "taskset -c 1 efibootmgr"). Because on QEMU SmmControl2DxeTrigger() only raises the SMI for the calling processor (BSP and AP alike), the first interval above times out invariably in such cases -- the BSP never shows up before the AP calls it in. In order to mitigate the performance penalty, decrease PcdCpuSmmApSyncTimeout to one tenth of its default value: 100 ms. (For comparison, Vlv2TbltDevicePkg sets 1 ms.) NOTE: once QEMU becomes capable of synchronous broadcast SMIs, this patch and the previous one ("OvmfPkg: use relaxed AP SMM synchronization mode") should be reverted, and SmmControl2DxeTrigger() should be adjusted instead. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> 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: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19059 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: use relaxed AP SMM synchronization modePaolo Bonzini3-0/+12
Port 0xb2 on QEMU only sends an SMI to the currently executing processor. The SMI handler, however, and in particular SmmWaitForApArrival, currently expects that SmmControl2DxeTrigger triggers an SMI IPI on all processors rather than just the BSP. Thus all SMM invocations loop for a second (the default value of PcdCpuSmmApSyncTimeout) before SmmWaitForApArrival sends another SMI IPI to the APs. With the default SmmCpuFeaturesLib, 32-bit machines must broadcast SMIs because 32-bit machines must reset the MTRRs on each entry to system management modes (they have no SMRRs). However, our virtual platform does not have problems with cacheability of SMRAM, so we can use "directed" SMIs instead. To do this, just set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode to 1 (aka SmmCpuSyncModeRelaxedAp). This fixes SMM on multiprocessor virtual machines. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19058 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: SmmCpuFeaturesLib: customize state save map formatPaolo Bonzini3-23/+212
This adjusts the previously introduced state save map access functions, to account for QEMU and KVM's 64-bit state save map following the AMD spec rather than the Intel one. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [lersek@redhat.com: reflow commit message, convert patch to CRLF] Cc: Paolo Bonzini <pbonzini@redhat.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@19057 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: SmmCpuFeaturesLib: implement SMRAM state save map accessPaolo Bonzini2-3/+376
This implementation copies SMRAM state save map access from the PiSmmCpuDxeSmm module. The most notable change is: - dropping support for EFI_SMM_SAVE_STATE_REGISTER_IO - changing the implementation of EFI_SMM_SAVE_STATE_REGISTER_LMA to use the SMM revision id instead of a local variable (which UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c initializes from CPUID's LM bit). This accounts for QEMU's implementation of x86_64, which always uses revision 0x20064 even if the LM bit is zero. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [lersek@redhat.com: reflow commit message & fix typo, convert patch to CRLF] Cc: Paolo Bonzini <pbonzini@redhat.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@19056 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: SmmCpuFeaturesLib: remove unnecessary bitsPaolo Bonzini2-220/+17
SMRR, MTRR, and SMM Feature Control support is not needed on a virtual platform. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: insert space between ASSERT and (), convert to CRLF, refresh against SVN r18958] Cc: Paolo Bonzini <pbonzini@redhat.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@19055 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: import SmmCpuFeaturesLib from UefiCpuPkgPaolo Bonzini2-0/+697
The next patches will customize the implementation, but let's start from the common version to better show the changes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [lersek@redhat.com: drop UNI file, keep whitespace intact, generate new FILE_GUID, split off DSC changes, reflow commit message, refresh against SVN r18958] Cc: Paolo Bonzini <pbonzini@redhat.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@19054 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection to FALSELaszlo Ersek3-0/+3
Explanation from Michael Kinney: This PCD allows a platform to provide PlatformSmmBspElection() in a platform specific SmmCpuPlatformHookLib instance to decide which CPU gets elected to be the BSP in each SMI. The SmmCpuPlatformHookLibNull [instance] always returns EFI_NOT_READY for that function, which makes the module behave the same as the PCD being set to FALSE. The default is TRUE, so the platform lib is always called, so a platform developer can implement the hook function and does not have to also change a PCD setting for the hook function to be active. A platform that wants to eliminate the call to the hook function [altogether] can set the PCD to FALSE. So for OVMF, I think it makes sense to set this PCD to FALSE in the DSC file. Suggested-by: 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19053 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: select LocalApicLib instance with x2apic supportLaszlo Ersek3-3/+3
Although neither LocalApicLib instance is suitable for runtime DXE drivers (because they access the APIC at the physical address retrieved from either MSR_IA32_APIC_BASE_ADDRESS or PcdCpuLocalApicBaseAddress), they are suitable for SMM drivers -- SMM drivers are not influenced by the runtime OS's virtual address map. PiSmmCpuDxeSmm links against LocalApicLib. 64-bit Linux guests tend to enable x2apic mode even in simple VCPU configurations (e.g., 4 sockets, 1 core/socket, 1 thread/core): [ 0.028173] x2apic enabled If PiSmmCpuDxeSmm was linked with the BaseXApicLib instance (i.e., with no x2apic support), then the next runtime service call that is backed by an SMM driver triggers the following ASSERT in BaseXApicLib (because the latter notices that x2apic has been enabled, which it doesn't support): ASSERT .../UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c(263): ApicBaseMsr.Bits.Extd == 0 It is reasonable to give all LocalApicLib client modules in OVMF the same level of x2apic support, hence resolve LocalApicLib globally to BaseXApicX2ApicLib. This will not be conditional on -D SMM_REQUIRE, because BaseXApicX2ApicLib is compatible with BaseXApicLib in any environment where the latter can be used. 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@19052 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: resolve DebugAgentLib for DXE_SMM_DRIVER modulesMichael Kinney3-0/+9
Add mappings to DebugAgentLib for SMM modules to prevent build breaks when SMM_REQUIRE and SOURCE_DEBUG_ENABLE are both set. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> [lersek@redhat.com: cover the X64 dsc, update commit msg, kudos Jordan] 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: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19051 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modulesLaszlo Ersek3-0/+3
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
2015-11-30OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modulesLaszlo Ersek3-0/+3
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
2015-11-30OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRELaszlo Ersek6-0/+51
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
2015-11-30OvmfPkg: PlatformPei: don't allocate fake lockbox if SMM_REQUIRELaszlo Ersek1-19/+21
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
2015-11-30OvmfPkg: LockBoxLib: -D SMM_REQUIRE excludes our fake lockboxLaszlo Ersek3-0/+8
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
2015-11-30OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRELaszlo Ersek2-7/+10
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
2015-11-30OvmfPkg: pull in CpuIo2Smm driverLaszlo Ersek6-0/+60
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
2015-11-30OvmfPkg: pull in the SMM IPL and SMM coreLaszlo Ersek6-0/+90
"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
2015-11-30OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVERLaszlo Ersek8-0/+438
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
2015-11-30OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXELaszlo Ersek8-0/+238
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
2015-11-30OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEILaszlo Ersek10-0/+766
"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
2015-11-30OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire setLaszlo Ersek3-1/+41
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
2015-11-30OvmfPkg: PlatformPei: allow caching in AddReservedMemoryBaseSizeHob()Laszlo Ersek3-3/+11
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
2015-11-30OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is setLaszlo Ersek5-4/+57
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
2015-11-30OvmfPkg: Sec: assert the build-time calculated end of the scratch bufferLaszlo Ersek8-3/+93
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
2015-11-30OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler tableLaszlo Ersek2-0/+15
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
2015-11-30OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequireLaszlo Ersek4-0/+22
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
2015-11-26OvmfPkg XenConsoleSerialPortLib: Implement Get(Set)Control/SetAttributesStar Zeng1-0/+95
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> 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@18972 6f19259b-4bc3-4df7-8a09-765794883524
2015-10-26OvmfPkg: QemuFlashFvbServicesRuntimeDxe: clean up includes and librariesLaszlo Ersek4-26/+13
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
2015-10-26OvmfPkg: QemuFlashFvbServicesRuntimeDxe: split out runtime DXE specificsLaszlo Ersek7-131/+209
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
2015-10-26OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing neededLaszlo Ersek2-69/+30
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
2015-10-26OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbScratchSpace fieldLaszlo Ersek2-3/+0
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
2015-10-26OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbDevLock fieldLaszlo Ersek2-2/+0
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
2015-10-26OvmfPkg: QemuFlashFvbServicesRuntimeDxe: fix VALID_ARCHITECTURES in INFLaszlo Ersek1-1/+1
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
2015-10-26OvmfPkg: QemuFlashFvbServicesRuntimeDxe: rewrap source code to 79 charsLaszlo Ersek6-292/+347
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
2015-10-26OvmfPkg: QemuFlashFvbServicesRuntimeDxe: strip trailing whitespaceLaszlo Ersek3-19/+19
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@18665 6f19259b-4bc3-4df7-8a09-765794883524
2015-10-21OvmfPkg: XenPvBlkDxe: handle empty cdrom drivesStefano Stabellini1-0/+15
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
2015-10-16OvmfPkg: VirtioBlkDxe: reset device at ExitBootServices()Laszlo Ersek2-1/+44
(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
2015-10-16OvmfPkg: VirtioScsiDxe: reset device at ExitBootServices()Laszlo Ersek2-2/+39
(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
generated by cgit v1.1 at 2024-11-13 08:44:41 +0000