Star Zeng [Sun, 11 Feb 2018 03:00:44 +0000 (11:00 +0800)]
SecurityPkg OpalPassword: Add solution without SMM device code
After IOMMU is enabled in S3, original solution with SMM device
code (OpalPasswordSmm) to unlock OPAL device for S3 will not work
as the DMA operation will be aborted without granted DMA buffer.
Instead, this solution is to add OpalPasswordPei to eliminate
SMM device code, and OPAL setup UI produced by OpalPasswordDxe
will be updated to send requests (set password, update password,
and etc), and then the requests will be processed in next boot
before SmmReadyToLock, password and device info will be saved to
lock box used by OpalPasswordPei to unlock OPAL device for S3.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Star Zeng [Sun, 11 Feb 2018 02:01:21 +0000 (10:01 +0800)]
MdeModulePkg LockBoxLib: Support LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY
With this flag, the LockBox can be restored in S3 resume only.
The LockBox can not be restored after SmmReadyToLock in normal boot
and after EndOfS3Resume in S3 resume.
It can not be set together with LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Jian J Wang [Fri, 2 Mar 2018 02:46:05 +0000 (10:46 +0800)]
UefiCpuPkg/MpInitLib: put mReservedApLoopFunc in executable memory
if PcdDxeNxMemoryProtectionPolicy is enabled for EfiReservedMemoryType
of memory, #PF will be triggered for each APs after ExitBootServices
in SCRT test. The root cause is that AP wakeup code executed at that
time is stored in memory of type EfiReservedMemoryType (referenced by
global mReservedApLoopFunc), which is marked as non-executable.
This patch fixes this issue by setting memory of mReservedApLoopFunc to
be executable immediately after allocation.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Jian J Wang [Wed, 7 Mar 2018 03:26:32 +0000 (11:26 +0800)]
MdeModulePkg/Core: fix too many available pages between BS_Data
The root cause is an unnecessary check to Size parameter in function
AdjustMemoryS(). It will cause one standalone free page (happen to have
Guard page around) in the free memory list cannot be allocated, even if
the requested memory size is less than a page.
//
// At least one more page needed for Guard page.
//
if (Size < (SizeRequested + EFI_PAGES_TO_SIZE (1))) {
return 0;
}
The following code in the same function actually covers above check
implicitly. So the fix is simply removing above check.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Laszlo Ersek [Wed, 7 Mar 2018 09:17:28 +0000 (10:17 +0100)]
BaseTools/header.makefile: revert gcc-8 "-Wno-xxx" options on OSX
I recently added the gcc-8 specific "-Wno-stringop-truncation" and
"-Wno-restrict" options to BUILD_CFLAGS, both for "Darwin" (XCODE5 /
clang, OSX) and otherwise (gcc, Linux / Cygwin).
I also regression-tested the change with gcc-4.8 on Linux -- gcc-4.8 does
not know either of the (gcc-8 specific) "-Wno-stringop-truncation" and
"-Wno-restrict" options, yet the build completed fine (by GCC design).
Regarding OSX, my expectation was that
- XCODE5 / clang would either recognize these warnings options (because
clang does recognize most -W options of gcc),
- or, similarly to gcc, clang would simply ignore the "-Wno-xxx" flags
that it didn't recognize.
Neither is the case; the new flags have broken the BaseTools build on OSX.
Revert them (for OSX only).
The ZeroMem() call goes beyond the HashInterfaceHob structure, causing
HOB list corruption. Instead, just clear the HashInterface fields, as
I suppose was originally intended.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-Andr? Lureau <marcandre.lureau@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Hao Wu [Tue, 6 Mar 2018 11:34:38 +0000 (19:34 +0800)]
MdeModulePkg/Core: Fix feature conflict between NX and Stack guard
If enabled, NX memory protection feature will mark some types of active
memory as NX (non-executable), which includes the first page of the stack.
This will overwrite the attributes of the first page of the stack if the
stack guard feature is also enabled.
The solution is to override the attributes setting to the first page of
the stack by adding back the 'EFI_MEMORY_RP' attribute when the stack
guard feature is enabled.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@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> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Hao Wu [Tue, 6 Mar 2018 10:36:37 +0000 (18:36 +0800)]
MdeModulePkg/Core: Refine handling NULL detection in NX setting
The commit rewrites the logic in function
InitializeDxeNxMemoryProtectionPolicy() for handling the first page
(page 0) when NULL pointer detection feature is enabled.
Instead of skip setting the page 0, the codes will now override the
attribute setting of page 0 by adding the 'EFI_MEMORY_RP' attribute.
The purpose is to make it easy for other special handling of pages
(e.g. the first page of the stack when stack guard feature is enabled).
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@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> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Function BmRepairAllControllers may recursively call itself if some
driver health protocol returns EfiDriverHealthStatusReconnectRequired.
However, driver health protocol of some buggy third party driver may
always return such status even after one and another reconnect. The
endless iteration will cause stack overflow and then system exception,
and it may be not easy to find that the exception is actually caused
by stack overflow.
So we limit the number of reconnect retry to 10 to improve code
robustness, and DEBUG_CODE is moved ahead before recursive repair to
track the repair result.
We also remove a duplicated declaration of BmRepairAllControllers() in
InternalBm.h in this patch, for it is only a trivial change.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Ruiyu Ni [Tue, 6 Mar 2018 03:31:57 +0000 (11:31 +0800)]
MdeModulePkg/NullMemoryTest: Fix bug in CompatibleRangeTest
CompatibleRangeTest() contains two bugs:
1. It doesn't reject the memory above 16MB
2. it cannot handle the case when the partial or whole range of
requested memory is already tested.
The patch fixes the two bugs.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Marc Zyngier [Tue, 6 Mar 2018 13:00:35 +0000 (13:00 +0000)]
ArmPkg/TimerDxe: Always perform an EOI, even for spurious interrupts
The generic timer driver only EOIs the timer interrupt if
the ISTATUS bit is set. This is completely fine if you pretend
that spurious interrupts do not exist. But as a matter of fact,
they do, and the first one will leave the interrupt activated
at the GIC level, making sure that no other interrupt can make
it anymore.
Making sure that each interrupt Ack is paired with an EOI is the
way to go. Oh, and enabling the interrupt each time it is taken
is completely pointless. We entered this function for a good
reason...
Star Zeng [Wed, 14 Feb 2018 09:10:36 +0000 (17:10 +0800)]
IntelSiliconPkg VTdPmrPei: Return SUCCESS when Mapping == NULL in Unmap
NULL is returned to Mapping when Operation is BusMasterCommonBuffer or
BusMasterCommonBuffer64 in PeiIoMmuMap().
So Mapping == NULL is valid when calling PeiIoMmuUnmap().
940dbd071e9f01717236af236740aa0da716805f wrongly changed EFI_SUCCESS
to EFI_INVALID_PARAMETER when Mapping == NULL in PeiIoMmuUnmap().
This patch is to correct it.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Laszlo Ersek [Thu, 1 Mar 2018 21:05:55 +0000 (22:05 +0100)]
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map
Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>:
[PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State
http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com
https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html
Original commit message from Brijesh:
> When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE +
> SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by
> both guest and hypervisor. Since the data need to be accessed by both
> hence we must map the SMMSaved State area as unencrypted (i.e C-bit
> cleared).
>
> This patch clears the SavedStateArea address before SMBASE relocation.
> Currently, we do not clear the SavedStateArea address after SMBASE is
> relocated due to the following reasons:
>
> 1) Guest BIOS never access the relocated SavedStateArea.
>
> 2) The C-bit works on page-aligned address, but the SavedStateArea
> address is not a page-aligned. Theoretically, we could roundup the
> address and clear the C-bit of aligned address but looking carefully we
> found that some portion of the page contains code -- which will causes a
> bigger issue for the SEV guest. When SEV is enabled, all the code must
> be encrypted otherwise hardware will cause trap.
Changes by Laszlo:
- separate AmdSevDxe bits from SmmCpuFeaturesLib bits;
- spell out PcdLib dependency with #include and in LibraryClasses;
- replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation
with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages()
function;
- consequently, pass page-aligned BaseAddress to
MemEncryptSevClearPageEncMask();
- zero the pages before clearing the C-bit;
- pass Flush=TRUE to MemEncryptSevClearPageEncMask();
- harden the treatment of MemEncryptSevClearPageEncMask() failure.
Laszlo Ersek [Thu, 1 Mar 2018 19:59:12 +0000 (20:59 +0100)]
OvmfPkg/SmmCpuFeaturesLib: SEV: encrypt+free pages of init. save state map
Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>:
[PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State
http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com
https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html
Once PiSmmCpuDxeSmm relocates SMBASE for all VCPUs, the pages of the
initial SMRAM save state map can be re-encrypted (including zeroing them
out after setting the C-bit on them), and they can be released to DXE for
general use (undoing the allocation that we did in PlatformPei's
AmdSevInitialize() function).
The decryption of the same pages (which will occur chronologically
earlier) is implemented in the next patch; hence the "re-encryption" part
of this patch is currently a no-op. The series is structured like this in
order to be bisection-friendly. If the decryption patch preceded this
patch, then an info leak would be created while standing between the
patches.
Laszlo Ersek [Thu, 1 Mar 2018 16:59:19 +0000 (17:59 +0100)]
OvmfPkg/PlatformPei: SEV: allocate pages of initial SMRAM save state map
In the next two patches, we'll temporarily decrypt the pages containing
the initial SMRAM save state map, for SMBASE relocation. (Unlike the
separate, relocated SMRAM save state map of each VCPU, the original,
shared map behaves similarly to a "common buffer" between guest and host.)
The decryption will occur near the beginning of the DXE phase, in
AmdSevDxe, and the re-encryption will occur in PiSmmCpuDxeSmm, via OVMF's
SmmCpuFeaturesLib instance.
There is a non-trivial time gap between these two points, and the DXE
phase might use the pages overlapping the initial SMRAM save state map for
arbitrary purposes meanwhile. In order to prevent any information leak
towards the hypervisor, make sure the DXE phase puts nothing in those
pages until re-encryption is done.
Creating a memalloc HOB for the area in question is safe:
- the temporary SEC/PEI RAM (stack and heap) is based at
PcdOvmfSecPeiTempRamBase, which is above 8MB,
- the permanent PEI RAM (installed in PlatformPei's PublishPeiMemory()
function) never starts below PcdOvmfDxeMemFvBase, which is also above
8MB.
The allocated pages can be released to the DXE phase after SMBASE
relocation and re-encryption are complete.
Laszlo Ersek [Thu, 1 Mar 2018 16:31:44 +0000 (17:31 +0100)]
OvmfPkg/MemEncryptSevLib: find pages of initial SMRAM save state map
In the next three patches, we're going to modify three modules under
OvmfPkg. When OVMF is built with -D SMM_REQUIRE and runs in an SEV guest,
each affected module will have to know the page range that covers the
initial (pre-SMBASE relocation) SMRAM save state map. Add a helper
function to MemEncryptSevLib that calculates the "base address" and
"number of pages" constants for this page range.
(In a RELEASE build -- i.e., with assertions disabled and optimization
enabled --, the helper function can be compiled to store two constants
determined at compile time.)
Laszlo Ersek [Thu, 1 Mar 2018 17:55:09 +0000 (18:55 +0100)]
OvmfPkg/SmmCpuFeaturesLib: rewrap to 79 columns
There are many overlong lines; it's hard to work with the library like
this. Rewrap all files to 79 columns.
(
The rewrapping of the "mSmmCpuRegisterRanges" and "mSmmCpuWidthOffset"
arrays was verified by hexdumping the arrays in
SmmCpuFeaturesLibConstructor(), both before and after the patch, and
comparing the dumps.
Laszlo Ersek [Thu, 1 Mar 2018 14:15:39 +0000 (15:15 +0100)]
OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryEncrypted() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "clear" reference to the C-bit with a "set" reference.
Laszlo Ersek [Thu, 1 Mar 2018 14:15:39 +0000 (15:15 +0100)]
OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryDecrypted() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "set" reference to the C-bit with a "clear" reference.
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevSetPageEncMask() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Replace any
leftover "clear" references to the C-bit with "set" references. Also
remove any excess space in the comment block, and unindent the trailing
"**/" if necessary. Correct several parameter references.
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevClearPageEncMask() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Also remove
any excess space in the comment block, and unindent the trailing "**/" if
necessary. Correct several parameter references.
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevIsEnabled() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Also remove
any excess space in the comment block, and unindent the trailing "**/" if
necessary.
Laszlo Ersek [Fri, 2 Mar 2018 16:11:52 +0000 (17:11 +0100)]
BaseTools/GenVtf: silence false "stringop-overflow" warning with memcpy()
gcc-8 (which is part of Fedora 28) enables the new warning
"-Wstringop-overflow" in "-Wall". This warning is documented in detail at
<https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says
> Warn for calls to string manipulation functions such as memcpy and
> strcpy that are determined to overflow the destination buffer.
It breaks the BaseTools build with:
> GenVtf.c: In function 'ConvertVersionInfo':
> GenVtf.c:132:7: error: 'strncpy' specified bound depends on the length
> of the source argument [-Werror=stringop-overflow=]
> strncpy (TemStr + 4 - Length, Str, Length);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> GenVtf.c:130:14: note: length computed here
> Length = strlen(Str);
> ^~~~~~~~~~~
It is a false positive because, while the bound equals the length of the
source argument, the destination pointer is moved back towards the
beginning of the destination buffer by the same amount (and this amount is
range-checked first, so we can't precede the start of the dest buffer).
Laszlo Ersek [Fri, 2 Mar 2018 16:11:52 +0000 (17:11 +0100)]
BaseTools/header.makefile: add "-Wno-restrict"
gcc-8 (which is part of Fedora 28) enables the new warning
"-Wrestrict" in "-Wall". This warning is documented in detail
at <https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says
> Warn when an object referenced by a restrict-qualified parameter (or, in
> C++, a __restrict-qualified parameter) is aliased by another argument,
> or when copies between such objects overlap.
It breaks the BaseTools build (in the Brotli compression library) with:
> In function 'ProcessCommandsInternal',
> inlined from 'ProcessCommands' at dec/decode.c:1828:10:
> dec/decode.c:1781:9: error: 'memcpy' accessing between 17 and 2147483631
> bytes at offsets 16 and 16 overlaps between 17 and 2147483631 bytes at
> offset 16 [-Werror=restrict]
> memcpy(copy_dst + 16, copy_src + 16, (size_t)(i - 16));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In function 'ProcessCommandsInternal',
> inlined from 'SafeProcessCommands' at dec/decode.c:1833:10:
> dec/decode.c:1781:9: error: 'memcpy' accessing between 17 and 2147483631
> bytes at offsets 16 and 16 overlaps between 17 and 2147483631 bytes at
> offset 16 [-Werror=restrict]
> memcpy(copy_dst + 16, copy_src + 16, (size_t)(i - 16));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paolo Bonzini <pbonzini@redhat.com> analyzed the Brotli source in detail,
and concluded that the warning is a false positive:
> This seems safe to me, because it's preceded by:
>
> uint8_t* copy_dst = &s->ringbuffer[pos];
> uint8_t* copy_src = &s->ringbuffer[src_start];
> int dst_end = pos + i;
> int src_end = src_start + i;
> if (src_end > pos && dst_end > src_start) {
> /* Regions intersect. */
> goto CommandPostWrapCopy;
> }
>
> If [src_start, src_start + i) and [pos, pos + i) don't intersect, then
> neither do [src_start + 16, src_start + i) and [pos + 16, pos + i).
>
> The if seems okay:
>
> (src_start + i > pos && pos + i > src_start)
>
> which can be rewritten to:
>
> (pos < src_start + i && src_start < pos + i)
>
> Then the numbers are in one of these two orders:
>
> pos <= src_start < pos + i <= src_start + i
> src_start <= pos < src_start + i <= pos + i
>
> These two would be allowed by the "if", but they can only happen if pos
> == src_start so they degenerate to the same two orders above:
>
> pos <= src_start < src_start + i <= pos + i
> src_start <= pos < pos + i <= src_start + i
>
> So it is a false positive in GCC.
gcc-8 (which is part of Fedora 28) enables the new warning
"-Wstringop-truncation" in "-Wall". This warning is documented in detail
at <https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says
> Warn for calls to bounded string manipulation functions such as strncat,
> strncpy, and stpncpy that may either truncate the copied string or leave
> the destination unchanged.
It breaks the BaseTools build with:
> EfiUtilityMsgs.c: In function 'PrintMessage':
> EfiUtilityMsgs.c:484:9: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
> strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> EfiUtilityMsgs.c:469:9: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
> strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> EfiUtilityMsgs.c:511:5: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
> strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The right way to fix the warning would be to implement string concat with
snprintf(). However, Microsoft does not appear to support snprintf()
before VS2015
<https://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010>,
so we just have to shut up the warning. The strncat() calls flagged above
are valid BTW.
Ruiyu Ni [Fri, 2 Mar 2018 09:35:41 +0000 (17:35 +0800)]
MdeModulePkg/UsbMass: Retry CMD for MediaChanged sense key
When a USB device reports failure for a CMD and REQUEST SENSE returns
Media Changed key, UsbBootExecCmdWithRetry() stops to retry CMD and
returns EFI_MEDIA_CHANGED to caller.
For this case, the CMD should be retried until success, getting
NoMedia sense key or timeout.
The patch updates UsbBootExecCmdWithRetry() to follow the above
rule so EFI_MEDIA_CHANGED is no longer returned.
UsbBootDetectMedia() is updated accordingly.
Because UsbBootGetParams() is called for new plugged USB storage,
and some USB storage devices may report Media Changed key,
UsbBootGetParams() is updated to treat it as a Success.
This change could fix the issue that some USB storage devices
cannot be detected.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
The above commit fixed the following issue:
When system boots to Shell without CDROM inside USB CDROM drive,
and then user inserts the CDROM with Eltorito file system,
"map -r" cannot show the new ELtorito file system.
The commit caused EFI_MEDIA_CHANGED status returned from
UsbBootDetectMedia().
But that fix exposes another issue:
When issuing ReadCapacity command to certain USB key
(Kingston DataTraveler G3 8GB) after it's hot-plugged, USB device
returns STALL error and RequestSense command returns media changed
sense data. (Most of the USB keys return SUCCESS for ReadCapacity
command after hot-plug.)
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
UsbBootExecCmd() only calls UsbBootRequestSense() to get sense key
when CMD fails.
When POWER ON (29h) ASC returns from REQUEST SENSE, implementation
should retry the CMD, instead of treating this as a SUCCESS.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Yonghong Zhu [Fri, 2 Mar 2018 15:07:06 +0000 (23:07 +0800)]
BaseTools: Fix byte orders when handling 8-byte array
Per UEFI spec, FibreEx.WWN, FibreEx.Lun, SasEx.Address, SasEx.Lun
and iSCSI.Lun are all 8-byte array with byte #0 in the left.
It means "0102030405060708" should be converted to:
UINT8[8] = {01, 02, 03, 04, 05, 06, 07, 08}
or UINT64 = {0807060504030201}
Today's implementation wrongly uses the reversed order.
The patch fixes this issue by using StrHexToBytes().
Copy this solution from MdePkg Hash version d0196be.
Yonghong Zhu [Fri, 2 Mar 2018 15:03:34 +0000 (23:03 +0800)]
BaseTools: Fix bug when converting iSCSI node
If protocol string is not specified, default TCP(0) should be used.
Today's implementation wrongly sets to 1 for this case.
Copy the fix solution from MdePkg Hash version e6c80aea.
Ruiyu Ni [Fri, 2 Mar 2018 11:50:30 +0000 (19:50 +0800)]
MdePkg/DevicePathFromText: Fix byte orders of iSCSI.Lun
Per UEFI spec, iSCSI.Lun is a 8-byte array with byte #0 in the left.
It means "0102030405060708" should be converted to:
UINT8[8] = {01, 02, 03, 04, 05, 06, 07, 08}
or UINT64 = {0807060504030201}
Today's implementation wrongly uses the reversed order.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jie Lin <jie.lin@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Star Zeng [Fri, 8 Dec 2017 10:04:54 +0000 (18:04 +0800)]
MdeModulePkg: Add S3SmmInitDone definition
Add gEdkiiS3SmmInitDoneGuid, after S3 SMM initialization is done and
before S3 boot script is executed, this GUID is installed as PPI in
PEI and protocol in SMM environment. It allows for PEIMs or SMM
drivers to hook this point and do the required tasks.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Yonghong Zhu [Fri, 2 Mar 2018 17:09:03 +0000 (01:09 +0800)]
BaseTools: Fix the bug to search Fv.txt file relative to workspace
when the SECTION FV_IMAGE = $(XX)/XX.Fv, the Fv file should relative to
WORKSPACE, so when we search the XX.Fv.txt file, we should search the
path relative to workspace first.
Yunhua Feng [Sat, 3 Mar 2018 01:12:18 +0000 (09:12 +0800)]
BaseTools: DSC Components section support flexible PCD
DSC Components section support flexible PCD, and for binary driver, we
need patch this value. Update the split char ',' not ', ' because some
value may have space, while others may not have this space.
Fu Siyuan [Fri, 2 Mar 2018 03:33:28 +0000 (11:33 +0800)]
MdeModulePkg/Mtftp4Dxe: Separate the timer ticking to calculate the packet live time.
TPL deadlock issue was enrolled by the commit of 39b0867d. To resolve the issue,
this patch separated the timer ticking for all the MTFTP clients to calculate the
packet live time in TPL_NOTIFY level.
Cc: Wang Fan <fan.wang@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Dandan Bi [Thu, 1 Mar 2018 07:08:01 +0000 (15:08 +0800)]
MdeModulePkg: Fix incorrect commit introduced by commit SHA-1:052c98
The default value of PcdExtFpdtBootRecordPadSize is 0x20000
But the following commit in master update it to 0 by mistake.
SHA-1: 052c98ce246a1ffb0b4c5185a644aa9f902650f7
Subject: MdeModulePkg: Add ResetSystemPei PEIM
This patch is to restore the value.
Cc: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Ruiyu Ni <ruiyu.ni@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> Reviewed-by: Star Zeng <star.zeng@intel.com>
Dandan Bi [Thu, 1 Mar 2018 05:40:48 +0000 (13:40 +0800)]
MdeModulePkg/DxeCorePerfLib: Add status check instead of ASSERT
Currently DxeCorePerformanceLib will get SMM performance data based
on SMM communication handler. If SMM communication handler returns error,
the library will ASSERT. In fact, if SMM perf data is not found.
DXE perf data can still be dumped. So using status check instead of
ASSERT is better.
Ruiyu Ni [Thu, 1 Mar 2018 06:33:43 +0000 (14:33 +0800)]
MdeModulePkg/DebugLibReportStatusCode: Fix hang if format is too long
The previous commit 137ed15511e2045a7333e33ae7f1e873ce1961dd
* MdeModulePkg/DebugLib: Print partial when format string is too long
copies partial format string to DEBUG_INFO buffer but when parsing
the format modifier, the original format string is still used.
Jiaxin Wu [Thu, 1 Mar 2018 09:24:20 +0000 (17:24 +0800)]
NetworkPkg/Udp6Dxe: Fix the failure to leave one multicast group address.
The issue was enrolled by the commit of ceec3638. One of the change in the commit
was to return the status from NetMapIterate in Udp6Groups function. But it should
not return EFI_ABORTED directly in case McastIp is not NULL, which means to terminate
the iteration and leave the McastIp successfully.
Cc: Wang Fan <fan.wang@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Jiaxin Wu [Thu, 1 Mar 2018 04:59:57 +0000 (12:59 +0800)]
NetworkPkg/HttpBootDxe: Fix the incorrect error message output.
For IPv6 case, if one invalid URL returned from DHCP server, HttpBootDxe
driver could not retrieve the URL host address from DNS server. In such a
case, the error message should be printed as:
Error: Could not retrieve the host address from DNS server.
Instead of:
Error: Could not discover the boot information for DHCP server.
Then, we can still output as following:
Error: Could not retrieve NBP file size from HTTP server.
Besides, currently implementation in HttpBootLoadFile will always output
error message even the HTTP process is correct.
This patch is to fix above issue.
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: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
Yonghong Zhu [Thu, 1 Mar 2018 05:48:31 +0000 (13:48 +0800)]
BaseTools: Fix the bug for display incorrect *M flag in report
The root cause is the byte array value in the driver Pcd, some bytes
have additional space character, while the value in DSC file doesn't
have this space, it cause the string compare return false, so we remove
the extra space.
Feng, YunhuaX [Thu, 1 Mar 2018 02:16:07 +0000 (10:16 +0800)]
BaseTools: Fix eval parse string issue
eval argument start with " or ', but it is unicode string,
will encounter error:
List = list(eval(Value)) # translate escape character
File "<string>", line 1
'j??=????????F??
^
SyntaxError: EOL while scanning string literal
Feng, YunhuaX [Thu, 1 Mar 2018 02:23:14 +0000 (10:23 +0800)]
BaseTools: GlobalData.gConfDirectory is None when run GenFds
When run GenFds, GlobalData.gConfDirectory is None, On Linux
self._ToolChainFamily default Value is "MSFT", and then
generate the wrong PcdValueInit Makefile
Ard Biesheuvel [Thu, 1 Mar 2018 09:27:31 +0000 (09:27 +0000)]
ShellPkg/UefiShellDebug1CommandsLib: remove I/O address limit from 'mm'
Neither the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL nor the EFI_CPU_IO2_PROTOCOL
impose any restrictions when it comes to the range of valid I/O
addresses. Even so, the 'mm' command in -IO mode refuses to perform
accesses to addresses >= 0xffff.
It is not up to 'mm' to impose this restriction, so remove it.
Yonghong Zhu [Wed, 28 Feb 2018 03:09:39 +0000 (11:09 +0800)]
BaseTools: Enhance FV info report file path to support absolute path
When generate build report, Tool will get the info like size, Fv Name,
etc from the xx.Fv.txt file and add these info into the build report.
This patch support the xx.Fv.txt to use absolute file path format since
user may provide specified FV path.
Based on content from the following branch/commit:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
https://github.com/Microsoft/MS_UEFI/commit/33bab4031a417d7d5a7d356c15a14c2e60302b2d
Add check to see if the Boot Logo 2 Protocol is available
and attempt to set the location and size of the boot logo
using both the Boot Logo Protocol and the Boot Logo 2
Protocol.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Based on content from the following branch/commit:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
https://github.com/Microsoft/MS_UEFI/commit/33bab4031a417d7d5a7d356c15a14c2e60302b2d
Update BootGraphicsResourceDxe to produce both the Boot Logo
Protocol and the Boot Logo 2 Protocol.
The Boot Logo 2 Protocol service GetBootLogo() is amended
to return the pointer to the GOP BLT buffer previously
registered with the SetBootLogo() service.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Based on content from the following branch/commit:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
https://github.com/Microsoft/MS_UEFI/commit/33bab4031a417d7d5a7d356c15a14c2e60302b2d
Add new Boot Logo 2 Protocol that adds a GetBootLogo()
service that can be used to retrieve the GOP BLT buffer,
location, and size of the boot logo that was previously
registered with the SetBootLogo() service.
The Boot Logo 2 Protocol service GetBootLogo() is amended
to return the pointer to the GOP BLT buffer previously
registered with the SetBootLogo() service.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Ard Biesheuvel [Wed, 28 Feb 2018 15:31:34 +0000 (15:31 +0000)]
ArmPlatformPkg/MemoryInitPeiLib: reserve rather than remove FV memory
Instead of completely removing the memory occupied by the primary PrePi
FV from the memory map, thereby making it inaccessible to the OS, mark
it as boot services data. This will ensure that the memory is left
untouched by the firmware, but will release it to the OS when it calls
ExitBootServices().
Note that for reasons that are not entirely clear, this only works as
desired if the memory allocation HOB and the resource descriptor HOB
that describe the region are identical in offset and size, and so we
still need to iterate over the descriptors and split them up.
Ard Biesheuvel [Wed, 28 Feb 2018 15:27:15 +0000 (15:27 +0000)]
ArmPlatformPkg/MemoryInitPeiLib: revert "don't reserve primary FV in memory"
Commit 8ae5fc182941 ("ArmPlatformPkg/MemoryInitPeiLib: don't reserve
primary FV in memory") deleted the code that removes the memory covering
the primary firmware volume from the memory map. The assumption was that
this is no longer necessary now that we no longer expose compression and
PE/COFF loader library code from the PrePi module to DXE core.
However, the FV is still declared, and so code may attempt to access it
anyway, which may cause unexpected results depending on whether the
memory has been reused for other purposes in the mean time. So revert
this change in preparation of dealing with this in a better way.
Ard Biesheuvel [Tue, 27 Feb 2018 17:47:06 +0000 (17:47 +0000)]
BaseTools/tools_def: use separate PP definition for DTC
Clang's preprocessor behaves differently from GCC's, and produces
intermediate device tree source that still contains #pragma pack()
and other directives that the device tree compiler chokes on.
For assembling device tree sources, it matters very little which
preprocessor is being used, so let's just use GNU CPP explicitly.
The field KnownGoodStackTop in CPU_EXCEPTION_INIT_DATA is initialized to
the start address of array mNewStack. This is wrong. It must be the end
of mNewStack. This patch fixes this mistake.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Yonghong Zhu [Mon, 26 Feb 2018 07:36:47 +0000 (15:36 +0800)]
BaseTools: Fix a bug override Pcd by DSC Components section
The case is: define a VOID* pcd in DEC file, eg: Value is {0x1}.
then override this PCD on DSC component section, eg: Value is
{0x1, 0x2, 0x3}, the max size of this PCD is calculate wrong
which cause build error.
v2: Add [LibraryClasses] section in INF file and refine coding style.
There are VS2015 NOOPT IA32 build failure like below in BaseSafeIntLib.
XXX.lib(XXX.obj): error LNK2001: unresolved external symbol __allmul
XXX.lib(XXX.obj): error LNK2001: unresolved external symbol __allshl
XXX.lib(XXX.obj): error LNK2001: unresolved external symbol __aullshr
This patch replaces direct shift/multiplication of 64-bit integer
with related function call to fix these failure.