summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* OvmfPkg: raise DXEFV size to 11 MBLaszlo Ersek2018-05-293-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Almost exactly two years after commit 2f7b34b20842f, we've grown out the 10MB DXEFV: > build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \ > -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D E1000_ENABLE \ > -D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE > > [...] > > GenFv: ERROR 3000: Invalid > the required fv image size 0xa28d48 exceeds the set fv image size > 0xa00000 Raise the DXEFV size to 11MB. (For builds that don't need this DXEFV bump, I've checked the FVMAIN_COMPACT increase stemming from the additional 1MB padding, using NOOPT + GCC48 + FD_SIZE_2MB, and no other "-D" flags. In the IA32 build, FVMAIN_COMPACT grows by 232 bytes. In the IA32X64 build, FVMAIN_COMPACT shrinks by 64 bytes. In the X64 build, FVMAIN_COMPACT shrinks by 376 bytes.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary 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: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
* SecurityPkg/Tcg2Smm: Correct function parameter attributeZhang, Chao B2018-05-291-4/+4
| | | | | | | | | | | | Correct UpdatePossibleResource parameter attribute to align to comment Change-Id: Id8f8be975f0e8666573decc3fbaaf326b7767ba8 Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Long Qin <qin.long@intel.com> Cc: Yao Jiewen <jiewen.yao@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com> Signed-off-by: Zhang, Chao B <chao.b.zhang@intel.com> Reviewed-by: Long Qin <qin.long@intel.com>
* QuarkPlatformPkg/PlatformFlashAccessLib: Add progress APIMichael D Kinney2018-05-281-8/+70
| | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=801 Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib. This allows the platform to inform the user of progress when a firmware storage device is being updated with a new firmware image. Cc: Kelly Steele <kelly.steele@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* QuarkPlatformPkg: Add DisplayUpdateProgressLib mappingKinney, Michael D2018-05-281-0/+1
| | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=801 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Kelly Steele <kelly.steele@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Vlv2TbltDevicePkg/PlatformFlashAccessLib: Add progress APIMichael D Kinney2018-05-282-28/+77
| | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=801 Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib. This allows the platform to inform the user of progress when a firmware storage device is being updated with a new firmware image. Cc: David Wei <david.wei@intel.com> Cc: Mang Guo <mang.guo@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: David Wei <david.wei@intel.com>
* Vlv2Tbl2DevicePkg: Add DisplayUpdateProgressLib mappingMichael D Kinney2018-05-283-0/+3
| | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=801 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: David Wei <david.wei@intel.com> Cc: Mang Guo <mang.guo@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: David Wei <david.wei@intel.com>
* SignedCapsulePkg/PlatformFlashAccessLib: Add progress APIMichael D Kinney2018-05-282-9/+110
| | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=801 Add a new API to the PlatformFlashAccessLib that passes in an optional Progress() function along with a start and end percentage to call the Progress() function with. If the Progress() function is not NULL, then it is the Progress() function that was passed into the Firmware Management Protocol SetImage() services and is used to update the user on the progress as a firmware device is updated with a firmware image. Implementations of the PlatformFlashAccessLib are recommended to call the Progress() function as work is performed to update to contents of a firmware storage device. Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg: Add DisplayUpdateProgressLib instancesMichael D Kinney2018-05-287-0/+801
| | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=801 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport Add DisplayUpdateProgressLib instances for text consoles and graphical consoles. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg: Add DisplayUpdateProgressLib classMichael D Kinney2018-05-283-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=801 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport Add the DisplayUpdateProgressLib class that is used to inform the user of progress during updates of firmware images in firmware devices. A platform specific instance of this library can be used to customize how the user is informed of progress. Add the EDK II Firmware Management Progress Protocol. This is an optional protocol that must be installed onto the same handle as a Firmware Management Protocol. This new protocol provides the color of a progress bar that allows different firmware devices to use different colors during a firmware update. It also provides a watchdog timer value in seconds that is armed each time the Progress() service passed into Firmware Management Protocol SetImage() is called. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* MdeModulePkg/PciBus: Do not enable MemWriteAndInvalidate bit for PCIERuiyu Ni2018-05-281-4/+6
| | | | | | | | | | Per PCIE spec, Memory Write and Invalidate is hardwired to 0b so PciBus driver shouldn't write 1b to it. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
* MdeModulePkg/PciBus: Remove unnecessary PCIE detectionRuiyu Ni2018-05-281-16/+1
| | | | | | | | | | | | | CreatePciIoDevice() detects whether the PCI device is a PCI Express device and remembers the device type in PciIoDevice->IsPciExp. RegisterPciDevice() detects the device type again which is unnecessary. The detection logic can be removed. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com>
* UefiCpuPkg/CpuCommonFeatures: Follow SDM for MAX CPUID feature detectRuiyu Ni2018-05-281-2/+2
| | | | | | | | | | | | | | | According to IA manual: "Before setting this bit (MSR_IA32_MISC_ENABLE[22]) , BIOS must execute the CPUID.0H and examine the maximum value returned in EAX[7:0]. If the maximum value is greater than 2, this bit is supported." We need to fix our current detection logic to compare against 2. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Ming Shao <ming.shao@intel.com>
* PcAtChipsetPkg/PcRtc: Add two new PCD for RTC Index/Target registersRuiyu Ni2018-05-285-12/+25
| | | | | | | | | | | | | | | | | In certain HW implementation, the BIT7 of RTC Index register(0x70) is for NMI sources enable/disable but the BIT7 of 0x70 cannot be read before writing. Software which doesn't want to change the NMI sources enable/disable setting can write to the alias register 0x74, through which only BIT0 ~ BIT6 of 0x70 is modified. So two new PCDs are added so that platform can have the flexibility to change the default RTC register addresses from 0x70/0x71 to 0x74/0x75. With the new PCDs added, it can also support special HW that provides RTC storage in a different register pairs. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* BaseTools: Rename String to StringUtils.Marvin.Haeuser@outlook.com2018-05-2842-43/+43
| | | | | | | | | | | | For case-insensitive file systems, edk2 String.py collides with the Python string.py, which results in build errors. This,for example, applies to building via the Windows Subsystem for Linux from a DriveFS file system. This patch renames String to StringUtils to prevent conflicts for case-insensitive file systems. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdePkg: Update MmSwDispatch.h's references to SmmSw2Dispatch.Marvin.Haeuser@outlook.com2018-05-281-3/+3
| | | | | | | | | | | | MmSwDispatch.h current refers to the deprecated SmmSw2Dispatch protocol. Replace those references with the new MmSwDispatch name. V2: - Do not change the copyright date as requested. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdePkg/Hpet: Add Event Timer Block ID definition.Marvin.Haeuser@outlook.com2018-05-281-0/+16
| | | | | | | | | | | | This patch adds the HPET Event Timer Block ID definition that can be found in the IA-PC HPET Specification, section 3.2.4. V2: - Do not change the copyright date as requested. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/GenFds: Remove redundant GetRealFileLine callZurcher, Christopher J2018-05-281-4/+3
| | | | | | | | | | | | | The EvaluateConditional function should not call GetRealFileLine because this is already done in Warning init and only needs to be calculated in the event of a parsing failure. This fix stops InsertedLines from being subtracted twice during error handling. Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zurcher, Christopher J <christopher.j.zurcher@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools: Add missing content to EOT tool.Jaben Carsey2018-05-282-1/+1460
| | | | | | | | Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools: loop to retry remove when it fails.Jaben Carsey2018-05-281-2/+10
| | | | | | | | | | | | | | There is a common race condition when the OS fails to release a file fast enough. this adds a retry loop. v2 - Add a timeout. Cc: Mike Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* MdeModulePkg/PciBus: Use actual max bus # for subordinary bus #Ruiyu Ni2018-05-251-1/+38
| | | | | | | | | | | | | | | | Current code assumes the max bus(0xFF) is under this P2P bridge and temporarily set it as subordinate bus. It may cause silicon hangs during PCI enumeration in some specific case. Instead, it should get the max bus number from the bus number resources returned from PCI_HOST_BRIDGE_RESOURCE_ALLOCATION.StartBusEnumeration() and set it as subordinate bus. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* EmulatorPkg/SmbiosLib: Declare the correct library class.Marvin Häuser2018-05-241-1/+1
| | | | | | | | | | | | Currently, SmbiosLib declares the PcdLib library class. Update the declaration to declare SmbiosLib. V2: - Do not change the copyright date as requested. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/Virtio10Dxe: convert to PciCapLibLaszlo Ersek2018-05-243-93/+53
| | | | | | | | | | | | | | | | | Replace the manual capability list parsing in OvmfPkg/Virtio10Dxe with PciCapLib and PciCapPciIoLib API calls. The VIRTIO_PCI_CAP_LINK structure type is now superfluous. (Well, it always has been; we should have used EFI_PCI_CAPABILITY_HDR.) Also, EFI_PCI_CAPABILITY_VENDOR_HDR is now included at the front of VIRTIO_PCI_CAP. No driver other than Virtio10Dxe relies on VIRTIO_PCI_CAP. 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/PciHotPlugInitDxe: convert to PciCapLibLaszlo Ersek2018-05-242-171/+103
| | | | | | | | | | | Replace the manual capability list parsing in OvmfPkg/PciHotPlugInitDxe with PciCapLib and PciCapPciSegmentLib API calls. 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>
* ArmVirtPkg: resolve PciCapLib, PciCapPciSegmentLib, PciCapPciIoLibLaszlo Ersek2018-05-241-0/+3
| | | | | | | | | | | | Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to their single respective instances under OvmfPkg. Later patches will use those lib classes in OvmfPkg drivers, some of which are included in ArmVirt platforms. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: resolve PciCapLib, PciCapPciSegmentLib, PciCapPciIoLibLaszlo Ersek2018-05-243-0/+9
| | | | | | | | | | | | Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to their single respective instances. Later patches will use these lib classes in OvmfPkg drivers. 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 PciCapPciIoLibLaszlo Ersek2018-05-245-0/+386
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-245-0/+395
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-245-0/+1540
| | | | | | | | | | | | | | 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>
* SecurityPkg/TcgStorage*Lib.h: Fix ECC reported issues.Eric Dong2018-05-243-8/+8
| | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* MdePkg/TcgStorage*.h: Fixed ECC reported issues.Eric Dong2018-05-242-5/+5
| | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* BaseTools/tools_def: add "-fno-unwind-tables" to GCC_AARCH64_CC_FLAGSLaszlo Ersek2018-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ElfConvert routines in GenFw don't handle the ".eh_frame" ELF section emitted by gcc. For this reason, Leif disabled the generation of that section for AARCH64 with "-fno-asynchronous-unwind-tables" in commit 28e80befa4fe [1], and Ard did the same for IA32 and X64 in commit 26ecc55c027d [2]. (The CLANG38 toolchain received the same flag at its inception, in commit 6f756db5ea05 [3].) However, ".eh_frame" is back now; in upstream gcc commit 9cbee213b579 [4] (part of tag "gcc-8_1_0-release"), both "-fasynchronous-unwind-tables" and "-funwind-tables" were made the default for AARCH64. (The patch author described the effects on the gcc mailing list [5].) We have to counter the latter flag with "-fno-unwind-tables", otherwise GenFw chokes on ".eh_frame" again (triggered for example on Fedora 28). "-f[no-]unwind-tables" goes back to at least gcc-4.4 [6], so it's safe to add to GCC_AARCH64_CC_FLAGS. [1] https://github.com/tianocore/edk2/commit/28e80befa4fe [2] https://github.com/tianocore/edk2/commit/26ecc55c027d [3] https://github.com/tianocore/edk2/commit/6f756db5ea05 [4] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9cbee213b579 [5] http://mid.mail-archive.com/7b28c03a-c032-6cec-c127-1c12cbe98eeb@foss.arm.com [6] https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Code-Gen-Options.html Cc: "Danilo C. L. de Paula" <ddepaula@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Cole Robinson <crobinso@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reported-by: "Danilo C. L. de Paula" <ddepaula@redhat.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: Liming Gao <liming.gao@intel.com>
* MdePkg/IndustryStandard: Add header file for SPMI ACPI tableHao Wu2018-05-231-0/+104
| | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=840 Add the header file for Service Processor Management Interface ACPI table definition. Cc: Younas Khan <pmdyounaskhan786@gmail.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* BaseTools/Workspace: Fix ValueChain setMarvin Haeuser2018-05-231-2/+2
| | | | | | | | | | | | | | | | Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain from a dict to a set, but also changed the (former) key type from a touple to two separate values, which was probably unintended and also breaks build for packages involving Structured PCDs, because add() only takes one argument. This commit changes the values back to touples. V2: - Removed a whitespace change. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* MdeModulePkg Variable: Fix XCODE5 varargs warningLiming Gao2018-05-232-2/+2
| | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=741 Change VariableGetBestLanguage() parameter type from BOOLEAN to UINTN Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Steven Shi <steven.shi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* IntelFrameworkPkg UefiLib: Fix XCODE5 varargs warningLiming Gao2018-05-231-1/+1
| | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=741 Change GetBestLanguage() parameter type from BOOLEAN to UINTN Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Steven Shi <steven.shi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdePkg UefiLib: Fix XCODE5 varargs warningLiming Gao2018-05-232-2/+2
| | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=741 Change GetBestLanguage() parameter type from BOOLEAN to UINTN Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Steven Shi <steven.shi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* 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-226-3/+1046
| | | | | | | | | | | | | | | | | | | | | | | | | 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/IndustryStandard: add QemuTpm.h headerMarc-André Lureau2018-05-221-0/+69
| | | | | | | | | Add some common macros and type definitions corresponding to the QEMU TPM interface. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLEMarc-André Lureau2018-05-225-0/+66
| | | | | | | | | | | 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>
* BaseTools: Enhance error message when file is not exist for GensecYonghong Zhu2018-05-221-0/+6
| | | | | | | | | | | | | | | When the file is not exist in workspace or packages path, current Gensec tool doesn't report exactly error message. FILE FV_IMAGE = 11111111-4CF1-42D8-A0C3-B3F60779dF4D { SECTION GUIDED A7717414-C616-4977-9420-844712A735BF { SECTION FV_IMAGE = TestPkg/Test.fd } } Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
* BaseTools: Report more clear error message when PCD type mismatchYunhua Feng2018-05-221-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Error message is not clear when PCD type defined in driver's Library is different with PCD type defined in DSC components or PCD type defined in DSC PCD section. Case as below: DSC: [PcdsFixedAtBuild] PcdToken.PcdCName | "A" [Components] TestPkg/TestDriver.inf { <PcdsPatchableInModule> PcdToken.PcdCName | "B" } Library: [Pcd] PcdToken.PcdCName Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools: Library PCD type will inherit from the driverYunhua Feng2018-05-221-0/+16
| | | | | | | | | | | | | If a PCD is not referenced in global PCD section of DSC file at all, but is referenced in module scope, then the default PCD type for libs should be the module scoped PCD type. Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=901 Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools: Fix bug PCD type in component is not same with Pcd sectionYunhua Feng2018-05-221-0/+2
| | | | | | | | | | | | | | | | | Per DSC spec 3.11 [Components] Sections: The PCD access methods (and storage methods) are selected on a platform basis - it is not permitted to have a PCD listed in one of the Pcd sections and use it differently in an individual module. For example, if a PCD is listed in a [PcdsFixedAtBuild] section, it is not permitted to list it in a <PcdsPatchableInModule> sub-section of an INF file. but current code doesn't report error for this case. Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=951 Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* SecurityPkg:Tcg2Smm: Update TcgNvs info after memory is allocatedZhang, Chao B2018-05-221-7/+12
| | | | | | | | | | | Update package format info in _PRS to TcgNvs after memory is allocated. Change-Id: Icfadb350e60d3ed2df332e92c257ce13309c0018 Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Yao Jiewen <jiewen.yao@intel.com> Cc: Long Qin <qin.long@intel.com> Signed-off-by: Zhang, Chao B <chao.b.zhang@intel.com> Reviewed-by: Long Qin <qin.long@intel.com>
* BaseTools: Separate HOST and PREFIX env for GCC tool chainLiming Gao2018-05-211-7/+8
| | | | | | | | | | | | | | The crossing GCC compiler may use the different path for make and gcc tool. So, GCC_HOST_BIN is introduced for make path. GCC5_BIN is still kept for gcc path. User needs to set GCC_HOST_BIN besides set GCC5_BIN env if the default make is not used. Normally, make is in the default system path. GCC_HOST_BIN is not required to be set. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com>
* IntelFrameworkPkg/UefiLib: Fix build fail caused by commit b6d5def2faDandan Bi2018-05-211-0/+1
| | | | | | | | | | | | | In commit b6d5def2faf56334128ea2f056356d7e3852831e when adding 'OUT' decorator for the parameter in AddUnicodeString(), it delete the function name by mistake. This patch is to fix this issue. CC: Marvin Haeuser <Marvin.Haeuser@outlook.com> CC: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdePkg/SmmPeriodicSmiLib: Get Periodic SMI Context More RobustlyRuiyu Ni2018-05-211-23/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PeriodicSmiDispatchFunction() in SmmPeriodicSmiLib may assert with "Bad CR signature". Currently, the SetActivePeriodicSmiLibraryHandler() function (invoked at the beginning of the PeriodicSmiDispatchFunction() function) attempts to locate the PERIODIC_SMI_LIBRARY_HANDLER_CONTEXT structure pointer for the current periodic SMI from a given EFI_SMM_PERIODIC_TIMER_REGISTER_CONTEXT (RegiserContext) structure pointer (using the CR macro). The RegisterContext structure pointer passed to the PeriodicSmiDispatchFunction() is assumed to point to the same RegisterContext structure address given to the SmmPeriodicTimerDispatch2 protocol Register() API in PeriodicSmiEnable(). However, certain SmmPeriodicTimerDispatch2 implementation may copy the RegisterContext to a local buffer and pass that address as the context to PeriodicSmiDispatchFunction() in which case usage of the CR macro to find the parent structure base fails. The patch uses the LookupPeriodicSmiLibraryHandler() function to find the PERIODIC_SMI_LIBRARY_HANDLER_CONTEXT structure pointer. This works even in this scenario since the DispatchHandle returned from the SmmPeriodicTimerDispatch2 Register() function uniquely identifies that registration. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.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>
* ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG devices againLaszlo Ersek2018-05-182-0/+130
| | | | | | | | | | | | | | | | | | Virtio RNG devices are never boot devices, so in commit ff1d0fbfbaec 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 ff1d0fbfbaec 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> Fixes: ff1d0fbfbaec55038ccf888759588fa4e21516f4 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-13 01:16:29 +0000