After adding a check to see if [Sources] section lists all the header
type files of a module, track module and library hashes for --hash
feature. If above check is not in compilance for a library or module,
force hash invalidation on that library or module.
Signed-off-by: Christian Rodriguez <christian.rodriguez@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Add a check to see if [Sources] section lists all the header type
files of a module. Performance impact should be minimal with this patch
since information is already being fetched for Makefile purposes. All
other information is already cached in memory. No extra IO time is needed.
Signed-off-by: Christian Rodriguez <christian.rodriguez@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Chu, Maggie [Wed, 22 May 2019 07:04:43 +0000 (15:04 +0800)]
SecurityPkg/OpalPassword: Add PCD to skip password prompt
https://bugzilla.tianocore.org/show_bug.cgi?id=1801
Add a PCD for skipping password prompt in device unlocked status.
Previous change only support if storage device is in locked status.
This change is added to support the case that security status of the
storage device is unlocked.
Signed-off-by: Maggie Chu <maggie.chu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ray Ni [Fri, 31 May 2019 09:42:09 +0000 (17:42 +0800)]
UefiCpuPkg/MpInitLib: Decrease NumApsExecuting only for ApInitConfig
The patch fixes the bug that the memory under 1MB is modified by
firmware in S3 boot.
Root cause is a racing condition in MpInitLib:
1. BSP: WakeUpByInitSipiSipi is set by NotifyOnS3SmmInitDonePpi()
2. BSP: WakeUpAP() wakes all APs to run certain procedure.
2.1. AllocateResetVector() uses <1MB memory for wake up vector.
2.1. FillExchangeInfoData() resets NumApsExecuting to 0.
2.2. WaitApWakeup() waits AP to clear WAKEUP_AP_SIGNAL.
3. AP: ApWakeupFunction() clears WAKEUP_AP_SIGNAL to inform BSP.
5. BSP: FreeResetVector() restores the <1MB memory
4. AP: ApWakeupFunction() calls the certain procedure.
4.1. NumApsExecuting is decreased.
#4.1 happens after the 1MB memory is restored so the result is
memory below 1MB is changed by #4.1
It happens only when the AP executes procedure a bit longer.
AP returns back to ApWakeupFunction() from procedure after
BSP restores the <1MB memory.
Since NumApsExecuting is only used when InitFlag == ApInitConfig
for counting the processor count.
The patch moves the NumApsExecuting decrease to the path when
InitFlag == ApInitConfig.
Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Nandagopal Sathyanarayanan <nandagopal.sathyanarayanan@intel.com>
Ray Ni [Tue, 4 Jun 2019 10:49:25 +0000 (18:49 +0800)]
UefiCpuPkg/MpInitLib: increase NumApsExecuting only for ApInitConfig
NumApsExecuting is only used when InitFlag == ApInitConfig for
counting the processor count.
The patch changes Ia32 version of waking up vector assembly code
to align to x64 version of waking up vector assembly code.
After the change both versions of waking up vector increase
NumApsExecuting when InitFlag == ApInitConfig.
Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
1. Current code gets CPUID_THERMAL_POWER_MANAGEMENT in
ClockModulationInitialize() and uses its ECMD bit for all processors.
But ClockModulationInitialize() is only executed by BSP, that means
the bit is just for BSP.
It may have no functionality issue as all processors may have same
bit value in a great possibility. But for good practice, the code
should get CPUID_THERMAL_POWER_MANAGEMENT in ClockModulationSupport
(executed by all processors), and then use them in
ClockModulationInitialize() for all processors.
We can see that Aesni.c (and others) have used this good practice.
2. Current code uses 3 CPU_REGISTER_TABLE_WRITE_FIELD for
MSR_IA32_CLOCK_MODULATION in ClockModulationInitialize(), they can
be reduced to 1 CPU_REGISTER_TABLE_WRITE64 by getting
MSR_IA32_CLOCK_MODULATION for all processors in
ClockModulationSupport() and then update fields for register table
write in ClockModulationInitialize().
We may argue that there may be more times of MSR_IA32_CLOCK_MODULATION
getting. But actually the times of MSR_IA32_CLOCK_MODULATION getting
could be also reduced.
The reason is in ProgramProcessorRegister() of CpuFeaturesInitialize.c,
AsmMsrBitFieldWrite64 (AsmReadMsr64 + AsmWriteMsr64) will be used for
CPU_REGISTER_TABLE_WRITE_FIELD, and AsmWriteMsr64 will be used for
CPU_REGISTER_TABLE_WRITE64.
The times of MSR accessing could be reduced with this patch.
Without the patch:
3 CPU_REGISTER_TABLE_WRITE_FIELD (in ClockModulationInitialize)
==> 3 AsmMsrBitFieldWrite64
==> 3 AsmReadMsr64 + 3 AsmWriteMsr64
With the patch:
1 AsmReadMsr64 (in ClockModulationSupport) +
1 CPU_REGISTER_TABLE_WRITE64 (in ClockModulationInitialize)
==> 1 AsmWriteMsr64
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Kevin Li <kevin.y.li@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
There will be ASSERT if LMCE is supported as below.
DXE_ASSERT!: [CpuFeaturesDxe]
XXX\UefiCpuPkg\Library\CpuCommonFeaturesLib\MachineCheck.c (342):
ConfigData != ((void *) 0)
The code should get Config Data and FeatureControlGetConfigData
could be used.
This issue is there since the code was added at the commit below.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Kevin Li <kevin.y.li@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
In current code, the values of TopaEntryPtr->Uint64 for TopaTable
and the values of OutputBaseReg.Uint64 and OutputMaskPtrsReg.Uint64
to register table write for RTIT_OUTPUT_BASE and RTIT_OUTPUT_MASK_PTRS
are not been initialized in whole. For example, the reserved bits in
OutputBaseReg.Uint64 are random that will cause GP fault like below
when SetProcessorRegister (in CpuFeaturesInitialize.c) sets register
based on register table.
And current code gets MSR_IA32_RTIT_CTL, MSR_IA32_RTIT_OUTPUT_BASE and
MSR_IA32_RTIT_OUTPUT_MASK_PTRS in ProcTraceInitialize() and uses their
values for all processors. But ProcTraceInitialize() is only executed
by BSP, that means the values just for BSP. For good practice, the code
should get MSR_IA32_RTIT_CTL, MSR_IA32_RTIT_OUTPUT_BASE and
MSR_IA32_RTIT_OUTPUT_MASK_PTRS in ProcTraceSupport (executed by all
processors), and then use them in ProcTraceInitialize() for all
processors. This can also resolve the issue that the values of
OutputBaseReg.Uint64 and OutputMaskPtrsReg.Uint64 are not been
initialized in whole.
For TopaEntryPtr->Uint64, this patch updates code to initialize it
in whole explicitly by TopaEntryPtr->Uint64 = 0 before updating its
fields.
At the same time, this patch also eliminates the ProcTraceSupported
field in PROC_TRACE_PROCESSOR_DATA and the TopaMemArrayCount field in
PROC_TRACE_DATA.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Kevin Li <kevin.y.li@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Current code disables TraceEn at the end of ProcTraceInitialize(),
then there will be much memory allocated even when ProcTrace feature
is disabled.
This patch updates code to disable TraceEn and return at the beginning
of ProcTraceInitialize() when when ProcTrace feature is disabled.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Kevin Li <kevin.y.li@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Marc W Chen [Thu, 6 Jun 2019 07:42:37 +0000 (15:42 +0800)]
OvmfPkg/QemuVideoDxe: Shouldn't assume system in VGA alias mode.
Query the supported attributes firstly, then bitwise AND (&) both VGA_IO
and VGA_IO_16. Since the supported attributes should only have one of
VGA_IO or VGA_IO_16 set, the result of bitwise AND (&) is either VGA_IO
or IO_16. Then the result can be passed to PciIo->Attributes() to set the
attributes.
Device driver should consider both since the mReserveVgaAliases in
PciBusDxe driver is default FALSE(implies that device driver can only set
VGA_IO_16 to PCI_ROOT_BRIDGE), and Platform code may not return
EFI_RESERVE_VGA_IO_ALIAS in GetPlatformPolicy of PciPlatformProtocol to
make mReserveVgaAliases become TRUE(implies that device driver can only
set VGA_IO to PCI_ROOT_BRIDGE), Currently OvmfPkg doesn't have problem
due to it has hard code value for PCI_ROOT_BRIDGE's attributes field, so
an IO access by PciIoProtocol will be successed due to
RootBridgeIoCheckParameter of PciRootBridgeIo.c will always get pass
result for legacy IO access.
Usually the attributes field of PCI_ROOT_BRIDGE should be 0, in that case
it will have issue since the VGA_IO may not be able to be enabled, then
IO access by PciIoProtocol will be failed, hence the QemuVideoDxe driver
will not work fine.
CryptoPkg/OpensslLib: fix build break caused by missing library
CryptoPkg\Library\Include\CrtLibSupport.h maps strxxxx interfaces to
edk2 PrintLib interfaces but related module inf file don't claim the
use of it. This will cause unresolved symbol issue with VS2017 build
which has enabled strict symbol check. This patch resolves the problem
by adding PrintLib to inf files.
Cc: Liming Gao <liming.gao@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com>
Xiaoyu Lu [Wed, 5 Jun 2019 05:24:55 +0000 (13:24 +0800)]
CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem
When use clang-3.8 to build the NetworkPkg, compiler optimization
may use memcpy for memory copy. For example:
CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
reference to `memcpy'`
Compiler optimization is sophisticated, but we can work around it
use __attribute__((__used__)) to informs the compiler that symbol
should be retained in the object file, even if it may be
unreferenced.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Update the list of additional licenses in Readme.md. For additional
licenses from a git submodule, provide a link to the license file
in the remote git repository. This makes the links in Readme.md
when viewed from the edk2 repository GitHub landing page
https://github.com/tianocore/edk2/ functional from a web browser.
* Remove references EdkCompatibilityPkg
* Update link to OpenSSL to license file in the git submodule link
to https://github.com/openssl/openssl
* Add link to license file in the git submodule like to
https://github.com/ucb-bar/berkeley-softfloat-3 for
ArmSoftFloatLib
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Because OPENSSL_NO_ERR and OPENSSL_NO_AUTOERRINIT are not defined by
default, err_load_crypto_strings_int() will not be actually referenced
by ossl_init_load_crypto_strings().
Since err_load_crypto_strings_int() is not actually referenced at all,
the fix can be done simply by removing crypto/err/err_all.c from build.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Said commit was not suitable for pushing during the edk2-stable201905 hard
feature freeze; it was pushed only by mistake. The subject line referenced
EmulatorPkg, but the patch changed MdeModulePkg/UiApp, regressing the
display of the CPU speed from SMBIOS in multiple platforms.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1877 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Dong, Guo [Wed, 29 May 2019 18:52:20 +0000 (11:52 -0700)]
UefiPayloadPkg: Remove legacy PIC 8259 driver
Since legacy PIC 8259 driver would be removed from edk2,
update UEFI payload to remove 8259 driver.
If required, bootloader could disable 8259.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com>
The bug reporter wish to display nothing as the CPU is virtual
Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
FmpDevicePkg use OpensslLib and when OpenSSL upgrade to 1.1.1b,
TimerLib is required by OpensslLib in CryptoPkg(commit 456dd8b99f,
CryptoPkg: Upgrade OpenSSL to 1.1.1b)
So add TimerLib to DSC file.
Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
When building CryptoPkg with XCODE, blow error may result
* usr/lib/clang/9.0.0/include/stdatomic.h:105:17:
error: unknown type name 'wchar_t'
Since the C native atomics are C11 feature we can explicitly
use C99 to work around it.
add -std=c99 to avoid it
* openssl/crypto/conf/conf_sap.c:71:12: error: variable 'ret' is
uninitialized
when used here [-Werror,-Wuninitialized]
Suppress warnings in OpenSSL so we don't break the build with -Werror.
add -Wno-error=uninitialized to disalbe this warning
Cc: Jian Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Laszlo Ersek [Wed, 29 May 2019 12:49:55 +0000 (14:49 +0200)]
OvmfPkg/PlatformPei: set 32-bit UC area at PciBase / PciExBarBase (pc/q35)
(This is a replacement for commit 39b9a5ffe661 ("OvmfPkg/PlatformPei: fix
MTRR for low-RAM sizes that have many bits clear", 2019-05-16).)
Reintroduce the same logic as seen in commit 39b9a5ffe661 for the pc
(i440fx) board type.
For q35, the same approach doesn't work any longer, given that (a) we'd
like to keep the PCIEXBAR in the platform DSC a fixed-at-build PCD, and
(b) QEMU expects the PCIEXBAR to reside at a lower address than the 32-bit
PCI MMIO aperture.
Therefore, introduce a helper function for determining the 32-bit
"uncacheable" (MMIO) area base address:
- On q35, this function behaves statically. Furthermore, the MTRR setup
exploits that the range [0xB000_0000, 0xFFFF_FFFF] can be marked UC with
just two variable MTRRs (one at 0xB000_0000 (size 256MB), another at
0xC000_0000 (size 1GB)).
- On pc (i440fx), the function behaves dynamically, implementing the same
logic as commit 39b9a5ffe661 did. The PciBase value is adjusted to the
value calculated, similarly to commit 39b9a5ffe661. A further
simplification is that we show that the UC32 area size truncation to a
whole power of two automatically guarantees a >=2GB base address.
On Q35 machine types that QEMU intends to support in the long term, QEMU
never lets the RAM below 4 GB exceed 2 GB.
Alas, this statement came from a misunderstanding that occurred while we
worked out the interface contract. In fact QEMU does allow the 32-bit RAM
extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the
range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than
2048MB and smaller than 2816MB).
In turn, such a RAM size (justifiedly) triggers
ASSERT (TopOfLowRam <= PciExBarBase);
in MemMapInitialization(), because we placed the 256MB PCIEXBAR at
0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the
32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000,
0xFC00_0000) range.)
In order to fix this, place the PCIEXBAR at 2816MB (0xB000_0000), and
start the 32-bit PCI window at 3 GB (0xC000_0000). This shrinks the 32-bit
PCI window to
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
Ard Biesheuvel [Mon, 3 Jun 2019 16:19:41 +0000 (18:19 +0200)]
CryptoPkg CLANG35: add -std=c99 to dodge OpenSSL C atomics issue
Commit c51f8bae7cabe ("CryptoPkg: Fix possible build problem with
Clang") added -std=c99 to the CLANG38 compiler command line of
packages that incorporate parts of OpenSSL, to ensure that the new
C atomics code used by OpenSSL for refcounting (which we don't care
about) does not pull in system C library headers, which we cannot
rely on when (cross)building EDK2 code.
Unsurprisingly, CLANG35 (which is only defined for ARM and AARCH64)
suffers from the exact same issue, so let's add the same flags
there as well.
OpenSSL internally redefines the size of HMAC_CTX at
crypto/hmac/hmac_lcl.h(OpenSSL commit e0810e35).
Ref: https://github.com/openssl/openssl/pull/4338
We should not use it directly and should remove relevant
functions(Hmac*GetContextSize).
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1792
But for compatiblility, temporarily change these definition
of HMAC_*_CTX_SIZE.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* Run process_files.pl script to regenerate OpensslLib[Crypto].inf
and opensslconf.h
* Remove -DNO_SYSLOG from OPENSSL_FLAGS in OpensslLib[Crypto].inf,
due to upstream OpenSSL commit cff55b90e95e("Cleaning UEFI
Build with additional OPENSSL_SYS_UEFI flags", 2017-03-29),
which was first released as part of OpenSSL_1_1_1.
* Starting with OpenSSL commit 8a8d9e1905(first release in
OpenSSL_1_1_1), the OpenSSL_version() function can no longer
return a pointer to the string literal "compiler: information
not available", in the case CFLAGS macro is not defined.
Instead, the function now has a hard dependency on the global
variable 'compiler_flags'. This variable is normally placed
by "util/mkbuildinf.pl" into "buildinf.h". In edk2 we don't
run that script whenever we build OpenSSL, therefore we
must provide our own dummy 'compiler_flags'.
* BUFSIZ is used by crypto/evp/evp_key.c(OpenSSL_1_1_1b)
And it is declared in stdio.h. So add it to CrtLibSupport.h.
Here's a discussion about this.
Ref: https://github.com/openssl/openssl/issues/8904
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Since OpenSSL_1_1_1b doesn't fully implement rand pool functions
for UEFI. We must provide a method to implenet these method.
TSC is used as first entropy source if it's availabe otherwise
fallback to TimerLib. But we are not sure the amount of randomness
they provide. If you really care about the security, one choice is
overrided it with hardware generator.
Add rand_pool.c to implement these functions required by OpenSSL
rand_pool_acquire_entropy
rand_pool_add_nonce_data
rand_pool_add_additional_data
rand_pool_init
rand_pool_cleanup
rand_pool_keep_random_devices_open
And add rand_pool_noise.* for getting entropy noise from different
architecture.
* We don't need ossl_store functions. We exclude relative files
through process_files.pl. And ossl_store_cleanup_int was first
added in crypto/init.c OpenSSL_1_1_1(71a5516d).
So add a new file(ossl_store.c) to implement ossl_store_cleanup_int
function.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
When building CryptoPkg with Clang, blow error may result
* /usr/lib/llvm-3.8/lib/clang/3.8.0/include/stdatomic.h:105:17: error:
unknown type name 'wchar_t'
Since the C native atomics are C11 feature we can explicitly
use C99 to work around it.
add -std=c99 to avoid it
* openssl/crypto/conf/conf_sap.c:71:12: error: variable 'ret' is
uninitialized
when used here [-Werror,-Wuninitialized]
Suppress warnings in OpenSSL so we don't break the build with -Werror.
add -Wno-error=uninitialized to disalbe this warning
Cc: Ting Ye <ting.ye@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
add /wd4132 /wd4700 /wd4310 for Visual Studio in OpensslLib[Crypto].inf
add -Wno-error=unused-but-set-variable for GCC in OpensslLib[Crypto].inf
Although this option is set in some build environments by default.
But this is only for OpenSSL compilation, no matter how the
default options change.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
This is for the upcoming upgrade to OpenSSL_1_1_1b
Compiler optimization(Visual Studio) may automatically use _ftol2
instead of some type conversion. For example:
OpensslLib.lib(drbg_lib.obj) : error LNK2001:
unresolved external symbol __ftol2
This patch add _ftol2 function for the compiler intrinsic.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
When running process_files.py to configure OpenSSL, we can exclude
some unnecessary files. This can reduce porting time, compiling
time and library size.
Upstream OpenSSL commit 71a5516dcc8a which was as part of
OpenSSL_1_1_1b, Add the STORE module(crypto/store/*).
But UEFI don't use them. So exclude these files.
Functions in crypto/rand/randfile.c OpenSSL and edk2 don't
call them. And it requires more crt runtime support.
So exclude it.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
This OpenSSL change was introduced in commit 8389ec4b4950 ("Add --with-rand-seed", 2017-07-22).
So add --with-rand-seed=none to process_files.pl.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Ard Biesheuvel [Fri, 31 May 2019 20:46:30 +0000 (22:46 +0200)]
ArmPkg/ArmSoftFloatLib GCC4x: fix build failure
The upstream SoftFloat code that was recently incorporated into
ArmSoftFloatLib uses some parameterization to tweak the inlining
and optimization behavior for different compilers.
The custom platform.h file that sets these parameters is based on
the upstream version for Linux/ARM, but was updated to include the
'always_inline' GCC attribute into the INLINE macro, to ensure that
all definitions that are marked as inline are not only inlined into
their callers, but also to ensure that no version of the function is
ever emitted into the object file.
This works fine on recent GCC and Clang, but the latter part turns
out to break on GCC 4.x, resulting duplicate definition linker errors.
Fortunately, the synticatically more appriopriate 'static inline'
works fine on both the recent and the older compilers, so let's switch
to that instead.
Ard Biesheuvel [Thu, 20 Dec 2018 19:16:53 +0000 (20:16 +0100)]
ArmPkg/ArmLib ARM: set .fpu to let Clang 7 assemble ArmV7Support.S
Clang 7 complains about the vmsr instruction in ArmV7Support.S,
which is only available on cores that implement some flavour of
VFP. So set the .fpu to NEON like we do in some other places.
Ard Biesheuvel [Fri, 24 May 2019 14:58:40 +0000 (16:58 +0200)]
ArmPkg/ArmSoftFloatLib: remove source files that are no longer used
Now that we have switched to a new version of the SoftFloat code,
remove the source files that make up the old implementation, and
are no longer referenced.
Ard Biesheuvel [Fri, 24 May 2019 14:52:13 +0000 (16:52 +0200)]
ArmPkg/ArmSoftFloatLib: switch to new version of softfloat library
Update the INF description and the top level .c files in order to
switch to the new version of the SoftFloat library imported as a
Git submodule in the previous patch.
Note that we no longer use the code that travelled a long way from
the 2002 version of the softfloat library via NetBsd and the StdLib
package. Instead, we are using the upstream version unmodified, with
the glue .c file adopted from the OP-TEE project. This approach is
much cleaner and much more maintainable.
Note that support for the RVCT toolchains is being dropped at the same
time. RVCT is mostly untested, and planned to be removed, and so it
makes little sense to go to the trouble of upgrading this library for
RVCT as well.
Ard Biesheuvel [Fri, 24 May 2019 14:05:02 +0000 (16:05 +0200)]
ArmPkg: import Berkeley Softfloat library as git submodule
In preparation of bringing ArmSoftFloatLib up to date in order
to provide some missing routines, import the Berkely SoftFloat
library into the tree as a git submodule.
Current Binary Cache doesn't update the restored file
creation and modification times to the current time.
Preserve the new restored file creation time as old
cached time might has potential issue to block the make
to build updated files based on the time stamp.
Enhance to update the restored file creation time to
current time.
Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Zhiju Fan <zhijux.fan@intel.com> Signed-off-by: Steven Shi <steven.shi@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Current binary cache doesn't support to save and restore
the library module. If a driver module cache miss happen,
all its dependency library modules need rebuild which
is very time-consuming. This patch is to extend the binary
cache to support library.
Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Christian Rodriguez <christian.rodriguez@intel.com> Signed-off-by: Steven Shi <steven.shi@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Current implementation of function AhciModeInitialization() has an
incorrect assumption that the value in the CAP (offset 00h) register will
always be greater than the highest bit set for the value in the PI (offset
0Ch) register.
This will lead to an issue that hard disk devices may not be found in the
non-S3 boot path for some AHCI controller capabilities.
More specifically, variable 'PortInitializeBitMap' will have the value
from 'Private->PortBitMap', which will be 0xFFFFFFFF in non-S3 boot path.
When the CAP register is of value 0x1 and PI register with value 0x4
(meaning port 2 is available), the current logic will only enumerate port
0. And the device attached behind port 2 will not be enumerated.
To address this issue, variable 'PortInitializeBitMap' will now take the
bitwise and result between 'Private->PortBitMap' and the value read from
the PI register.
Please note that there will be no function impact for S3 path, since in
this case, the bits being set in 'Private->PortBitMap' will be a subset
of the bits being set in the PI register. Their bitwise and operation will
still be the value of 'Private->PortBitMap'.
Cc: Maggie Chu <maggie.chu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Support rebasing FSP 1.x binary.
FSP 1.x has single component in binary so not supported
by split command and rebase can be done with the same
command for rebasing FSP-T component in FSP 2.x image.
Test: both FSP 2.x (Kabylake) and FSP 1.x (BroadwellDE) binary
can be rebased successfully.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Guo Dong [Wed, 29 May 2019 19:07:29 +0000 (03:07 +0800)]
Maintainers.txt: update UEFI payload information
Remove CorebootModulePkg and CorebootPayloadPkg, and add
UefiPayloadPkg to reflect recently change in UEFI payload.
wiki link for UefiPayloadPkg would be available soon.
Signed-off-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Current Binary Cache use the PlatformInfo.Name to distinguish
the different platform cache paths in the database folder.
But the different platforms might use the same PLATFORM_NAME
in the DSC files. Different platform caches might overlay each
other inside Binary Cache database if they use same platform name
Use the PlatformInfo.Platform.OutputDirectory instead of the
PlatformInfo.Name can solve the problem.
This patch is going to fix that issue.
Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Steven Shi <steven.shi@intel.com> Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
This patch is related to commit 9ca1f1
It's to remove the second .SecMain call from 'run' target.
Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
There is a bug to use AsciiStrCpyS to copy a truncated
string. If would cause an assert because the truncated
length is always less than the source string length. It
should use the AsciiStrnCpyS instead.
When a target of 'run' is passed into build.py,
BaseTools unconditionally attempts to execute the
application called './SecMain' in the build output directory.
This behavior applies to the Nt32Pkg which is being
replaced with features in the EmulatorPkg.
Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The edk2 source tree contains four instances of the outdated mailing
list address "edk2-devel@lists.01.org".
I created a new variable, MSG_EDKII_MAIL_ADDR, to receive the
new email address and replaced the old one with this variable
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
In V3: Must generate hashes before attempting to copy from cache for
hash verifcation
In V2: Build failure caused by passing incorrect boolean parameter to
SaveFileOnChange(). Fixed for patch instances.
Library hashing is now supported by the --hash feature. The --hash
feature implementation assumed that the hashing could be done in
place once per module, but that isn't true for libraries due to the
fact that they are built as dependencies. So on a clean build, we now
generate the .hash after the library dependencies are complete.
Added early escape as optimization, if hash already exists in memory.
Signed-off-by: Christian Rodriguez <christian.rodriguez@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
When a module in a DSC file uses a FILE_GUID override in the
module scoped <Defines> section, a copy of the modified INF file
is placed in the Conf/.cache directory. The check for private
includes uses the INF path to determine if the module is allowed
to use the private includes. Since the INF path in this case is
not in any package, this check always fails, and no private
include paths are possible.
The fix is to keep both the OriginalPath and the new Path in
the PathClass object, and always use the OriginalPath to see if
the module INF is in the package with private includes.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Liming Gao [Mon, 20 May 2019 12:06:43 +0000 (20:06 +0800)]
EmulatorPkg: Add NetworkPkg/NetworkPkg.dec as the package dependency
NetLib will be moved from MdeModulePkg and NetworkPkg.
So, the module that consumes NetLib need to depend on NetworkPkg.dec.
Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Krzysztof Koch [Wed, 8 May 2019 13:13:54 +0000 (06:13 -0700)]
ShellPkg: Display VENDOR_ID in ASCII when parsing PPTT
The ID Type Structure (Type 2) inside the Processor Properties
Topology Table (PPTT) has a VENDOR_ID field which identifies the
node vendor. The approved values are listed in the ACPI ID Registry
and they are meant to be interpreted as arrays of ASCII characters.
This change to the acpiview parser for PPTT aims to reflect that.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The checking to CpuInfo->CpuIdVersionInfoEcx.Bits.AESNI is enough,
the checking to CPU generation could be removed, then the code
could be reused by more platforms.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
CryptRandItc.c is only for IPF arch, which has not been supported any
more in edk2. And no module actually reference this file. This patch
just removes it from tree.
Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Ray Ni [Fri, 17 May 2019 04:56:35 +0000 (12:56 +0800)]
Maintainers.txt: Remove Nt32Pkg reference after Nt32Pkg is removed
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Joe Richey [Fri, 10 May 2019 09:36:33 +0000 (17:36 +0800)]
UefiCpuPkg: Remove double \r
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Joe Richey <joerichey@google.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
The integer that stands for the uncacheable area size has 11 (eleven) bits
set to 1. As a result, covering this size requires 11 variable MTRRs (each
MTRR must cover a naturally aligned, power-of-two sized area). But, if we
need more variable MTRRs than the CPU can muster (such as 8), then
MtrrSetMemoryAttribute() fails, and we refuse to continue booting (which
is justified, in itself).
Unfortunately, this is not difficult to trigger, and the error message is
well-hidden from end-users, in the OVMF debug log. The following
mitigation is inspired by SeaBIOS:
Truncate the uncacheable area size to a power-of-two, while keeping the
end fixed at 4 GB. Such an interval can be covered by just one variable
MTRR.
This may leave such an MMIO gap, between the end of low-RAM and the start
of the uncacheable area, that is marked as WB (through the MTRR default).
Raise the base of the 32-bit PCI MMIO aperture accordingly -- the gap will
not be used for anything.
On Q35, the minimal 32-bit PCI MMIO aperture (triggered by RAM size 2815
MB) shrinks from
0xE000_0000 - 0xAFF0_0000 = 769 MB
to
0xE000_0000 - 0xC000_0000 = 512 MB
On i440fx, the minimal 32-bit PCI MMIO aperture (triggered by RAM size
3583 MB) shrinks from
On Q35 machine types that QEMU intends to support in the long term, QEMU
never lets the RAM below 4 GB exceed 2 GB.
Alas, this statement came from a misunderstanding that occurred while we
worked out the interface contract. In fact QEMU does allow the 32-bit RAM
extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the
range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than
2048MB and smaller than 2816MB).
In turn, such a RAM size (justifiedly) triggers
ASSERT (TopOfLowRam <= PciExBarBase);
in MemMapInitialization(), because we placed the 256MB PCIEXBAR at
0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the
32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000,
0xFC00_0000) range.)
In order to fix this, reorder the 32-bit PCI window against the PCIEXBAR,
as follows:
- start the 32-bit PCI window where it starts on i440fx as well, that is,
at 2GB or TopOfLowRam, whichever is higher;
- unlike on i440fx, where the 32-bit PCI window extends up to 0xFC00_0000,
stop it at 0xE000_0000 on q35,
- place the PCIEXBAR at 0xE000_0000.
(We cannot place the PCIEXBAR at 0xF000_0000 because the 256MB MMIO area
that starts there is not entirely free.)
Before this patch, the 32-bit PCI window used to only *end* at the same
spot (namely, 0xFC00_0000) between i440fx and q35; now it will only
*start* at the same spot (namely, 2GB or TopOfLowRam, whichever is higher)
between both boards.
Laszlo Ersek [Tue, 22 Jan 2019 19:44:47 +0000 (20:44 +0100)]
OvmfPkg/PlatformPei: hoist PciBase assignment above the i440fx/q35 branching
In the MemMapInitialization() function, we currently assign PciBase
different values, on both branches of the board type check. Hoist the
PciBase assignment from the i440fx branch in front of the "if". This is a
no-op for the i440fx branch. On the q35 branch, we overwrite this value,
hence the change is a no-op on q35 as well.
This is another refactoring for simplifying the rest of this series.
Laszlo Ersek [Tue, 22 Jan 2019 19:37:31 +0000 (20:37 +0100)]
OvmfPkg/PlatformPei: assign PciSize on both i440fx/q35 branches explicitly
In the MemMapInitialization() function, we currently have a common
PciSize assignment, shared between i440fx and q35. In order to simplify
the rest of this series, lift and duplicate the assignment identically to
both board-specific branches.
Fu Siyuan [Thu, 16 May 2019 08:18:10 +0000 (16:18 +0800)]
EmulatorPkg: Update DSC/FDF to use NetworkPkg's include fragment file.
This patch updates the platform DSC/FDF files to use the include fragment
files provided by NetworkPkg.
The feature enabling flags in [Defines] section have been updated to use
the NetworkPkg's terms, and the value has been overridden with the original
default value on this platform.
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Message-Id: <20190516081810.27840-5-shenglei.zhang@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293
[lersek@redhat.com: add TianoCore Bugzilla reference]
Fu Siyuan [Thu, 16 May 2019 08:18:09 +0000 (16:18 +0800)]
ArmVirtPkg: Update DSC/FDF to use NetworkPkg's include fragment file.
This patch updates the platform DSC/FDF files to use the include fragment
files provided by NetworkPkg.
The feature enabling flags in [Defines] section have been updated to use
the NetworkPkg's terms, and the value has been overridden with the original
default value on this platform.
v2:Add check for NETWORK_SNP_ENABLE and NETWORK_TLS_ENABLE.
Fu Siyuan [Thu, 16 May 2019 08:18:08 +0000 (16:18 +0800)]
Nt32Pkg: Update DSC/FDF to use NetworkPkg's include fragment file.
This patch updates the platform DSC/FDF files to use the include fragment
files provided by NetworkPkg.
The feature enabling flags in [Defines] section have be updated to use the
NetworkPkg's terms, and the value have been overridden with the original
default value on this platform.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Message-Id: <20190516081810.27840-3-shenglei.zhang@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293
[lersek@redhat.com: add TianoCore Bugzilla reference]
Fu Siyuan [Thu, 16 May 2019 08:18:07 +0000 (16:18 +0800)]
OvmfPkg: Update DSC/FDF to use NetworkPkg's include fragment file.
This patch updates the platform DSC/FDF files to use the include fragment
files provided by NetworkPkg.
The feature enabling flags in [Defines] section have been updated to use
the NetworkPkg's terms, and the value has been overridden with the original
default value on this platform.
v2:1.Make the comments before Network definition align other parts.
2.Set NETWORK_ALLOW_HTTP_CONNECTIONS true.
3.Remove TcpIoLib in lib classes section.
4.Withdraw the removal of [PcdsFixedAtBuild.X64].
Gary Lin [Thu, 16 May 2019 03:08:34 +0000 (11:08 +0800)]
OvmfPkg/EnrollDefaultKeys: import the non-default key into db
For QA test and development, we may need to test Secure Boot with a
devel key instead of UEFI CA.
This commit adds an argument, "--no-default", to EnrollDefaultKeys.efi.
With the argument, the key from SMBIOS Type 11 will also be enrolled
into db. Besides, the keys in AuthData.c, i.e. Microsoft KEK CA,
Microsoft PCA, and Microsoft UEFI CA will be excluded, so the developer
can easily create a varstore template for a specific key.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190516030834.12203-1-glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Since we will merger the BaseUefiTianoCustomDecompressLib
in MdeModulePkg into BaseUefiDecompressLib in MdePkg and
remove the one in MdeModulePkg. So here update the Platform
to use the UefiDecompressLib instance in MdePkg.
Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
We plan to merge the BaseUefiTianoCustomDecompressLib
in MdeModulePkg into the BaseUefDecompressLib in MdePkg.
In order to reduce the duplicated codes and maintain
easily.
This patch adds a new fdf file in BaseUefDecompressLib
(BaseUefiTianoCustomDecompressLib.inf) to keep the same
functionality and usage model with the one in MdeModulePkg,
and then update consumer to use this new one one and
remove the one in MdeModulePkg finally.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Krzysztof Koch [Wed, 24 Apr 2019 09:50:22 +0000 (10:50 +0100)]
MdePkg: Add ACPI 6.3 header file
The patch includes the following ACPI 6.3 updates:
1. Reserve CRAT and CDIT table names in ACPI 6.3 header.
- ACPI 6.3 January 2019, Table 5-30
- Mantis ID 1883 (https://mantis.uefi.org/mantis/view.php?id=1883)
2. Add new processor structure flags in PPTT.
- ACPI 6.3 January 2019, Section 5.2.29
- Mantis ID 1870 (https://mantis.uefi.org/mantis/view.php?id=1870)
- Mantis ID 1934 (https://mantis.uefi.org/mantis/view.php?id=1934)
3. Add SPE support to MADT.
- ACPI 6.3 January 2019, Table 5-60
- Mantis ID 1934 (https://mantis.uefi.org/mantis/view.php?id=1934)
4. Add 'Hot-plug Capable' flag to APIC.
- ACPI 6.3 January 2019, Table 5-44, Table 5-47 & Table 5-58
- Mantis ID 1948 (https://mantis.uefi.org/mantis/view.php?id=1948)
5. Add CNTHV timer to GTDT.
- ACPI 6.3 January 2019, Section 5.2.24
- Mantis ID 1851 (https://mantis.uefi.org/mantis/view.php?id=1851)
6. Add 'Trigger Order' to Platform Communication Channel Identification
Structure.
- ACPI 6.3 January 2019, Section 5.2.28
- Mantis ID 1867 (https://mantis.uefi.org/mantis/view.php?id=1867)
7. Add Generic Initiator Affinity Structure to SRAT.
- ACPI 6.3 January 2019, Section 5.2.16.6
- Mantis ID 1904 (https://mantis.uefi.org/mantis/view.php?id=1904)
8. Add 'HMAT Enhancements'.
- ACPI 6.3 January 2019, Section 5.2.27
- Mantis ID 1914 (https://mantis.uefi.org/mantis/view.php?id=1914)
- Mantis ID 1959 (https://mantis.uefi.org/mantis/view.php?id=1959)
9. Fix generic address structure definition to include all address
space ID keywords.
- ACPI 6.3 January 2019, Table 5-25
- Mantis ID 1965 (https://mantis.uefi.org/mantis/view.php?id=1965)
10. Make Acpi63.h the latest ACPI definition.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Zhang, Shenglei [Wed, 15 May 2019 07:24:19 +0000 (15:24 +0800)]
OvmfPkg: Remove duplicated library classes in dxe drivers section in DSC
NetLib,IpIoLib,UdpIoLib and DpcLib already exist in [LibraryClasses].
So the ones in [LibraryClasses.common.DXE_DRIVER] are duplicated,
which should be removed.
This commit will update the package DSC file to consume the
ReportStatusCodeLib (DXE phase instance) in MdeModulePkg, instead of using
the one in IntelFrameworkModulePkg.
Please note that, the 2 ReportStatusCodeLib are almost identical. Thus,
there is no functional impact for this commit.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Customer met system hang-up during serial port loopback test in OS.
It is a corner case happened with one CPU core doing "out dx,al" and
another CPU core(s) doing "rep outs dx,byte ptr [rsi]".
Detailed code flow is as below.
1. Serial port loopback test in OS.
One CPU core: "out dx,al" -> Writing B2h, SMI will happen.
Another CPU core(s): "rep outs dx,byte ptr [rsi]".
2. SMI happens to enter SMM.
"out dx" (SMM_IO_TYPE_OUT_DX) is saved as I/O instruction type in
SMRAM save state for CPU doing "out dx,al".
"rep outs dx" (SMM_IO_TYPE_REP_OUTS) is saved as I/O instruction
type and rsi is save as I/O Memory Address in SMRAM save state for
CPU doing "rep outs dx, byte ptr [rsi]".
NOTE: I/O Memory Address (rsi) is a virtual address mapped by
OS/Virtual Machine.
3. Some SMM code calls EFI_SMM_CPU_PROTOCOL.ReadSaveState() with
EFI_SMM_SAVE_STATE_REGISTER_IO and parse data returned.
For example:
https://github.com/tianocore/edk2/blob/master/QuarkSocPkg/
QuarkNorthCluster/Smm/DxeSmm/QncSmmDispatcher/QNC/QNCSmmSw.c#L76
4. SmmReadSaveState() is executed to read save state for
EFI_SMM_SAVE_STATE_REGISTER_IO.
- The SmmReadSaveState() function in
"UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c" calls the
SmmCpuFeaturesReadSaveStateRegister() function, from the platform's
SmmCpuFeaturesLib instance.
- If that platform-specific function returns EFI_UNSUPPORTED, then
PiSmmCpuDxeSmm falls back to the common function
ReadSaveStateRegister(), defined in file
"UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c".
Current ReadSaveStateRegister() in
UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c is trying to copy data
from I/O Memory Address for EFI_SMM_SAVE_STATE_IO_TYPE_REP_PREFIX,
PF will happen as SMM page table does not know and cover this
OS/Virtual Machine virtual address.
Same case is for SmmCpuFeaturesReadSaveStateRegister() in platform-
specific SmmCpuFeaturesLib instance if it has similar implementation
to read save state for EFI_SMM_SAVE_STATE_REGISTER_IO with
EFI_SMM_SAVE_STATE_IO_TYPE_REP_PREFIX.
Same case is for "ins", 'outs' and 'rep ins'.
So to fix the problem, this patch updates the code to only support
IN/OUT, but not INS/OUTS/REP INS/REP OUTS for SmmReadSaveState().
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>