CryptoPkg/TlsLib: Remove the redundant free of BIO objects
TLS BIO objects (InBio/OutBio) will be freed by SSL_free() function.
So, the following free operation (BIO_free) in TlsFree is redundant.
It can be removed directly.
Cc: Ye Ting <ting.ye@intel.com> Cc: Long Qin <qin.long@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
NetworkPkg/Ip6Dxe: Fix the IPv6 PXE boot option goes missing issue
This patch is to fix the potential issue recorded at Bugzilla 636:
https://bugzilla.tianocore.org/show_bug.cgi?id=636
The issue is caused by the IPv6 policy switching after PXEv6 boot. When IP
policy is changing, the IPv6 children used by PXE.UdpRead() will be destroyed.
Then, PXE Stop() function is called to uninstall the devicePath protocol,
which leads to the IPv6 PXE boot option goes missing.
Through the above analysis, the IP driver should take the responsibility for
the upper layer network stacks recovery by using ConnectController().
Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Cc: Subramanian Sriram <sriram-s@hpe.com> Cc: Ni Ruiyu <ruiyu.ni@intel.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Reviewed-by: Subramanian Sriram <sriram-s@hpe.com> Tested-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Star Zeng [Fri, 28 Jul 2017 02:05:19 +0000 (10:05 +0800)]
MdeModulePkg FirmwarePerfPei: Remove SEC performance data getting code
Current SEC performance data getting code in FirmwarePerformancePei
may get wrong SEC performance data if FirmwarePerformancePei executes
after memory discovered.
And as SecCore has added SecPerformancePpiCallBack to get SEC performance
data and build HOB to convey the SEC performance data to DXE phase.
This patch is to remove the SEC performance data getting code in
FirmwarePerformancePei.
Star Zeng [Fri, 28 Jul 2017 02:05:08 +0000 (10:05 +0800)]
UefiCpuPkg SecCore: Add SecPerformancePpiCallBack
Add SecPerformancePpiCallBack to get SEC performance data and
build HOB to convey the SEC performance data to DXE phase.
Cc: Liming Gao <liming.gao@intel.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Star Zeng [Fri, 28 Jul 2017 14:13:00 +0000 (22:13 +0800)]
UefiCpuPkg SecCore: Adjust PeiTemporaryRamBase&Size to be 8byte aligned
As HOB which has 8byte aligned requirement will be built based on them
in PEI phase.
Cc: Liming Gao <liming.gao@intel.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Star Zeng [Fri, 28 Jul 2017 03:44:54 +0000 (11:44 +0800)]
MdeModulePkg PiSmmCoreMemoryAllocLib: Fix a FreePool() assertion issue
When PiSmmCore links against PeiDxeDebugLibReportStatusCode, the code
flow below will cause a FreePool() assertion issue.
PiSmmCoreMemoryAllocationLibConstructor() ->
SmmInitializeMemoryServices() ->
DEBUG ((DEBUG_INFO, "SmmAddMemoryRegion\n")) in SmmAddMemoryRegion() ->
DebugPrint() -> REPORT_STATUS_CODE_EX() -> ReportStatusCodeEx() ->
AllocatePool()/FreePool(PiSmmCoreMemoryAllocLib) ->
ASSERT() at Head = CR (Buffer, POOL_HEAD, Data, POOL_HEAD_SIGNATURE)
in CoreFreePoolI() of DxeCore Pool.c
It is because at the point of FreePool() in the code flow above,
mSmmCoreMemoryAllocLibSmramRanges/mSmmCoreMemoryAllocLibSmramRangeCount
are not been initialized yet, the FreePool() will be directed to
gBS->FreePool(), that is wrong.
This patch is to temporarily use BootServicesData to hold the
SmramRanges data before calling SmmInitializeMemoryServices().
BaseTools: Fix the bug to correctly check Pcd type that in FDF file
We set Pcd value in FDF and used this Pcd as PatchableInModule type in
module, it cause build report generate failure. because we incorrectly
set the Pcd type during check whether the Pcd is used.
Ruiyu Ni [Thu, 27 Jul 2017 03:05:16 +0000 (11:05 +0800)]
MdeModulePkg/PciBus: Avoid hang when BUS pad resource is not in top
PciScanBus() assumes the GetResourcePadding() puts BUS descriptor
in the very beginning, if it's not, the Descriptors will be updated
to point to middle of the pool buffer, which can cause
FreePool(Descriptors) hang in DEBUG image.
No functionality impact to RELEASE image.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Ruiyu Ni [Wed, 26 Jul 2017 08:21:54 +0000 (16:21 +0800)]
ShellPkg: Avoid buffer out-of-bound access
PathSize is the number of bytes in PathForReturn buffer so
PathForReturn[PathSize - 1] incorrectly accesses the last
character in the buffer,
PathForReturn[PathSize / sizeof (CHAR16) - 1] should be used.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Steven Shi <steven.shi@intel.com>
Star Zeng [Thu, 20 Jul 2017 06:47:28 +0000 (14:47 +0800)]
MdePkg: Follow UEFI 2.7 spec to deprecate SMM Communication ACPI Table
Delete PiSmmCommunicationAcpiTable.h and delete SMM Communication ACPI
Table definition in UefiAcpiDataTable.h.
As EFI_SMM_COMMUNICATE_HEADER is defined in both PI spec vol 4
and UEFI spec, move its definition to SmmCommunication.h.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Star Zeng [Thu, 20 Jul 2017 06:57:12 +0000 (14:57 +0800)]
UefiCpuPkg PiSmmCommunicationSmm: Deprecate SMM Communication ACPI Table
Follow UEFI 2.7 spec to deprecate SMM Communication ACPI Table,
PiSmmCommunicationSmm will not install SMM Communication ACPI Table
anymore.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
MdeModulePkg/BMMUiLib: Check reset requirement before exiting UiApp
V2: Refine the comments.
In UI page, some configuration change may require system reset.
BootMaintenanceManagerUiLib misses this check before exiting UiApp
to boot other boot options. Now add the check.
MdeModulePkg/BMUiLib: Check reset requirement before exiting UiApp
V2: Refine the comments.
In UI page, some configuration change may require system reset.
BootManagerUiLib misses this check before exiting UiApp to boot
other boot options. Now add the check.
MdeModulePkg/SetupBrowser: Record the reset status in all SendForm
After calling SendForm to enter front page, configuration change in some
driver may require system reset. Currently the reset status is saved in
SendForm level. Then SendForm can return the reset status.
IsResetRequired API also can return the reset status before exiting browser.
It return the reset status in current SendForm level now. But SendForm can
be recursive called by some module.so the reset status in previous SendForm
may be lost. Now change the IsResetRequired API to return the reset info no
matter the reset is caught in any SendForm.
But for other case, PcdMaxVariableSize is also required with the value
of 0x2000 (e,g. NetworkPkg/IScsiDxe), so remove the condition of
PcdMaxVariableSize for NT32 platform.
4.10.2.4 Babble Detected Error
When a device transmits more data on the USB than the host controller
is expecting for a transaction, it is defined to be babbling.
In general, this is called a Babble Error. When a device sends more
data than the TD Transfer Size bytes (TD Babble), unexpected activity
that persists beyond a specified point in a (micro)frame (Frame Babble),
or a packet greater than Max Packet Size (Packet Babble), the host
controller shall set the Babble Detected Error in the Completion Code
field of the TRB, generate an Error Event, and halt the endpoint
(refer to Section 4.10.2.1).
This patch is to also check for EFI_USB_ERR_BABBLE error returned as
a TransferResult and then proceed to XhcRecoverhaltedEndPoint.
Cc: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Currently, SmmCommunciate fails in RestoreLockBox after
SmmReadyToLock since COMM buffer is in stack instead of
using SmmCommRegion by gEdkiiPiSmmCommunicationRegionTableGuid.
This patch is to get SmmCommRegion by
gEdkiiPiSmmCommunicationRegionTableGuid for COMM buffer
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Baraneedharan Anbazhagan <anbazhagan@hp.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Ruiyu Ni [Wed, 19 Jul 2017 09:14:28 +0000 (17:14 +0800)]
MdePkg/ResetNotification: Rename to UnregisterResetNotify
UEFI Spec uses UnRegisterResetNotify in protocol structure
definition but uses UnregisterResetNotify in the function
prototype definition.
By searching the entire spec, Unregister* is used for
SIMPLE_TEXT_INPUT_EX_PROTOCOL.UnregisterKeyNotify(). So choose
to use UnregisterResetNotify for consistency.
Star Zeng [Wed, 19 Jul 2017 10:16:31 +0000 (18:16 +0800)]
MdePkg UsbFunctionIo.h: Update comments for GetDeviceInfo return status
UEFI spec 2.6 errata B update Status Codes Returned table of the
EFI_USBFN_IO_PROTOCOL.GetDeviceInfo function as follows:
1. Update EFI_INVALID_PARAMETER description:
Original text:
A parameter is invalid.
New text:
One or more of the following conditions is TRUE:
BufferSize is NULL.
*BufferSize is not 0 and Buffer is NULL.
Id in invalid.
2. Update EFI_BUFFER_TOO_SMALL description:
Original text:
Supplied buffer isn’t large enough to hold the request string.
New text:
The buffer is too small to hold the buffer.
*BufferSize has been updated with the size needed to hold the
request string.
Eric Dong [Thu, 20 Jul 2017 05:46:12 +0000 (13:46 +0800)]
UefiCpuPkg: Remove deprecated CPU feature.
Senter feature could not be a single feature,
it has been merge to Smx feature, so remove it.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Eric Dong [Wed, 19 Jul 2017 02:34:59 +0000 (10:34 +0800)]
MdeModulePkg SmmAccess: Update comments to follow PI spec.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Eric Dong [Wed, 19 Jul 2017 02:32:38 +0000 (10:32 +0800)]
MdePkg SmmAccess2: Update comments to follow PI spec.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The patch fixes two kinds of bugs in DxeCore that accesses memory
which might be freed or owned by other modules.
The two bugs don't cause functionality issue.
1. CoreValidateHandle() checks whether the handle is valid by
validating its signature. The proper way is to check whether
the handle is in the handle database.
2. CoreDisconnectControllersUsingProtocolInterface() and
CoreOpenProtocol() de-reference Link pointer which is
already freed. The proper way is to not de-reference the pointer.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com>
Commit 0df6c8c157af ("BaseTools/tools_def AARCH64: avoid SIMD registers
in XIP code") updated the compiler flags used by AARCH64 when building
modules (including BASE libraries) that may execute before the MMU is
enabled.
This broke the build for OpensslLib/OpensslLibCrypto because the SIMD
register file is shared with the FPU, and since OpenSSL contains some
references to float/double types (which are mostly unused for UEFI btw),
disabling floating point prevents the compiler from building OpenSSL
at all. So for OpensslLib[Crypto], we need to override the XIP CC flags,
to remove the -mgeneral-regs-only compiler flag again.
When introducing the support for XIP CC flags, we were aware that this
would affect BASE libraries as well, but were not expecting this to
have any performance impact. However, in the case of software crypto,
it makes sense not to needlessly inhibit the compiler's ability to
generate fast code, and even if OpenssLib is a BASE library, it is
guaranteed not to run with the MMU off. So omit -mstrict-align from the
local XIP CC flags override as well.
BaseTools/tools_def AARCH64: avoid SIMD registers in XIP code
XIP code may execute with the MMU off, in which case all memory accesses
should be strictly aligned to their size. Some versions of GCC violate
this restriction even when -mstrict-align is passed, when performing
loads and stores that involve SIMD registers. This is clearly a bug in
the compiler, but we can easily work around it by avoiding SIMD registers
altogether when building code that may execute in such a context. So add
-mgeneral-regs-only to the AARCH64 XIP CC flags.
BaseTools/tools_def AARCH64: mark register x18 as reserved
The AArch64 ABI classifies register x18 as a platform register, which
means it should not be used unless the code is guaranteed to run on a
platform that doesn't use it in such a capacity.
GCC does not honour this requirement by default, and so we need to tell
it not to touch it explicitly, by passing the -ffixed-x18 command line
option.
NumPages variable was introduced in commit 66c548be509d. In this commit
we allocate an intermediate buffer when SEV is enabled. The 'BounceBuffer'
variable points to the intermediate buffer pointer and NumPages variables
stores the number of pages. Later in the code, 'BounceBuffer' variable is
checked to see if we need to free the intermediate buffers. The code looks
correct, suppress the warning.
OvmfPkg: update PciHostBridgeDxe to use PlatformHasIoMmuLib
This patch enables PciHostBridgeDxe driver to use Platform IoMMU detection
library to ensure that PciHostBridgeDxe is run after platform IoMmuDxe
driver has checked whether platform need to install IOMMU protocol provider.
OvmfPkg/QemuFwCfgLib: Add option to dynamic alloc FW_CFG_DMA Access
Update InternalQemuFwCfgDmaBytes() to work with DMA Access pointer.
The change provides the flexibility to dynamically allocate the "Access"
when SEV is enabled.
OvmfPkg/QemuFwCfgLib: Implement SEV internal function for Dxe phase
When SEV is enabled, the DMA must be performed on unencrypted pages.
So when get asked to perfom FWCFG DMA read or write, we allocate a
intermediate (bounce buffer) unencrypted buffer and use this buffer
for DMA read or write.
OvmfPkg/QemuFwCfgLib: Provide Pei and Dxe specific library
Current QemuFwCfgLib.inf is used in both Pei and Dxe phases. Add Pei
and Dxe inf file to provide a seperate QemuFwCfgLib instances for Pei
and Dxe phases.
The IOMMU protocol driver provides capabilities to set a DMA access
attribute and methods to allocate, free, map and unmap the DMA memory
for the PCI Bus devices.
Due to security reasons all DMA operations inside the SEV guest must
be performed on shared (i.e unencrypted) pages. The IOMMU protocol
driver for the SEV guest uses a bounce buffer to map guest DMA buffer
to shared pages inorder to provide the support for DMA operations inside
SEV guest.
IoMmuDxe driver looks for SEV capabilities, if present then it installs
the real IOMMU protocol otherwise it installs placeholder protocol.
Currently, PciHostBridgeDxe and QemuFWCfgLib need to know the existance
of IOMMU protocol. The modules needing to know the existance of IOMMU
support should add
gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid
in their depex to ensure that platform IOMMU detection has been performed.
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Add the shorter-term library instance outlined in the previous patch to
OvmfPkg, so that we can imbue PciHostBridgeDxe with a protocol dependency
on gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid.
Platforms that optionally provide an IOMMU protocol should do so by
including a DXE driver (usually called IoMmuDxe) that produces either
the IOMMU protocol -- if the underlying capabilities are available --,
or gIoMmuAbsentProtocolGuid, to signal that the IOMMU capability
detection completed with negative result (i.e., no IOMMU will be
available in the system).
In turn, DXE drivers (and library instances) that are supposed to use
the IOMMU protocol if it is available should add the following to
their DEPEX:
gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid
This ensures these client modules will only be dispatched after IOMMU
detection completes (with positive or negative result).
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When SEV is enabled, the MMIO memory range must be mapped as unencrypted
(i.e C-bit cleared).
We need to clear the C-bit for MMIO GCD entries in order to cover the
ranges that were added during the PEI phase (through memory resource
descriptor HOBs). Additionally, the NonExistent ranges are processed
in order to cover, in advance, MMIO ranges added later in the DXE phase
by various device drivers, via the appropriate DXE memory space services.
The approach is not transparent for later addition of system memory ranges
to the GCD memory space map. (Such ranges should be encrypted.) OVMF does
not do such a thing at the moment, so this approach should be OK.
The driver is being added to the APRIORI DXE file so that, we clear the
C-bit from MMIO regions before any driver accesses it.
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
OvmfPkg/PlatformPei: Set memory encryption PCD when SEV is enabled
Secure Encrypted Virtualization (SEV) guest VMs have the concept of
private and shared memory. Private memory is encrypted with the
guest-specific key, while shared memory may be encrypted with hypervisor
key. Certain types of memory (namely instruction pages and guest page
tables) are always treated as private memory by the hardware.
For data memory, SEV guest VMs can choose which pages they would like
to be private. The choice is done using the standard CPU page tables
using the C-bit. When building the initial page table we mark all the
memory as private.
The patch sets the memory encryption PCD. The PCD is consumed by the
following edk2 modules, which manipulate page tables:
CapsulePei is not used by OVMF. DxeIplPeim consumes the PCD at the
end of the PEI phase, when it builds the initial page tables for the
DXE core / DXE phase. S3Resume2Pei does not consume the PCD in its
entry point function, only when DxeIplPeim branches to the S3 resume
path at the end of the PEI phase, and calls S3Resume2Pei's
EFI_PEI_S3_RESUME2_PPI.S3RestoreConfig2() member function.
Therefore it is safe to set the PCD for these modules in PlatformPei.
They are all dispatched after the PEI phase, so setting the PCD for
them in PlatformPei is safe. (BootScriptExecutorDxe is launched "for
real" in the PEI phase during S3 resume, but it caches the PCD into a
static variable when its entry point is originally invoked in DXE.)
OvmfPkg/BaseMemcryptSevLib: Add SEV helper library
Add Secure Encrypted Virtualization (SEV) helper library.
The library provides the routines to:
- set or clear memory encryption bit for a given memory region.
- query whether SEV is enabled.
OvmfPkg: Update dsc to use IoLib from BaseIoLibIntrinsicSev.inf
When SEV is enabled then we must unroll the rep String I/O instructions.
The patch updates dsc file to use SEV version of IoLib inf. The main
difference between BaseIoLibIntrinsic.inf and BaseIoLibIntrinsicSev.inf
is, SEV version checks if its running under SEV enabled guest, If so
then it unroll the String I/O (REP INS/OUTS) otherwise fallbacks to
rep ins/outs.
OvmfPkg/ResetVector: Set C-bit when building initial page table
SEV guest VMs have the concept of private and shared memory. Private
memory is encrypted with the guest-specific key, while shared memory
may be encrypted with hypervisor key. Certain types of memory (namely
instruction pages and guest page tables) are always treated as private
memory by the hardware. The C-bit in PTE indicate whether the page is
private or shared. The C-bit position for the PTE can be obtained from
CPUID Fn8000_001F[EBX].
When SEV is active, the BIOS is encrypted by the Qemu launch sequence,
we must set the C-bit when building the page table.
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These flags are based on the flags from the GCC5 toolchain in
tools_def.template. Since the GCC5 toolchain uses link-time
optimizations (LTO), we must compile and link the 'Host' files with
LTO enabled so we can link to other modules.