summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/Library
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/PlatformBootManagerLib: add missing report status code callArd Biesheuvel2018-05-292-0/+5
| | | | | | | | | | | Consumers of status code reports may rely on a status code to be reported when the ReadyToBoot event is signalled. For instance, FirmwarePerformanceDxe will fail to install the FPDT ACPI table in this case. So add the missing call. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg BasePciCapLib: Fix VS build failureLiming Gao2018-05-291-2/+2
| | | | | | | | | | | Fix VS warning C4244: 'function': conversion from 'UINT32' to 'UINT16', possible loss of data. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: remove whitespace after casts] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: introduce PciCapPciIoLibLaszlo Ersek2018-05-243-0/+323
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a library class, and a UEFI_DRIVER lib instance, that are layered on top of PciCapLib, and allow clients to plug an EFI_PCI_IO_PROTOCOL backend into PciCapLib, for config space access. (Side note: Although the UEFI spec says that EFI_PCI_IO_PROTOCOL_CONFIG() returns EFI_UNSUPPORTED if "[t]he address range specified by Offset, Width, and Count is not valid for the PCI configuration header of the PCI controller", this patch doesn't directly document the EFI_UNSUPPORTED error code, for ProtoDevTransferConfig() and its callers ProtoDevReadConfig() and ProtoDevWriteConfig(). Instead, the patch refers to "unspecified error codes". The reason is that in edk2, the PciIoConfigRead() and PciIoConfigWrite() functions [1] can also return EFI_INVALID_PARAMETER for the above situation. Namely, PciIoConfigRead() and PciIoConfigWrite() first call PciIoVerifyConfigAccess(), which indeed produces the standard EFI_UNSUPPORTED error code, if the device's config space is exceeded. However, if PciIoVerifyConfigAccess() passes, and we reach RootBridgeIoPciRead() and RootBridgeIoPciWrite() [2], then RootBridgeIoCheckParameter() can still fail, e.g. if the root bridge doesn't support extended config space (see commit 014b472053ae3). For all kinds of Limit violations in IO, MMIO, and config space, RootBridgeIoCheckParameter() returns EFI_INVALID_PARAMETER, not EFI_UNSUPPORTED. That error code is then propagated up to, and out of, PciIoConfigRead() and PciIoConfigWrite(). [1] MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c [2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c ) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PciCapPciSegmentLibLaszlo Ersek2018-05-243-0/+308
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a library class, and a BASE lib instance, that are layered on top of PciCapLib, and allow clients to plug a PciSegmentLib backend into PciCapLib, for config space access. (Side note: The "MaxDomain" parameter is provided because, in practice, platforms exist where a PCI Express device may show up on a root bridge such that the root bridge doesn't support access to extended config space. Earlier the same issue was handled for MdeModulePkg/PciHostBridgeDxe in commit 014b472053ae3. However, that solution does not apply to the PciSegmentLib class, because: (1) The config space accessor functions of the PciSegmentLib class, such as PciSegmentReadBuffer(), have no way of informing the caller whether access to extended config space actually succeeds. (For example, in the UefiPciSegmentLibPciRootBridgeIo instace, which could in theory benefit from commit 014b472053ae3, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() status code is explicitly ignored, because there's no way for the lib instance to propagate it to the PciSegmentLib caller. If the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() call fails, then DxePciSegmentLibPciRootBridgeIoReadWorker() returns Data with indeterminate value.) (2) There is no *general* way for any firmware platform to provide, or use, a PciSegmentLib instance in which access to extended config space always succeeds. In brief, on a platform where config space may be limited to 256 bytes, access to extended config space through PciSegmentLib may invoke undefined behavior; therefore PciCapPciSegmentLib must give platforms a way to prevent such access.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PciCapLibLaszlo Ersek2018-05-243-0/+1107
| | | | | | | | | | | | | | Add a library class, and a BASE lib instance, to work more easily with PCI capabilities in PCI config space. Functions are provided to parse capabilities lists, and to locate, describe, read and write capabilities. PCI config space access is abstracted away. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformBootManagerLib: process TPM PPI requestMarc-André Lureau2018-05-222-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Call Tcg2PhysicalPresenceLibProcessRequest() to process pending PPI requests from PlatformBootManagerAfterConsole(). Laszlo understanding of edk2 is that the PPI operation processing was meant to occur *entirely* before End-Of-Dxe, so that 3rd party UEFI drivers couldn't interfere with PPI opcode processing *at all*. He suggested that we should *not* call Tcg2PhysicalPresenceLibProcessRequest() from BeforeConsole(). Because, an "auth" console, i.e. one that does not depend on a 3rd party driver, is *in general* impossible to guarantee. Instead we could opt to trust 3rd party drivers, and use the "normal" console(s) in AfterConsole(), in order to let the user confirm the PPI requests. It will depend on the user to enable Secure Boot, so that the trustworthiness of those 3rd party drivers is ensured. If an attacker roots the guest OS from within, queues some TPM2 PPI requests, and also modifies drivers on the EFI system partition and/or in GPU option ROMs (?), then those drivers will not load after guest reboot, and thus the dependent console(s) won't be used for confirming the PPI requests. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add Tcg2PhysicalPresenceLibQemuMarc-André Lureau2018-05-223-0/+1043
| | | | | | | | | | | | | | | | | | | | | | | | | Cloned "SecurityPkg/Library/DxeTcg2PhysicalPresenceLib" and: - removed all the functions that are unreachable from Tcg2PhysicalPresenceLibProcessRequest() [called from platform BDS], or SubmitRequestToPreOSFunction() and ReturnOperationResponseToOsFunction() [called from Tcg2Dxe]. - replaced everything that's related to the TCG2_PHYSICAL_PRESENCE*_VARIABLE variables, with direct access to the QEMU structures. This commit is based on initial experimental work from Stefan Berger. In particular, he wrote most of QEMU PPI support, and designed the qemu/firmware interaction. Initially, Stefan tried to reuse the existing SecurityPkg code, but we eventually decided to get rid of the variables and simplify the ovmf/qemu version. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> [lersek@redhat.com: clean up non-idiomatic coding style] [lersek@redhat.com: null mPpi on invalid PPI address] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLEMarc-André Lureau2018-05-222-0/+60
| | | | | | | | | | | This NULL library will let us call Tcg2PhysicalPresenceLibProcessRequest() unconditionally from BdsPlatform when building without TPM2_ENABLE. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> [lersek@redhat.com: replace MdeModulePkg.dec w/ MdePkg.dec] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices againLaszlo Ersek2018-05-182-0/+106
| | | | | | | | | | | | | | | | | | | Virtio RNG devices are never boot devices, so in commit 245c643cc8b7 we stopped connecting them. This is a problem because an OS boot loader may depend on EFI_RNG_PROTOCOL to seed the OS's RNG. Connect Virtio RNG devices again. And, while commit 245c643cc8b7 removed that from PlatformBootManagerAfterConsole(), reintroduce it now to PlatformBootManagerBeforeConsole() -- this way Driver#### options launched between both functions may access EFI_RNG_PROTOCOL too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: 245c643cc8b73240c3b88cb55b2911b285a8c10d Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1579518 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformBootManagerLib: connect consoles unconditionallyLaszlo Ersek2018-05-141-83/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | If both ConIn and ConOut exist, but ConIn references none of the PS/2 keyboard, the USB wild-card keyboard, and any serial ports, then PlatformInitializeConsole() currently allows the boot to proceed without any input devices at all. This makes for a bad user experience -- the firmware menu could only be entered through OsIndications, set by a guest OS. Do what ArmVirtQemu does already, namely connect the consoles, and add them to ConIn / ConOut / ErrOut, unconditionally. (The underlying EfiBootManagerUpdateConsoleVariable() function checks for duplicates.) The issue used to be masked by the EfiBootManagerConnectAll() call that got conditionalized in commit 245c643cc8b7. This patch is best viewed with "git show -b -W". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: 245c643cc8b73240c3b88cb55b2911b285a8c10d Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1577546 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformBootManagerLib: add USB keyboard to ConInLaszlo Ersek2018-04-161-0/+32
| | | | | | | | | | | | | | | | | | | PlatformInitializeConsole() (called by PlatformBootManagerBeforeConsole()) adds elements of "gPlatformConsole" to ConIn / ConOut / ErrOut (as requested per element) if at boot at least one of ConIn and ConOut doesn't exist. This typically applies to new VMs, and VMs with freshly recreated varstores. Add a USB keyboard wildcard to ConIn via "gPlatformConsole", so that we not only bind the PS/2 keyboard. (The PS/2 keyboard is added in PrepareLpcBridgeDevicePath()). Explicitly connecting the USB keyboard is necessary after commit 245c643cc8b7. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/TlsAuthConfigLib: configure trusted cipher suites for HTTPS bootLaszlo Ersek2018-04-132-1/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Read the list of trusted cipher suites from fw_cfg and to store it to EDKII_HTTP_TLS_CIPHER_LIST_VARIABLE. The fw_cfg file will be formatted by the "update-crypto-policies" utility on the host side, so that the host settings take effect in guest HTTPS boot as well. QEMU forwards the file intact to the firmware. The contents are forwarded by NetworkPkg/HttpDxe (in TlsConfigCipherList()) to NetworkPkg/TlsDxe (TlsSetSessionData()) and TlsLib (TlsSetCipherList()). Note: the development of the "update-crypto-policies" feature is underway at this time. Meanwhile the following script can be used to generate the binary file for fw_cfg: export LC_ALL=C openssl ciphers -V \ | sed -r -n \ -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \ | xargs -r -- printf -- '%b' > ciphers.bin Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com> [lersek@redhat.com: update commit msg and add script as requested by Gary] [lersek@redhat.com: update commit msg as requested by Jiaxin]
* OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS bootLaszlo Ersek2018-03-302-0/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce TlsAuthConfigLib to read the list of trusted CA certificates from fw_cfg and to store it to EFI_TLS_CA_CERTIFICATE_VARIABLE. The fw_cfg file is formatted by the "p11-kit" and "update-ca-trust" utilities on the host side, so that the host settings take effect in guest HTTPS boot as well. QEMU forwards the file intact to the firmware. The contents are sanity-checked by NetworkPkg/HttpDxe code that was added in commit 0fd13678a681. Link TlsAuthConfigLib via NULL resolution into TlsAuthConfigDxe. This sets EFI_TLS_CA_CERTIFICATE_VARIABLE in time for both NetworkPkg/TlsAuthConfigDxe (for possible HII interaction with the user) and for NetworkPkg/HttpDxe (for the effective TLS configuration). The file formatted by "p11-kit" can be large. On a RHEL-7 host, the the Mozilla CA root certificate bundle -- installed with the "ca-certificates" package -- is processed into a 182KB file. Thus, create EFI_TLS_CA_CERTIFICATE_VARIABLE as a volatile & boot-time only variable. Also, in TLS_ENABLE builds, set the cumulative limit for volatile variables (PcdVariableStoreSize) to 512KB, and the individual limit for the same (PcdMaxVolatileVariableSize) to 256KB. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg:Fix VS2012 build failureDandan Bi2018-03-281-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Initialize local variable to suppress warning C4701/C4703: potentially uninitialized local variable/pointer variable. 1.In VirtualMemory.c: Read of "PageMapLevel4Entry" in SetMemoryEncDe() is only reached when "PageMapLevel4Entry" is got correctly. 2.In VirtioBlk.c: Reads (dereferences) of "BufferMapping" and "BufferDeviceAddress" in SynchronousRequest() are only reached if "BufferSize > 0" *and* we map the data buffer successfully. 3.In VirtioScsi.c: Reads (dereferences) of "InDataMapping" and "InDataDeviceAddress", in VirtioScsiPassThru() are only reached if "Packet->InTransferLength > 0" on input, *and* we map the input buffer successfully. The similar reason for "OutDataMapping" and "OutDataDeviceAddress". Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformBootManagerLib: process "-kernel" before boot devicesLaszlo Ersek2018-03-161-4/+4
| | | | | | | | | | | | | | | | | | This improves the UEFI boot time for VMs that have "-kernel", many disks or NICs, and no "bootindex" properties. (Unlike in ArmVirt commit 23d04b58e27b, in OvmfPkg commit 52fba28994e9 we introduced TryRunningQemuKernel() right from the start *after* BdsLibConnectAll(). Therefore, unlike in patch 'ArmVirtPkg/PlatformBootManagerLib: return to "-kernel before boot devices"', we adopt the logic as new in this patch.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
* OvmfPkg/PlatformBootManagerLib: hoist PciAcpiInitialization()Laszlo Ersek2018-03-161-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PlatformBootManagerAfterConsole() <--------------------------------+ PlatformBdsConnectSequence() | ConnectDevicesFromQemu() / EfiBootManagerConnectAll() | PciAcpiInitialization() ---------------------------------+ TryRunningQemuKernel() Functionally this is a no-op: - PciAcpiInitialization() iterates over PciIo protocol instances, which are available just the same at the new call site. - The PCI interrupt line register exists only to inform system software (it doesn't affect hardware) and UEFI drivers don't use PCI interrupts anyway. (More background in commits 2e70cf8ade0d and 5218c27950c4.) This change will let us move TryRunningQemuKernel() between PciAcpiInitialization() and PlatformBdsConnectSequence() in the next patch. Cc: "Gabriel L. Somlo" <gsomlo@gmail.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <gsomlo@gmail.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
* OvmfPkg/PlatformBootManagerLib: rejuvenate old-style function commentsLaszlo Ersek2018-03-161-102/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | The old-style "Routine Description: ..." comments use the leftmost column and are placed between the parameter list and the function body. Therefore they cause git-diff to produce bogus hunk headers that fail to name the function being patched. Convert these comment blocks to the current edk2 style. While at it, clean them up too. For PlatformBootManagerBeforeConsole() and PlatformBootManagerAfterConsole(), copy the descriptions from the call sites in "MdeModulePkg/Universal/BdsDxe/BdsEntry.c". They are more detailed than the comments in the lib class header "MdeModulePkg/Include/Library/PlatformBootManagerLib.h"; ArmVirtPkg already uses these comments. No functional changes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
* OvmfPkg/PlatformBootManagerLib: wrap overlong lines in "BdsPlatform.c"Laszlo Ersek2018-03-161-28/+51
| | | | | | | | | | | No functional changes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
* OvmfPkg/PciHostBridgeLib: clear PCI aperture vars for (re)initHeyi Guo2018-03-152-1/+10
| | | | | | | | | | | | | | | Use ZeroMem() to initialize (or re-initialize) all fields in temporary PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not mandatory but is helpful for future extension: when we add new fields to PCI_ROOT_BRIDGE_APERTURE and the default value of these fields can safely be zero, this code will not suffer from an additional change. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformBootManagerLib: minimize the set of connected devicesLaszlo Ersek2018-03-141-6/+10
| | | | | | | | | | | | | | Prefer ConnectDevicesFromQemu() to EfiBootManagerConnectAll(). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()Laszlo Ersek2018-03-141-2/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QemuBootOrderLib expects PlatformBootManagerLib to call the following triplet: (1) EfiBootManagerConnectAll(), (2) EfiBootManagerRefreshAllBootOption(), (3) SetBootOrderFromQemu(). This leads to bad performance, when many devices exist such that the firmware can drive them, but they aren't marked for booting in the "bootorder" fw_cfg file. Namely, (1) EfiBootManagerConnectAll() talks to all hardware, which takes long. Plus some DriverBindingStart() functions write NV variables, which is also slow. (For example, the IP config policy for each NIC is stored in an NV var that is named after the MAC). (2) EfiBootManagerRefreshAllBootOption() generates boot options from the protocol instances produced by (1). Writing boot options is slow. (3) Under the above circumstances, SetBootOrderFromQemu() removes most of the boot options produced by (2). Erasing boot options is slow. Introduce ConnectDevicesFromQemu() as a replacement for (1): only connect devices that the QEMU user actually wants to boot off of. (There's a slight loss of compatibility when a platform switches from EfiBootManagerConnectAll() to ConnectDevicesFromQemu(). EfiBootManagerConnectAll() may produce UEFI device paths that are unknown to QemuBootOrderLib (that is, for neither PCI- nor virtio-mmio-based devices). The BootOrderComplete() function lets such unmatched boot options survive at the end of the boot order. With ConnectDevicesFromQemu(), these options will not be auto-generated in the first place. They may still be produced by other means. SetBootOrderFromQemu() is not modified in any way; reordering+filtering boot options remains a separate task.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/QemuBootOrderLib: clean up translation of virtio-net over MMIOLaszlo Ersek2018-03-141-3/+3
| | | | | | | | | | | | | | | | | | | | The "/MAC(" suffix of the translated UEFI devpath prefix is unnecessary for matching, because the virtio-mmio base address in VenHwString is unique anyway. Furthermore, the partial string "MAC(" cannot be processed by ConvertTextToDevicePath(), which will become relevant later in this series. Remove "/MAC(". While at it, remove a bogus comment on PCI. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/QemuBootOrderLib: add missing EFIAPI specifiersLaszlo Ersek2018-03-141-0/+2
| | | | | | | | | | | | | | Public library APIs should be declared as EFIAPI. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/QemuBootOrderLib: wrap overlong lineLaszlo Ersek2018-03-141-1/+2
| | | | | | | | | | | | | | 81 characters is too many. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/VirtioMmioDeviceLib: improve style of mMmioDeviceProtocolTemplateLaszlo Ersek2018-03-131-1/+1
| | | | | | | | | | | | | In edk2, we spell "static" "STATIC", plus objects with static storage duration (esp. protocol templates) should be const-qualified (spelled "CONST") whenever possible. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/VirtioMmioDeviceLib: list "VirtioMmioDevice.h" in the INF fileLaszlo Ersek2018-03-131-0/+1
| | | | | | | | | | | | | | | | Among other things, the header file declares the functions that implement the VIRTIO_DEVICE_PROTOCOL members over virtio-mmio. The functions are defined in "VirtioMmioDeviceFunctions.c", and referenced in the initialization of "mMmioDeviceProtocolTemplate", in "VirtioMmioDevice.c". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/SerializeVariablesLib: list "SerializeVariablesLib.h" in INF fileLaszlo Ersek2018-03-131-0/+1
| | | | | | | | | | | | | | | The header file defines macros and types for "SerializeVariablesLib.c". Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/QemuBootOrderLib: list "ExtraRootBusMap.h" in the INF fileLaszlo Ersek2018-03-131-0/+1
| | | | | | | | | | | | | | | The header file declares the CreateExtraRootBusMap(), DestroyExtraRootBusMap(), and MapRootBusPosToBusNr() functions. They are defined in "ExtraRootBusMap.c", and called from "QemuBootOrderLib.c". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/QemuBootOrderLib: sort [Sources*] sections in the INF fileLaszlo Ersek2018-03-131-1/+1
| | | | | | | | | | | This makes it easier to insert future source files. No functional changes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformDebugLibIoPort: list "DebugLibDetect.h" in the INF filesLaszlo Ersek2018-03-132-0/+2
| | | | | | | | | | | | | | | | | Among other things, "DebugLibDetect.h" declares the PlatformDebugLibIoPortFound() function. The function is called from "DebugLib.c", which is included in both library instances. The function is defined separately per library instance, in "DebugLibDetectRom.c" and "DebugLibDetect.c", respectively. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/NvVarsFileLib: list "NvVarsFileLib.h" in the INF fileLaszlo Ersek2018-03-131-0/+1
| | | | | | | | | | | | | | | | The header file declares LoadNvVarsFromFs() and SaveNvVarsToFs(), which are defined in "FsAccess.c" and called from "NvVarsFileLib.c". Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/LockBoxLib: list "LockBoxLib.h" in the INF filesLaszlo Ersek2018-03-132-0/+2
| | | | | | | | | | | | | | | | | | | | | | Among other things, the header file declares the AllocateAcpiNvsPool() function. This function is called from the "LockBoxLib.c" source file (in the implementation of the SaveLockBox() library API), which is built into both library instances. AllocateAcpiNvsPool() is implemented separately per library instance, in "LockBoxBase.c" and "LockBoxDxe.c", respectively. (In the LockBoxBaseLib instance, the AllocateAcpiNvsPool() function is never expected to be called -- the public SaveLockBox() API should never be called before the DXE phase --, we just have to provide a stub for linking purposes.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/LoadLinuxLib: list "LoadLinuxLib.h" in the INF fileLaszlo Ersek2018-03-131-0/+1
| | | | | | | | | | | | | | | | | | | | The header file declares the InitLinuxDescriptorTables() and SetLinuxDescriptorTables() functions, which are called from "Linux.c" and implemented in "LinuxGdt.c". The header file also declares the JumpToKernel() and JumpToUefiKernel() functions, which are similarly called from "Linux.c". They are implemented (dependent on architecture) in "Ia32/JumpToKernel.nasm" and "X64/JumpToKernel.nasm". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/BaseMemEncryptSevLib: list "X64/VirtualMemory.h" in the INF fileLaszlo Ersek2018-03-131-0/+1
| | | | | | | | | | | | | | | | | | Among other things, the header file declares the InternalMemEncryptSevSetMemoryDecrypted() and InternalMemEncryptSevSetMemoryEncrypted() functions. The functions are called from "X64/MemEncryptSevLib.c", and defined in "X64/VirtualMemory.c". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/AcpiTimerLib: list "AcpiTimerLib.h" in the INF filesLaszlo Ersek2018-03-133-0/+3
| | | | | | | | | | | | | | | | | The header file declares the InternalAcpiGetTimerTick() function. The function is called from "AcpiTimerLib.c", which is built into all three library instances. The function is defined individually per library instance, in "BaseRomAcpiTimerLib.c", "BaseAcpiTimerLib.c", and "DxeAcpiTimerLib.c" (enumerated in increasing firmware phase order). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/SmmCpuFeaturesLib: SEV: encrypt+free pages of init. save state mapLaszlo Ersek2018-03-062-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Once PiSmmCpuDxeSmm relocates SMBASE for all VCPUs, the pages of the initial SMRAM save state map can be re-encrypted (including zeroing them out after setting the C-bit on them), and they can be released to DXE for general use (undoing the allocation that we did in PlatformPei's AmdSevInitialize() function). The decryption of the same pages (which will occur chronologically earlier) is implemented in the next patch; hence the "re-encryption" part of this patch is currently a no-op. The series is structured like this in order to be bisection-friendly. If the decryption patch preceded this patch, then an info leak would be created while standing between the patches. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: find pages of initial SMRAM save state mapLaszlo Ersek2018-03-062-0/+55
| | | | | | | | | | | | | | | | | | | | | In the next three patches, we're going to modify three modules under OvmfPkg. When OVMF is built with -D SMM_REQUIRE and runs in an SEV guest, each affected module will have to know the page range that covers the initial (pre-SMBASE relocation) SMRAM save state map. Add a helper function to MemEncryptSevLib that calculates the "base address" and "number of pages" constants for this page range. (In a RELEASE build -- i.e., with assertions disabled and optimization enabled --, the helper function can be compiled to store two constants determined at compile time.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/SmmCpuFeaturesLib: remove unneeded #includes and LibraryClassesLaszlo Ersek2018-03-062-3/+0
| | | | | | | | | | Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/SmmCpuFeaturesLib: sort #includes, and entries in INF file sectionsLaszlo Ersek2018-03-062-5/+5
| | | | | | | | | | Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/SmmCpuFeaturesLib: upper-case the "static" keywordLaszlo Ersek2018-03-061-4/+6
| | | | | | | | | | | | | In edk2, the "static" keyword is spelled "STATIC". Also let "STATIC" stand alone on a line in function definitions. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/SmmCpuFeaturesLib: rewrap to 79 columnsLaszlo Ersek2018-03-062-115/+489
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are many overlong lines; it's hard to work with the library like this. Rewrap all files to 79 columns. ( The rewrapping of the "mSmmCpuRegisterRanges" and "mSmmCpuWidthOffset" arrays was verified by hexdumping the arrays in SmmCpuFeaturesLibConstructor(), both before and after the patch, and comparing the dumps. Contents of "mSmmCpuRegisterRanges", IA32 build: > mSmmCpuRegisterRanges: { > mSmmCpuRegisterRanges: 000000 04 00 00 00 0A 00 00 00 07 00 00 00 14 00 00 00 > mSmmCpuRegisterRanges: 000010 2E 00 00 00 1B 00 00 00 33 00 00 00 36 00 00 00 > mSmmCpuRegisterRanges: 000020 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > mSmmCpuRegisterRanges: } Contents of "mSmmCpuRegisterRanges", X64 build: > mSmmCpuRegisterRanges: { > mSmmCpuRegisterRanges: 000000 04 00 00 00 0A 00 00 00 07 00 00 00 00 00 00 00 > mSmmCpuRegisterRanges: 000010 14 00 00 00 2E 00 00 00 1B 00 00 00 00 00 00 00 > mSmmCpuRegisterRanges: 000020 33 00 00 00 36 00 00 00 04 00 00 00 00 00 00 00 > mSmmCpuRegisterRanges: 000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > mSmmCpuRegisterRanges: } Contents of "mSmmCpuWidthOffset", both IA32 and X64 builds: > mSmmCpuWidthOffset: { > mSmmCpuWidthOffset: 000000 00 00 00 00 00 00 00 00 00 00 00 08 00 00 68 02 > mSmmCpuWidthOffset: 000010 6C 02 00 00 00 08 00 00 88 02 8C 02 00 00 00 08 > mSmmCpuWidthOffset: 000020 00 00 78 02 7C 02 00 00 00 00 00 00 64 02 68 02 > mSmmCpuWidthOffset: 000030 00 00 00 00 00 00 84 02 88 02 00 00 00 00 00 00 > mSmmCpuWidthOffset: 000040 74 02 78 02 00 00 00 00 00 00 00 00 04 00 00 00 > mSmmCpuWidthOffset: 000050 04 04 A8 03 00 02 00 00 00 00 04 04 AC 03 10 02 > mSmmCpuWidthOffset: 000060 00 00 00 00 04 04 B0 03 20 02 00 00 00 00 04 04 > mSmmCpuWidthOffset: 000070 B4 03 30 02 00 00 00 00 04 04 B8 03 40 02 00 00 > mSmmCpuWidthOffset: 000080 00 00 04 04 BC 03 50 02 00 00 00 00 00 04 00 00 > mSmmCpuWidthOffset: 000090 70 02 00 00 00 00 04 04 C4 03 90 02 00 00 00 00 > mSmmCpuWidthOffset: 0000A0 04 08 C8 03 60 03 64 03 00 00 04 08 CC 03 68 03 > mSmmCpuWidthOffset: 0000B0 6C 03 00 00 00 08 00 00 B8 03 BC 03 01 00 00 08 > mSmmCpuWidthOffset: 0000C0 00 00 B0 03 B4 03 01 00 00 08 00 00 A8 03 AC 03 > mSmmCpuWidthOffset: 0000D0 01 00 00 08 00 00 A0 03 A4 03 01 00 00 08 00 00 > mSmmCpuWidthOffset: 0000E0 98 03 9C 03 01 00 00 08 00 00 90 03 94 03 01 00 > mSmmCpuWidthOffset: 0000F0 00 08 00 00 88 03 8C 03 01 00 00 08 00 00 80 03 > mSmmCpuWidthOffset: 000100 84 03 01 00 04 08 D0 03 F8 03 FC 03 01 00 04 08 > mSmmCpuWidthOffset: 000110 DC 03 E0 03 E4 03 01 00 04 08 D4 03 F0 03 F4 03 > mSmmCpuWidthOffset: 000120 01 00 04 08 D8 03 E8 03 EC 03 01 00 04 08 E0 03 > mSmmCpuWidthOffset: 000130 D8 03 DC 03 01 00 04 08 E4 03 D0 03 D4 03 01 00 > mSmmCpuWidthOffset: 000140 04 08 E8 03 C8 03 CC 03 01 00 04 08 EC 03 C0 03 > mSmmCpuWidthOffset: 000150 C4 03 01 00 04 08 F0 03 78 03 7C 03 01 00 04 08 > mSmmCpuWidthOffset: 000160 F4 03 70 03 74 03 01 00 04 08 FC 03 58 03 5C 03 > mSmmCpuWidthOffset: 000170 00 00 04 08 F8 03 50 03 54 03 00 00 00 04 00 00 > mSmmCpuWidthOffset: 000180 48 03 4C 03 00 00 > mSmmCpuWidthOffset: } ) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: sort #includes, and entries in INF file sectionsLaszlo Ersek2018-03-066-12/+12
| | | | | | | | | | Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryEncrypted() ↵Laszlo Ersek2018-03-062-10/+14
| | | | | | | | | | | | | | | | | decl The declaration and the definition(s) of the function should have identical leading comments and/or identical parameter lists. Document the "Cr3BaseAddress" parameter, and correct several parameter references. Replace a "clear" reference to the C-bit with a "set" reference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryDecrypted() ↵Laszlo Ersek2018-03-062-8/+12
| | | | | | | | | | | | | | | | | decl The declaration and the definition(s) of the function should have identical leading comments and/or identical parameter lists. Document the "Cr3BaseAddress" parameter, and correct several parameter references. Replace a "set" reference to the C-bit with a "clear" reference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: clean up SetMemoryEncDec() comment blockLaszlo Ersek2018-03-061-3/+5
| | | | | | | | | | | | | Document the "Cr3BaseAddress" parameter, and correct several parameter references. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevSetPageEncMask() declLaszlo Ersek2018-03-062-25/+24
| | | | | | | | | | | | | | | | The declaration and the definition(s) of the function should have identical leading comments and/or identical parameter lists. Replace any leftover "clear" references to the C-bit with "set" references. Also remove any excess space in the comment block, and unindent the trailing "**/" if necessary. Correct several parameter references. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevClearPageEncMask() declLaszlo Ersek2018-03-062-21/+20
| | | | | | | | | | | | | | | The declaration and the definition(s) of the function should have identical leading comments and/or identical parameter lists. Also remove any excess space in the comment block, and unindent the trailing "**/" if necessary. Correct several parameter references. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevIsEnabled() declLaszlo Ersek2018-03-061-2/+1
| | | | | | | | | | | | | | | The declaration and the definition(s) of the function should have identical leading comments and/or identical parameter lists. Also remove any excess space in the comment block, and unindent the trailing "**/" if necessary. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: rewrap to 79 characters widthLaszlo Ersek2018-03-066-135/+241
| | | | | | | | | | | | | There are many overlong lines; it's hard to work with the library like this. Rewrap all files to 79 columns. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/BaseMemEncryptSevLib: Enable protection for newly added page tableBrijesh Singh2018-01-152-7/+399
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 2ac1730bf2a5 (MdeModulePkg/DxeIpl: Mark page table as read-only) sets the memory pages used for page table as read-only after paging is setup and sets CR0.WP to protect CPU modifying the read-only pages. The commit causes #PF when MemEncryptSevClearPageEncMask() or MemEncryptSevSetPageEncMask() tries to change the page-table attributes. This patch takes the similar approach as Commit 147fd35c3e38 (UefiCpuPkg/CpuDxe: Enable protection for newly added page table). When page table protection is enabled, we disable it temporarily before changing the page table attributes. This patch makes use of the same approach as Commit 2ac1730bf2a5 (MdeModulePkg/DxeIpl: Mark page table as read-only)) for allocating page table memory from reserved memory pool, which helps to reduce a potential "split" operation. The patch duplicates code from commit 147fd35c3e38. The code duplication will be removed after we implement page table manipulation library. See bugzilla https://bugzilla.tianocore.org/show_bug.cgi?id=847. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com>