I find there is no variable driver in ovmf, can we add this driver in ovmf?
Just clarification, no Variable driver found in PEI phase.
It is correct, OVMF does not pull in the read-only variable driver PEIM. What do you need it for? Currently, OVMF has no need to read any variables in the PEI phase. If you have an OVMF feature or enhancement in mind, for upstream OvmfPkg/, that requires r/o variable access in the PEI phase, we can consider pulling in the PEIM. Otherwise, without an actual use case / client in the PEI phase, I don't think it should be pulled in. For example, if you have a PEIM that needs read access to variables, but you don't want to upstream that PEIM to upstream OvmfPkg/OvmfPkg*.dsc, then I think the variable PEIM should also be pulled in only in your local test environment. Thanks.
I plan to use OvmfPkg do some PEI test. the test cases will read Variable Pei. Thanks!
Thanks for confirming. In this case, as I proposed above, given that the dependent PEIMs will not be upstreamed, for the long term, to OvmfPkg in edk2, please pull in VariablePei too in your local test environment (where you add the PEIMs meant to be tested to the DSC / FDF files anyway). Thus, I'm closing this as INVALID -- without a direct / long term client for VariablePei, we should avoid fattening OVMF. The FV / FD space is quite scarce. I hope this is alright with you. Thanks!
I'm reopening this bug, because we have found an upstreamable use case for the variable PEIM -- UEFI memmap defragmentation.
This is being addressed as part of the following series: Subject: [PATCH 00/14] OvmfPkg: add the Variable PEIM, defragment the UEFI memmap Message-Id: <20170314233246.17864-1-lersek@redhat.com> URL: https://lists.01.org/pipermail/edk2-devel/2017-March/008525.html
Postponing this for now.
See also https://lists.01.org/pipermail/edk2-devel/2017-March/009049.html
v2: [edk2] [PATCH v2 0/8] OvmfPkg: add the Variable PEIM, defragment the UEFI memmap https://lists.01.org/pipermail/edk2-devel/2017-November/018305.html http://mid.mail-archive.com/20171130163029.19743-1-lersek@redhat.com
I'd like to close this as WONTFIX, but given that it blocks bug 594, I'm only moving it back to CONFIRMED.
Bug 594, which used to depend on this one, got ultimately solved without a dependency on PEI phase variable access. Many thanks to Marc-André Lureau and Stefan Berger again for that work. With bug 594 solved, and S4 support being practically irrelevant, there's no need to keep this BZ open. I'll be privately carrying the patches that I posted earlier.
Reopening, with a dependency on bug 2122. With OvmfPkg/OvmfPkg*.dsc officially lacking Xen support (in favor of OvmfPkg/OvmfXen.dsc), the patches posted earlier for this BZ should not affect Xen in any observable way, and should no longer be rejeced. http://mid.mail-archive.com/46ef6b76-568e-75e8-fe72-c09dfe584158@redhat.com https://edk2.groups.io/g/devel/message/46210
Keeping this open because pre-requisite bug 2122 is not blocked due to lack of capacity, but due to its planned schedule (bug 2122 should be fixed around Aug 2020, per bug 2122 comment 0). Also, dropping the dependency on bug 1086, because that bug has been moved to edk2-platforms. A reminder shall be here that OVMF will have to sanity-check the MemoryTypeInformation UEFI variable in the PEI phase, as 3rd party UEFI executables can write that variable, and bogus values maay prevent the platform from booting: CoreInitializeMemoryServices() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c] @ edfe16a6d9f8: >| 2264 // >| 2265 // Assert if a resource descriptor HOB for the memory region described by the PHIT was not found >| 2266 // >| 2267 ASSERT (Found); >| ... >| 2339 // >| 2340 // If no memory regions are found that are big enough to initialize the DXE core, then ASSERT(). >| 2341 // >| 2342 ASSERT (Length >= MinimalMemorySizeNeeded);
(I've moved bug 1086 back to the DXE Core, and reinstated the dependency.)
I'm dropping bug 1086 from the dependency list. Bug 1086 is a DoS for the firmware, if the OS tampers with the Memory Type Information variable. But such a DoS is not hard to recover from, in a virtual machine. (Delete / re-initialize the varstore on the host side.) Furthermore, the symptom described in bug 1086 is possible to trigger even without OS involvement. If the guest RAM size is sharply reduced between two cold boots, and the last cold boot used huge amounts of some memory type, the firmware might not boot anyway (regardless of OS involvement). I'm planning to submit a new version of this patch set, but this time, limited to SMM. This feature has security impact for SMM, per: A Tour Beyond BIOS Secure SMM Communication in the EFI Developer Kit II Memory Type Information is discussed (recommended) at length in the paper, plus the "Call for action" section in the end includes it in the summary: > Call for action > 1) A platform should check its own SMM communication buffer. > 2) The DXE agent should allocate a fixed communication buffer or use the EDKII_PI_SMM_COMMUNICATION_REGION_TABLE. > 3) The SMI handler should call SmmIsBufferOutsideSmmValid() to validate the communication buffer. > 4) A platform should enable Memory Type Information table. > 5) A platform should report the WSMT table to indicate the capability.
Also dropping bug 2122 from the dependency list. -D SMM_REQUIRE already requires QEMU/Q35 (it doesn't boot on Xen), and this BZ is now relevant specifically for SMM. In the past, Jordan has tried to detect pflash dynamically in the PEI phase, but in the PEI phase, OVMF is not in SMM, and so QEMU denies access to the pflash. Thus this feature needs to depend on static (build time) configuration.
Posted: * [edk2-devel] [PATCH 0/5] OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation http://mid.mail-archive.com/20200310222739.26717-1-lersek@redhat.com https://edk2.groups.io/g/devel/message/55726
(In reply to Laszlo Ersek from comment #17) > Posted: > > * [edk2-devel] [PATCH 0/5] > OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation > > http://mid.mail-archive.com/20200310222739.26717-1-lersek@redhat.com > https://edk2.groups.io/g/devel/message/55726 Merged as commit range 7d325f93e190..d42fdd6f8384, via <https://github.com/tianocore/edk2/pull/442>.
