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
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
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
The current types of subexpressions used in QemuFlashPtr() are as follows.
(We also show the types of "larger" subexpressions, according to operator
binding.)
mFlashBase + (Lba * mFdBlockSize) + Offset
^ ^ ^ ^
| | | |
(UINT8*) EFI_LBA UINTN UINTN
(UINT64)
--------------------------------- ------
(UINT8*) UINTN
------------------------------------------
(UINT8*)
When building with VS2010 for Ia32 / NOOPT, the 64-by-32 bit
multiplication is translated to an intrinsic, which is not allowed in
edk2.
Recognize that "Lba" is always bounded by "mFdBlockCount" (an UINTN) here
-- all callers of QemuFlashPtr() ensure that. In addition, the flash chip
in question is always under 4GB, which is why we can address it at all on
Ia32. Narrow "Lba" to UINTN, without any loss of range.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
[commit message by lersek@redhat.com]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16384 6f19259b-4bc3-4df7-8a09-765794883524
When QemuFlashWrite() is asked to write a range that includes the last
byte of the LBA, then the byte that the function uses to switch the flash
device back to read mode (ROMD mode in KVM speak) actually falls out of
the LBA.
Normally this doesn't cause visible problems. However, if the variable
store and the firmware code are backed by separate flash devices, as
implemented by
[Qemu-devel] [PATCH v2] hw/i386/pc_sysfw: support two flash drives
http://thread.gmane.org/gmane.comp.emulators.qemu/243678
plus
[edk2] [edk2 PATCH] OvmfPkg: split the variable store to a separate file
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/5045/focus=5046
then the READ_ARRAY_CMD not only reaches a different LBA, it reaches a
different qemu device. This results in a guest reboot soon after.
Fix this by ensuring that we always stay within the LBA just written when
issuing READ_ARRAY_CMD.
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@14996 6f19259b-4bc3-4df7-8a09-765794883524
If QEMU flash is detected, this module will install
FirmwareVolumeBlock support for the QEMU flash device.
It will also set PCDs with the results that:
1. OvmfPkg/EmuVariableFvbRuntimeDxe will be disabled
2. MdeModulePkg variable services will read/write flash directly
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14839 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek
Scott Duplichan
Jordan Justen