BaseTools/Scripts/PatchCheck.py: Detect emails rewritten by Groups.Io
Due to strict DMARC / DKIM / SPF rules, Groups.Io sometimes rewrite
the author email. See for example commit df851da3ceff5b6bcf5e12616.
Add a check to detect these rewrites with PatchCheck.py.
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Commit fd30b00707 updated the logic in function MicrocodeDetect() that
will directly use the CPUID and PlatformID information from the 'CpuData'
field in the CPU_MP_DATA structure, instead of collecting these
information for each processor via AsmCpuid() and AsmReadMsr64() calls
respectively.
At that moment, this approach worked fine for APs. Since:
a) When the APs are waken up for the 1st time (1st MpInitLibInitialize()
entry at PEI phase), the function InitializeApData() will be called for
each AP and the CPUID and PlatformID information will be collected.
b) During the 2nd entry of MpInitLibInitialize() at DXE phase, when the
APs are waken up again, the function InitializeApData() will not be
called, which means the CPUID and PlatformID information will not be
collected. However, the below logics in MicrocodeDetect() function:
CurrentRevision = GetCurrentMicrocodeSignature ();
IsBspCallIn = (ProcessorNumber == (UINTN)CpuMpData->BspNumber) ? TRUE : FALSE;
if (CurrentRevision != 0 && !IsBspCallIn) {
//
// Skip loading microcode if it has been loaded successfully
//
return;
}
will ensure that the microcode detection and application will be
skipped due to the fact that such process has already been done in the
PEI phase.
But after commit 396e791059, which removes the above skip loading logic,
the CPUID and PlatformID information on APs will be used upon the 2nd
entry of the MpInitLibInitialize(). But since the CPUID and PlatformID
information has not been collected, it will bring issue to the microcode
detection process.
This commit will update the logic in MicrocodeDetect() back to always
collecting the CPUID and PlatformID information explicitly.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)
Now that the SMRAM at the default SMBASE is honored everywhere necessary,
implement the actual detection. The (simple) steps are described in
previous patch "OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register
macros".
Regarding CSM_ENABLE builds: according to the discussion with Jiewen at
if the platform has SMRAM at the default SMBASE, then we have to
(a) either punch a hole in the legacy E820 map as well, in
LegacyBiosBuildE820() [OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c],
(b) or document, or programmatically catch, the incompatibility between
the "SMRAM at default SMBASE" and "CSM" features.
Because CSM is out of scope for the larger "VCPU hotplug with SMM"
feature, option (b) applies. Therefore, if the CSM is enabled in the OVMF
build, then PlatformPei will not attempt to detect SMRAM at the default
SMBASE, at all. This is approach (4) -- the most flexible one, for
end-users -- from:
Laszlo Ersek [Wed, 29 Jan 2020 18:53:18 +0000 (19:53 +0100)]
OvmfPkg: introduce PcdCsmEnable feature flag
In the DXE phase and later, it is possible for a module to dynamically
determine whether a CSM is enabled. An example can be seen in commit 855743f71774 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no
CSM", 2016-05-25).
SEC and PEI phase modules cannot check the Legacy BIOS Protocol however.
For their sake, introduce a new feature PCD that simply reflects the
CSM_ENABLE build flag.
OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASE
During normal boot, when EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed
by platform BDS, the SMM IPL locks SMRAM (TSEG) through
EFI_SMM_ACCESS2_PROTOCOL.Lock(). See SmmIplReadyToLockEventNotify() in
"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c".
During S3 resume, S3Resume2Pei locks SMRAM (TSEG) through
PEI_SMM_ACCESS_PPI.Lock(), before executing the boot script. See
S3ResumeExecuteBootScript() in
"UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c".
Those are precisely the places where the SMRAM at the default SMBASE
should be locked too. Add such an action to SmramAccessLock().
Notes:
- The SMRAM at the default SMBASE doesn't support the "closed and
unlocked" state (and so it can't be closed without locking it, and it
cannot be opened after closing it).
- The SMRAM at the default SMBASE isn't (and shouldn't) be exposed with
another EFI_SMRAM_DESCRIPTOR in the GetCapabilities() members of
EFI_SMM_ACCESS2_PROTOCOL / PEI_SMM_ACCESS_PPI. That's because the SMRAM
in question is not "general purpose"; it's only QEMU's solution to
protect the initial SMI handler from the OS, when a VCPU is hot-plugged.
Consequently, the state of the SMRAM at the default SMBASE is not
reflected in the "OpenState" / "LockState" fields of the protocol and
PPI.
- An alternative to extending SmramAccessLock() would be to register an
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL notify in SmmAccess2Dxe (for locking
at normal boot), and an EDKII_S3_SMM_INIT_DONE_GUID PPI notify in
SmmAccessPei (for locking at S3 resume).
OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASE
When OVMF runs in a SEV guest, the initial SMM Save State Map is
(1) allocated as EfiBootServicesData type memory in OvmfPkg/PlatformPei,
function AmdSevInitialize(), for preventing unintended information
sharing with the hypervisor;
(2) decrypted in AmdSevDxe;
(3) re-encrypted in OvmfPkg/Library/SmmCpuFeaturesLib, function
SmmCpuFeaturesSmmRelocationComplete(), which is called by
PiSmmCpuDxeSmm right after initial SMBASE relocation;
(4) released to DXE at the same location.
The SMRAM at the default SMBASE is a superset of the initial Save State
Map. The reserved memory allocation in InitializeRamRegions(), from the
previous patch, must override the allocating and freeing in (1) and (4),
respectively. (Note: the decrypting and re-encrypting in (2) and (3) are
unaffected.)
In AmdSevInitialize(), only assert the containment of the initial Save
State Map, in the larger area already allocated by InitializeRamRegions().
In SmmCpuFeaturesSmmRelocationComplete(), preserve the allocation of the
initial Save State Map into OS runtime, as part of the allocation done by
InitializeRamRegions(). Only assert containment.
These changes only affect the normal boot path (the UEFI memory map is
untouched during S3 resume).
OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it exists
The 128KB SMRAM at the default SMBASE will be used for protecting the
initial SMI handler for hot-plugged VCPUs. After platform reset, the SMRAM
in question is open (and looks just like RAM). When BDS signals
EFI_DXE_MM_READY_TO_LOCK_PROTOCOL (and so TSEG is locked down), we're
going to lock the SMRAM at the default SMBASE too.
For this, we have to reserve said SMRAM area as early as possible, from
components in PEI, DXE, and OS runtime.
* QemuInitializeRam() currently produces a single resource descriptor HOB,
for exposing the system RAM available under 1GB. This occurs during both
normal boot and S3 resume identically (the latter only for the sake of
CpuMpPei borrowing low RAM for the AP startup vector).
But, the SMRAM at the default SMBASE falls in the middle of the current
system RAM HOB. Split the HOB, and cover the SMRAM with a reserved
memory HOB in the middle. CpuMpPei (via MpInitLib) skips reserved memory
HOBs.
* InitializeRamRegions() is responsible for producing memory allocation
HOBs, carving out parts of the resource descriptor HOBs produced in
QemuInitializeRam(). Allocate the above-introduced reserved memory
region in full, similarly to how we treat TSEG, so that DXE and the OS
avoid the locked SMRAM (black hole) in this area.
(Note that these allocations only occur on the normal boot path, as they
matter for the UEFI memory map, which cannot be changed during S3
resume.)
OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default SMBASE
The permanent PEI RAM that is published on the normal boot path starts
strictly above MEMFD_BASE_ADDRESS (8 MB -- see the FDF files), regardless
of whether PEI decompression will be necessary on S3 resume due to
SMM_REQUIRE. Therefore the normal boot permanent PEI RAM never overlaps
with the SMRAM at the default SMBASE (192 KB).
The S3 resume permanent PEI RAM is strictly above the normal boot one.
Therefore the no-overlap statement holds true on the S3 resume path as
well.
Assert the no-overlap condition commonly for both boot paths in
PublishPeiMemory().
OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton)
Introduce the Q35SmramAtDefaultSmbaseInitialization() function for
detecting the "SMRAM at default SMBASE" feature.
For now, the function is only a skeleton, so that we can gradually build
upon the result while the result is hard-coded as FALSE. The actual
detection will occur in a later patch.
OvmfPkg/PlatformPei: factor out Q35BoardVerification()
Before adding another SMM-related, and therefore Q35-only, dynamically
detectable feature, extract the current board type check from
Q35TsegMbytesInitialization() to a standalone function.
In Intel datasheet 316966-002 (the "q35 spec"), Table 5-1 "DRAM Controller
Register Address Map (D0:F0)" leaves the byte register at config space
offset 0x9C unused.
On QEMU's Q35 board, for detecting the "SMRAM at default SMBASE" feature,
firmware is expected to write MCH_DEFAULT_SMBASE_QUERY (0xFF) to offset
MCH_DEFAULT_SMBASE_CTL (0x9C), and read back the register. If the value is
MCH_DEFAULT_SMBASE_IN_RAM (0x01), then the feature is available, and the
range mentioned below is open (accessible to code running outside of SMM).
Then, once firmware writes MCH_DEFAULT_SMBASE_LCK (0x02) to the register,
the MCH_DEFAULT_SMBASE_SIZE (128KB) range at 0x3_0000 (SMM_DEFAULT_SMBASE)
gets closed and locked down, and the register becomes read-only. The area
is reopened, and the register becomes read/write, at platform reset.
Add the above-listed macros to "Q35MchIch9.h".
(There are some other unused offsets in Table 5-1; for example we had
scavenged 0x50 for implementing the extended TSEG feature. 0x9C is the
first byte-wide register standing in isolation after 0x50.)
OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defs
In a subsequent patch, we'll introduce new DRAM controller macros in
"Q35MchIch9.h". Their names are too long for the currently available
vertical whitespace, so increase the latter first.
There is no functional change in this patch ("git show -b" displays
nothing).
For supporting VCPU hotplug with SMM enabled/required, QEMU offers the
(dynamically detectable) feature called "SMRAM at default SMBASE". When
the feature is enabled, the firmware can lock down the 128 KB range
starting at the default SMBASE; that is, the [0x3_0000, 0x4_FFFF]
interval. The goal is to shield the very first SMI handler of the
hotplugged VCPU from OS influence.
Multiple modules in OVMF will have to inter-operate for locking down this
range. Introduce a dynamic PCD that will reflect the feature (to be
negotiated by PlatformPei), for coordination between drivers.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
When using structured PCDs, a C application is auto generated
to fill in the structured PCD value. The C application uses
the standard include files <stdio.h>, <stdlib.h>, and <string.h>.
This C application also supports include paths from package DEC
files when a structured PCD declaration provides a <Packages>
list. The complete list of include paths are -I options for
include paths from package DEC files and the compiler's standard
include paths.
-I include paths are higher priority than the standard include
paths. If the -I included paths from package DEC files contain
<stdio.h>, <stdlib.h>, or <string.h> the wrong include files are
used to compile the C application for the structured PCD value.
Update GenerateByteArrayValue() to skip a package DEC include
paths that contain <stdio.h>, <stdlib.h>, or <string.h>.
Build failures were observed when adding a structured PCD to
CryptoPkg. CryptoPkg contains <stdio.h>, <stdlib.h>, and
<string.h> in the path CryptoPkg/Library/Include to support
building Open SSL. The Library/Include path is listed as a
private include path in CryptoPkg.dec. Without this change, the
standard include files designed to support build OpenSLL are
used to build the structured PCD C application, and that build
fails.
Other packages that provide a standard C lib or a gasket for
a subset of the standard C lib will run into this same issue
if they also define and use a Structured PCD. So this issue
is not limited to the CryptoPkg.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
This commit introduces a Unified Hash API to calculate hash using a
hashing algorithm specified by the PCD, PcdHashApiLibPolicy. This library
interfaces with the various hashing API, such as, MD4, MD5, SHA1, SHA256,
SHA512 and SM3_256 implemented in BaseCryptLib. The user can calculate
the desired hash by setting PcdHashApiLibPolicy to appropriate value.
This feature is documented in the Bugzilla,
https://bugzilla.tianocore.org/show_bug.cgi?id=2151.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Amol N Sukerkar <amol.n.sukerkar@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Added CryptoPkg Token Space GUID to be able to define PCDs.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Amol N Sukerkar <amol.n.sukerkar@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Laszlo Ersek [Thu, 16 Jan 2020 18:24:34 +0000 (19:24 +0100)]
BaseTools/Conf/gitattributes: fix "--function-context" for C source code
The "--function-context" ("-W") option of git-diff displays the entire
body of a modified function, not just small modified hunks within the
function. It is useful for reviewers when the code changes to the function
are small, but they could affect, or depend on, control flow that is far
away in the same function.
Of course, the size of the displayed context can be controlled with the
"-U" option anyway, but such fixed-size contexts are usually either too
small, or too large, in the above scenario.
It turns out that "--function-context" does not work correctly for C
source files in edk2. In particular, labels for the goto instruction
(which the edk2 coding style places in the leftmost column) appear to
terminate "--function-context".
The "git" utility contains built-in hunk header patterns for the C and C++
languages. However, they do not take effect in edk2 because we don't
explicitly assign the "cpp" git-diff driver to our C files. The
gitattributes(5) manual explains that this is required:
> There are a few built-in patterns to make this easier, and
> tex is one of them, so you do not have to write the above in
> your configuration file (you still need to enable this with
> the attribute mechanism, via .gitattributes). The following
> built in patterns are available:
>
> [...]
>
> * cpp suitable for source code in the C and C++
> languages.
The key statement is the one in parentheses.
Grab the suffix lists from the [C-Code-File] and [Acpi-Table-Code-File]
sections of "BaseTools/Conf/build_rule.template", add "*.h" and "*.H", and
mark those as belonging to the "cpp" git-diff driver.
This change has a dramatic effect on the following command, for example:
Laszlo Ersek [Thu, 16 Jan 2020 13:45:38 +0000 (14:45 +0100)]
SecurityPkg/DxeImageVerificationHandler: fix "defer" vs. "deny" policies
In DxeImageVerificationHandler(), we should return EFI_SECURITY_VIOLATION
for a rejected image only if the platform sets
DEFER_EXECUTE_ON_SECURITY_VIOLATION as the policy for the image's source.
Otherwise, EFI_ACCESS_DENIED must be returned.
Right now, EFI_SECURITY_VIOLATION is returned for all rejected images,
which is wrong -- it causes LoadImage() to hold on to rejected images (in
untrusted state), for further platform actions. However, if a platform
already set DENY_EXECUTE_ON_SECURITY_VIOLATION, the platform will not
expect the rejected image to stick around in memory (regardless of its
untrusted state).
Therefore, adhere to the platform policy in the return value of the
DxeImageVerificationHandler() function.
Furthermore, according to "32.4.2 Image Execution Information Table" in
the UEFI v2.8 spec, and considering that edk2 only supports (AuditMode==0)
at the moment:
> When AuditMode==0, if the image's signature is not found in the
> authorized database, or is found in the forbidden database, the image
> will not be started and instead, information about it will be placed in
> this table.
we have to store an EFI_IMAGE_EXECUTION_INFO record in both the "defer"
case and the "deny" case. Thus, the AddImageExeInfo() call is not being
made conditional on (Policy == DEFER_EXECUTE_ON_SECURITY_VIOLATION); the
documentation is updated instead.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Fixes: 5db28a6753d307cdfb1cfdeb2f63739a9f959837 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-12-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
Laszlo Ersek [Thu, 16 Jan 2020 13:19:58 +0000 (14:19 +0100)]
SecurityPkg/DxeImageVerificationHandler: fix imgexec info on memalloc fail
It makes no sense to call AddImageExeInfo() with (Signature == NULL) and
(SignatureSize > 0). AddImageExeInfo() does not crash in such a case -- it
avoids the CopyMem() call --, but it creates an invalid
EFI_IMAGE_EXECUTION_INFO record. Namely, the
"EFI_IMAGE_EXECUTION_INFO.InfoSize" field includes "SignatureSize", but
the actual signature bytes are not filled in.
Document and ASSERT() this condition in AddImageExeInfo().
In DxeImageVerificationHandler(), zero out "SignatureListSize" if we set
"SignatureList" to NULL due to AllocateZeroPool() failure.
(Another approach could be to avoid calling AddImageExeInfo() completely,
in case AllocateZeroPool() fails. Unfortunately, the UEFI v2.8 spec does
not seem to state clearly whether a signature is mandatory in
EFI_IMAGE_EXECUTION_INFO, if the "Action" field is
EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED or EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND.
For now, the EFI_IMAGE_EXECUTION_INFO addition logic is not changed; we
only make sure that the record we add is not malformed.)
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-11-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
Laszlo Ersek [Thu, 16 Jan 2020 12:39:19 +0000 (13:39 +0100)]
SecurityPkg/DxeImageVerificationHandler: fix retval for (FileBuffer==NULL)
"FileBuffer" is a non-optional input (pointer) parameter to
DxeImageVerificationHandler(). Normally, when an edk2 function receives a
NULL argument for such a parameter, we return EFI_INVALID_PARAMETER or
RETURN_INVALID_PARAMETER. However, those don't conform to the
SECURITY2_FILE_AUTHENTICATION_HANDLER prototype.
Return EFI_ACCESS_DENIED when "FileBuffer" is NULL; it means that no image
has been loaded.
This patch does not change the control flow in the function, it only
changes the "Status" outcome from API-incompatible error codes to
EFI_ACCESS_DENIED, under some circumstances.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Fixes: 570b3d1a7278df29878da87990e8366bd42d0ec5 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-10-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
The "Status" variable is set to EFI_ACCESS_DENIED at the top of the
function. Then it is overwritten with EFI_SECURITY_VIOLATION under the
"Failed" (earlier: "Done") label. We finally return "Status".
The above covers the complete usage of "Status" in
DxeImageVerificationHandler(). Remove the variable, and simply return
EFI_SECURITY_VIOLATION in the end.
This patch is a no-op, regarding behavior.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-9-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
Before the "Done" label at the end of DxeImageVerificationHandler(), we
now have a single access to "Status": we set "Status" to EFI_ACCESS_DENIED
at the top of the function. Therefore, the (Status != EFI_SUCCESS)
condition is always true under the "Done" label.
Accordingly, unnest the AddImageExeInfo() call dependent on that
condition, remove the condition, and also rename the "Done" label to
"Failed".
Functionally, this patch is a no-op. It's easier to review with:
git show -b -W
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-8-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: replace EFI_D_INFO w/ DEBUG_INFO for PatchCheck.py]
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
Laszlo Ersek [Thu, 16 Jan 2020 12:19:26 +0000 (13:19 +0100)]
SecurityPkg/DxeImageVerificationHandler: remove superfluous Status setting
After the final "IsVerified" check, we set "Status" to EFI_ACCESS_DENIED.
This is superfluous, as "Status" already carries EFI_ACCESS_DENIED value
there, from the top of the function. Remove the assignment.
Functionally, this change is a no-op.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-7-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
Laszlo Ersek [Thu, 16 Jan 2020 12:07:46 +0000 (13:07 +0100)]
SecurityPkg/DxeImageVerificationHandler: fix retval on memalloc failure
A SECURITY2_FILE_AUTHENTICATION_HANDLER function is not expected to return
EFI_OUT_OF_RESOURCES. We should only return EFI_SUCCESS,
EFI_SECURITY_VIOLATION, or EFI_ACCESS_DENIED.
In case we run out of memory while preparing "SignatureList" for
AddImageExeInfo(), we should simply stick with the EFI_ACCESS_DENIED value
that is already in "Status" -- from just before the "Action" condition --,
and not suppress it with EFI_OUT_OF_RESOURCES.
This patch does not change the control flow in the function, it only
changes the "Status" outcome from API-incompatible error codes to
EFI_ACCESS_DENIED, under some circumstances.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Fixes: 570b3d1a7278df29878da87990e8366bd42d0ec5 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-6-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
Laszlo Ersek [Thu, 16 Jan 2020 11:56:59 +0000 (12:56 +0100)]
SecurityPkg/DxeImageVerificationHandler: narrow down PE/COFF hash status
Inside the "for" loop that scans the signatures of the image, we call
HashPeImageByType(), and assign its return value to "Status".
Beyond the immediate retval check, this assignment is useless (never
consumed). That's because a subsequent access to "Status" may only be one
of the following:
- the "Status" assignment when we call HashPeImageByType() in the next
iteration of the loop,
- the "Status = EFI_ACCESS_DENIED" assignment right after the final
"IsVerified" check.
To make it clear that the assignment is only useful for the immediate
HashPeImageByType() retval check, introduce a specific helper variable,
called "HashStatus".
This patch is a no-op, functionally.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-5-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
Laszlo Ersek [Thu, 16 Jan 2020 11:14:14 +0000 (12:14 +0100)]
SecurityPkg/DxeImageVerificationHandler: keep PE/COFF info status internal
The PeCoffLoaderGetImageInfo() function may return various error codes,
such as RETURN_INVALID_PARAMETER and RETURN_UNSUPPORTED.
Such error values should not be assigned to our "Status" variable in the
DxeImageVerificationHandler() function, because "Status" generally stands
for the main exit value of the function. And
SECURITY2_FILE_AUTHENTICATION_HANDLER functions are expected to return one
of EFI_SUCCESS, EFI_SECURITY_VIOLATION, and EFI_ACCESS_DENIED only.
Introduce the "PeCoffStatus" helper variable for keeping the return value
of PeCoffLoaderGetImageInfo() internal to the function. If
PeCoffLoaderGetImageInfo() fails, we'll jump to the "Done" label with
"Status" being EFI_ACCESS_DENIED, inherited from the top of the function.
Note that this is consistent with the subsequent PE/COFF Signature check,
where we jump to the "Done" label with "Status" having been re-set to
EFI_ACCESS_DENIED.
As a consequence, we can at once remove the
Status = EFI_ACCESS_DENIED;
assignment right after the "PeCoffStatus" check.
This patch does not change the control flow in the function, it only
changes the "Status" outcome from API-incompatible error codes to
EFI_ACCESS_DENIED, under some circumstances.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-4-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
with identical behavior, and improved readability (less nesting).
The same applies to "break" (instead of "return") in a loop body.
Perform these transformations on DxeImageVerificationHandler().
This patch is a no-op for behavior. Use
git show -b -W
for reviewing it more easily.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-3-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
In the DxeImageVerificationHandler() function, the "VerifyStatus" variable
can only contain one of two values: EFI_SUCCESS and EFI_ACCESS_DENIED.
Furthermore, the variable is only consumed with EFI_ERROR().
Therefore, using the EFI_STATUS type for the variable is unnecessary.
Worse, given the complex meanings of the function's return values, using
EFI_STATUS for "VerifyStatus" is actively confusing.
Rename the variable to "IsVerified", and make it a simple BOOLEAN.
This patch is a no-op, regarding behavior.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200116190705.18816-2-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: push with Mike's R-b due to Chinese New Year
Holiday: <https://edk2.groups.io/g/devel/message/53429>; msgid
<d3fbb76dabed4e1987c512c328c82810@intel.com>]
Laszlo Ersek [Tue, 8 Oct 2019 07:15:38 +0000 (09:15 +0200)]
OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug
MaxCpuCountInitialization() currently handles the following options:
(1) QEMU does not report the boot CPU count (FW_CFG_NB_CPUS is 0)
In this case, PlatformPei makes MpInitLib enumerate APs up to the
default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until
the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses.
(Whichever is reached first.)
Time-limited AP enumeration had never been reliable on QEMU/KVM, which
is why commit 45a70db3c3a5 strated handling case (2) below, in OVMF.
(2) QEMU reports the boot CPU count (FW_CFG_NB_CPUS is nonzero)
In this case, PlatformPei sets
- PcdCpuMaxLogicalProcessorNumber to the reported boot CPU count
(FW_CFG_NB_CPUS, which exports "PCMachineState.boot_cpus"),
- and PcdCpuApInitTimeOutInMicroSeconds to practically "infinity"
(MAX_UINT32, ~71 minutes).
That causes MpInitLib to enumerate exactly the present (boot) APs.
With CPU hotplug in mind, this method is not good enough. Because,
using QEMU terminology, UefiCpuPkg expects
PcdCpuMaxLogicalProcessorNumber to provide the "possible CPUs" count
("MachineState.smp.max_cpus"), which includes present and not present
CPUs both (with not present CPUs being subject for hot-plugging).
FW_CFG_NB_CPUS does not include not present CPUs.
Rewrite MaxCpuCountInitialization() for handling the following cases:
(1) The behavior of case (1) does not change. (No UefiCpuPkg PCDs are set
to values different from the defaults.)
(2) QEMU reports the boot CPU count ("PCMachineState.boot_cpus", via
FW_CFG_NB_CPUS), but not the possible CPUs count
("MachineState.smp.max_cpus").
In this case, the behavior remains unchanged.
The way MpInitLib is instructed to do the same differs however: we now
set the new PcdCpuBootLogicalProcessorNumber to the boot CPU count
(while continuing to set PcdCpuMaxLogicalProcessorNumber identically).
PcdCpuApInitTimeOutInMicroSeconds becomes irrelevant.
(3) QEMU reports both the boot CPU count ("PCMachineState.boot_cpus", via
FW_CFG_NB_CPUS), and the possible CPUs count
("MachineState.smp.max_cpus").
We tell UefiCpuPkg about the possible CPUs count through
PcdCpuMaxLogicalProcessorNumber. We also tell MpInitLib the boot CPU
count for precise and quick AP enumeration, via
PcdCpuBootLogicalProcessorNumber. PcdCpuApInitTimeOutInMicroSeconds is
irrelevant again.
This patch is a pre-requisite for enabling CPU hotplug with SMM_REQUIRE.
As a side effect, the patch also enables S3 to work with CPU hotplug at
once, *without* SMM_REQUIRE.
(Without the patch, S3 resume fails, if a CPU is hot-plugged at OS
runtime, prior to suspend: the FW_CFG_NB_CPUS increase seen during resume
causes PcdCpuMaxLogicalProcessorNumber to increase as well, which is not
permitted.
With the patch, PcdCpuMaxLogicalProcessorNumber stays the same, namely
"MachineState.smp.max_cpus". Therefore, the CPU structures allocated
during normal boot can accommodate the CPUs at S3 resume that have been
hotplugged prior to S3 suspend.)
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20191022221554.14963-4-lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Laszlo Ersek [Tue, 22 Oct 2019 10:12:41 +0000 (12:12 +0200)]
OvmfPkg/IndustryStandard: define macros for QEMU's CPU hotplug registers
In v1.5.0, QEMU's "pc" (i440fx) board gained a "CPU present bitmap"
register block. In v2.0.0, this was extended to the "q35" board.
In v2.7.0, a new (read/write) register interface was laid over the "CPU
present bitmap", with an option for the guest to switch the register block
to the new (a.k.a. modern) interface.
Both interfaces are documented in "docs/specs/acpi_cpu_hotplug.txt" in the
QEMU tree.
Add macros for a minimal subset of the modern interface, just so we can
count the possible CPUs (as opposed to boot CPUs) in a later patch in this
series.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20191022221554.14963-3-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
PcdCpuMaxLogicalProcessorNumber and PcdCpuApInitTimeOutInMicroSeconds are
only referenced in "OvmfPkg/PlatformPei/PlatformPei.inf", and OvmfXen does
not include that module. Remove the unnecessary dynamic PCD defaults from
"OvmfXen.dsc".
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <20191022221554.14963-2-lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Update PatchCheck to not enforce no tabs and not enforce CR/LF
line endings for .gitmodules files. These files are updated by
git when a git submodule command is used and the updates by git
use tab characters and LF line endings.
Also update patch check to not enforce CR/LF line endings for
patch lines that create a submodule directory. These patch
lines use LF line endings. The git submodule directory is
added as a new file with attributes 160000 that can be detected
by looking for the pattern "new file mode 160000".
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Hmac(Md5|Sha1|Sha256)GetContextSize() use a deprecated macro
HMAC_MAX_MD_CBLOCK defined in openssl. They should be dropped to
avoid misuses in the future. For context allocation and release,
use HmacXxxNew() and HmacXxxFree() instead.
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Xiaoyu Lu <xiaoyux.lu@intel.com>
HmacXxxInit() is supposed to be initialize user supplied buffer as HMAC
context, as well as user supplied key. Currently it has no real use cases.
Due to BZ1792, the user has no way to get correct size of context buffer
after it's fixed, and then cannot make use of HmacXxxInit to initialize
it.
So it's decided to replace it with HmacXxxSetKey to keep the functionality
of supplying a key to HMAC, but drop all other initialization works. The
user can still get HMAC context via HmacXxxNew interface, which hides the
details about the context.
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Xiaoyu Lu <xiaoyux.lu@intel.com>
Previous commit d786a17232:
UefiCpuPkg/MpInitLib: Reduce the size when loading microcode patches
Removed the below assignments for the 'InitFlag' field of CPU_MP_DATA
structure in function MpInitLibInitialize() when APs are waken up to do
some initialize sync:
The above commit mistakenly assumed the 'InitFlag' field will have a value
of 'ApInitDone' when the APs have been successfully waken up before. And
since there is no explicit comparision for the 'InitFlag' field with the
'ApInitReconfig' value. The commit removed those assignments.
However, under some cases (e.g. when variable OldCpuMpData is not NULL,
which means function CollectProcessorCount() will not be called), removing
the above assignments will left the 'InitFlag' field being uninitialized
with a value of 0, which is a invalid value for the type of 'InitFlag'
(AP_INIT_STATE).
It may potentially cause the WakeUpAP() function to run some unnecessary
codes when the APs have been successfully waken up before:
This commit will address the above-mentioned issue.
Test done:
* OS boot on a real platform with multi processors
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
Capsule Dependency is an incremental change of Fmp Capsule Update. The
capsule format is extended to include a set of binary encoded dependency
expression. The dependency expression is signed together with the Fmp
payload and evaluated before update is applied.
This feature is defined in UEFI Spec 2.8.
The dependency evaluation has two steps:
1. Validate platform existing Fmp images' version satisfy the dependency
expression in capsule image.
2. Validate the capsule image version satisfy all the platform existing
Fmp image's dependency expression.
If the dependency expression evaluates to FALSE, then the capsule update
fails and last attempt status is set to
LAST_ATTEMPT_STATUS_ERROR_UNSATISFIED_DEPENDENCIES.
The dependency saving and getting is FmpDeviceLib implementation scope.
The parameter "Image" of FmpDeviceSetImage and FmpDeviceGetImage function
is extended to contain the dependency. The layout:
+--------------------------+
| Dependency Op-codes |
+--------------------------+
| Fmp Payload Image |
+--------------------------+
1. FmpDeviceSetImage is responsible for retrieving the dependency from the
parameter "Image" and saving it to a protected storage.
2. FmpDeviceGetImage is responsible for retrieving the dependency from the
storage where FmpDeviceSetImage saves dependency and combining it with the
Fmp Payload Image into one buffer which is returned to the caller. This
dependency will be populated into EFI_FIRMWARE_IMAGE_DESCRIPTOR and used
for dependency evaluation.
3. FmpDeviceGetAttributes must set the bit IMAGE_ATTRIBUTE_DEPENDENCY to
indicate the Fmp device supports Fmp Capsule Dependency feature.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
1. Enhance "CapsuleApp -P" to output the depex expression op-codes in
the EFI_FIRMWARE_IMAGE_DESCRIPTOR.
2. Enhance Last Attempt Status String with a new string to describe the
error LAST_ATTEMPT_STATUS_ERROR_UNSATISFIED_DEPENDENCIES.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Add new definitions for Fmp Capsule dependency in UEFI Spec 2.8.
1. Extend the Last Attempt Status with a value to indicate the firmware
update fails with unsatisfied dependencies.
2. Add the definition of dependency expression op-codes.
3. Add the definition of EFI_FIRMWARE_IMAGE_DEP which is an array of FMP
dependency expression op-codes.
4. Extend the EFI_FIRMWARE_IMAGE_DESCRIPTOR with a pointer to the array of
FMP dependency expression op-codes.
5. Extend the Image Attribute Definitions with IMAGE_ATTRIBUTE_DEPENDENCY
to indicate that there is and EFI_FIRMWARE_IMAGE_DEP section associated
with the image.
6. Update EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION to 4.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
To increase the resiliency driver will now attempt to
retry the commands that failed due to the CRC error up
to 5 times. This should address the problems with the commands
that fail due to random condition on links. This should also
help the boards on which CMD13 is particularly unstable after
switching the link frequency.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Error detection function will now check if the command
failure has been caused by one of the errors that can
appear randomly on link(CRC error + end bit error). If
such an error has been a cause of failure, function will
return EFI_CRC_ERROR instead of EFI_DEVICE_ERROR to indicate
to the higher level that command has a chance of succeeding if
resent.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Albecki, Mateusz [Tue, 14 Jan 2020 12:05:27 +0000 (20:05 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Fix DAT lane SW reset
Driver used to reset the DAT lane on a current error which
is not required according to SD specification(it's not going
to help). This patch will reset the DAT lane only on DAT
lane specific errors.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Laszlo Ersek [Thu, 9 Jan 2020 21:00:39 +0000 (22:00 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: fix 2M->4K page splitting regression for PDEs
In commit 4eee0cc7cc0d ("UefiCpuPkg/PiSmmCpu: Enable 5 level paging when
CPU supports", 2019-07-12), the Page Directory Entry setting was regressed
(corrupted) when splitting a 2MB page to 512 4KB pages, in the
InitPaging() function.
Consider the following hunk, displayed with
$ git show --function-context --ignore-space-change 4eee0cc7cc0db
> //
> // If it is 2M page, check IsAddressSplit()
> //
> if (((*Pd & IA32_PG_PS) != 0) && IsAddressSplit (Address)) {
> //
> // Based on current page table, create 4KB page table for split area.
> //
> ASSERT (Address == (*Pd & PHYSICAL_ADDRESS_MASK));
>
> Pt = AllocatePageTableMemory (1);
> ASSERT (Pt != NULL);
>
> + *Pd = (UINTN) Pt | IA32_PG_RW | IA32_PG_P;
> +
> // Split it
> - for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++) {
> - Pt[PtIndex] = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
> + for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++, Pt++) {
> + *Pt = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
> } // end for PT
> *Pd = (UINT64)(UINTN)Pt | mAddressEncMask | PAGE_ATTRIBUTE_BITS;
> } // end if IsAddressSplit
> } // end for PD
First, the new assignment to the Page Directory Entry (*Pd) is
superfluous. That's because (a) we set (*Pd) after the Page Table Entry
loop anyway, and (b) here we do not attempt to access the memory starting
at "Address" (which is mapped by the original value of the Page Directory
Entry).
Second, appending "Pt++" to the incrementing expression of the PTE loop is
a bug. It causes "Pt" to point *right past* the just-allocated Page Table,
once we finish the loop. But the PDE assignment that immediately follows
the loop assumes that "Pt" still points to the *start* of the new Page
Table.
The result is that the originally mapped 2MB page disappears from the
processor's view. The PDE now points to a "Page Table" that is filled with
garbage. The random entries in that "Page Table" will cause some virtual
addresses in the original 2MB area to fault. Other virtual addresses in
the same range will no longer have a 1:1 physical mapping, but be
scattered over random physical page frames.
The second phase of the InitPaging() function ("Go through page table and
set several page table entries to absent or execute-disable") already
manipulates entries in wrong Page Tables, for such PDEs that got split in
the first phase.
This issue has been caught as follows:
- OVMF is started with 2001 MB of guest RAM.
- This places the main SMRAM window at 0x7C10_1000.
- The SMRAM management in the SMM Core links this SMRAM window into
"mSmmMemoryMap", with a FREE_PAGE_LIST record placed at the start of the
area.
- At "SMM Ready To Lock" time, PiSmmCpuDxeSmm calls InitPaging(). The
first phase (quoted above) decides to split the 2MB page at 0x7C00_0000
into 512 4KB pages, and corrupts the PDE. The new Page Table is
allocated at 0x7CE0_D000, but the PDE is set to 0x7CE0_E000 (plus
attributes 0x67).
- Due to the corrupted PDE, the second phase of InitPaging() already looks
up the PTE for Address=0x7C10_1000 in the wrong place. The second phase
goes on to mark bogus PTEs as "NX".
- PiSmmCpuDxeSmm calls SetMemMapAttributes(). Address 0x7C10_1000 is at
the base of the SMRAM window, therefore it happens to be listed in the
SMRAM map as an EfiConventionalMemory region. SetMemMapAttributes()
calls SmmSetMemoryAttributes() to mark the region as XP. However,
GetPageTableEntry() in ConvertMemoryPageAttributes() fails -- address
0x7C10_1000 is no longer mapped by anything! -- and so the attribute
setting fails with RETURN_UNSUPPORTED. This error goes unnoticed, as
SetMemMapAttributes() ignores the return value of
SmmSetMemoryAttributes().
- When SetMemMapAttributes() reaches another entry in the SMRAM map,
ConvertMemoryPageAttributes() decides it needs to split a 2MB page, and
calls SplitPage().
- SplitPage() calls AllocatePageTableMemory() for the new Page Table,
which takes us to InternalAllocMaxAddress() in the SMM Core.
- The SMM core attempts to read the FREE_PAGE_LIST record at 0x7C10_1000.
Because this virtual address is no longer mapped, the firmware crashes
in InternalAllocMaxAddress(), when accessing (Pages->NumberOfPages).
Remove the useless assignment to (*Pd) from before the loop. Revert the
loop incrementing and the PTE assignment to the known good version.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1789335 Fixes: 4eee0cc7cc0db74489b99c19eba056b53eda6358 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
This commit fixes an offset calculation that is used to write the
VarErrorFlag UEFI variable to the UEFI variable runtime cache.
Currently a physical address is used instead of an offset. This
commit changes the offset to zero with a length of the entire
non-volatile variable store so the entire non-volatile variable
store buffer in SMRAM (with the variable update modification) is
copied to the runtime variable cache. This follows the same pattern
used in other SynchronizeRuntimeVariableCache () calls for
consistency.
* Observable symptom: An exception in SMM will most likely occur
due to the invalid memory reference when the VarErrorFlag variable
is written. The variable is most commonly written when the UEFI
variable store is full.
* The issue only occurs when the variable runtime cache is enabled
by the following PCD being set to TRUE:
gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache
Fixes: aab3b9b9a1e5e1f3fa966fb1667fc3e6c47e7706 Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Michael Turner <michael.turner@microsoft.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Capsule generate tool support encode capsule dependencies through '-j'
command with a JSON file. To enable dependency feature, "Dependencies"
field for each payload in JSON file is required.
The value of "Dependencies" field is C style infix notation expression.
For example:
"Dependencies":"72E2945A-00DA-448E-9AA7-075AD840F9D4 > 0x00000001"
Ard Biesheuvel [Mon, 6 Jan 2020 11:38:29 +0000 (12:38 +0100)]
ArmPlatformPkg/PrePeiCore: enable VFP at startup
While the alternative PEI-less SEC implementation in PrePi already
takes the EnableVFP PCD into account, the PrePeiCore code does not,
and so we may end up triggering synchronous exception when code
attempts to use FP or SIMD registers, which is permitted on AARCH64
by the spec.
So enable the VFP as early as feasible if the associated PCD is set.
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib. Note that this means the hack to support warm
reboot by jumping to the SEC entry point with the MMU and caches off
is also no longer used, and can be removed as well, along with the PCD
PcdArmReenterPeiForCapsuleWarmReboot that was introduced for this
purpose.
Laszlo Ersek [Wed, 8 Jan 2020 22:24:02 +0000 (23:24 +0100)]
NetworkPkg/HttpDxe: fix 32-bit truncation in HTTPS download
When downloading over TLS, each TLS message ("APP packet") is returned as
a (decrypted) fragment table by EFI_TLS_PROTOCOL.ProcessPacket().
The TlsProcessMessage() function in "NetworkPkg/HttpDxe/HttpsSupport.c"
linearizes the fragment table into a single contiguous data block. The
resultant flat data block contains both TLS headers and data.
The HttpsReceive() function parses the actual application data -- in this
case: decrypted HTTP data -- out of the flattened TLS data block, peeling
off the TLS headers.
The HttpResponseWorker() function in "NetworkPkg/HttpDxe/HttpImpl.c"
propagates this HTTP data outwards, implementing the
EFI_HTTP_PROTOCOL.Response() function.
Now consider the following documentation for EFI_HTTP_PROTOCOL.Response(),
quoted from "MdePkg/Include/Protocol/Http.h":
> It is the responsibility of the caller to allocate a buffer for Body and
> specify the size in BodyLength. If the remote host provides a response
> that contains a content body, up to BodyLength bytes will be copied from
> the receive buffer into Body and BodyLength will be updated with the
> amount of bytes received and copied to Body. This allows the client to
> download a large file in chunks instead of into one contiguous block of
> memory.
Note that, if the caller-allocated buffer is larger than the
server-provided chunk, then the transfer length is limited by the latter.
This is in fact the dominant case when downloading a huge file (for which
UefiBootManagerLib allocated a huge contiguous RAM Disk buffer) in small
TLS messages.
For adjusting BodyLength as described above -- i.e., to the application
data chunk that has been extracted from the TLS message --, the
HttpResponseWorker() function employs the following assignment:
HttpMsg->BodyLength = MIN (Fragment.Len, (UINT32) HttpMsg->BodyLength);
The (UINT32) cast is motivated by the MIN() requirement -- in
"MdePkg/Include/Base.h" -- that both arguments be of the same type.
"Fragment.Len" (NET_FRAGMENT.Len) has type UINT32, and
"HttpMsg->BodyLength" (EFI_HTTP_MESSAGE.BodyLength) has type UINTN.
Therefore a cast is indeed necessary.
Unfortunately, the cast is done in the wrong direction. Consider the
following circumstances:
- "Fragment.Len" happens to be consistently 16KiB, dictated by the HTTPS
Server's TLS stack,
- the size of the file to download is 4GiB + N*16KiB, where N is a
positive integer.
As the download progresses, each received 16KiB application data chunk
brings the *next* input value of BodyLength closer down to 4GiB. The cast
in MIN() always masks off the high-order bits from the input value of
BodyLength, but this is no problem because the low-order bits are nonzero,
therefore the MIN() always permits progress.
However, once BodyLength reaches 4GiB exactly on input, the MIN()
invocation produces a zero value. HttpResponseWorker() adjusts the output
value of BodyLength to zero, and then passes it to HttpParseMessageBody().
HttpParseMessageBody() (in "NetworkPkg/Library/DxeHttpLib/DxeHttpLib.c")
rejects the zero BodyLength with EFI_INVALID_PARAMETER, which is fully
propagated outwards, and aborts the HTTPS download. HttpBootDxe writes the
message "Error: Unexpected network error" to the UEFI console.
For example, a file with size (4GiB + 197MiB) terminates after downloading
just 197MiB.
Invert the direction of the cast: widen "Fragment.Len" to UINTN.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Laszlo Ersek [Wed, 8 Jan 2020 20:19:35 +0000 (21:19 +0100)]
MdeModulePkg/UefiBootManagerLib: log reserved mem allocation failure
The LoadFile protocol can report such a large buffer size that we cannot
allocate enough reserved pages for. This particularly affects HTTP(S)
Boot, if the remote file is very large (for example, an ISO image).
While the TianoCore wiki mentions this at
<https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-image-size>:
> The maximum RAM disk image size depends on how much continuous reserved
> memory block the platform could provide.
it's hard to remember; so log a DEBUG_ERROR message when the allocation
fails.
(Manually rewrapped here for keeping PatchCheck.py happy.)
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com>
* Always print subject line after the git commit id to make
it easier to know the context of warnings or errors.
* Allow UTF-8 characters in subject line
* Error if subject line length > 75 without CVE-xxx-xxxxx present
* Error if subject line length > 92 with CVE-xxxx-xxxxx present
* If body line length is > 75, then print warning instead of error.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
BuildOption is used by TargetTxtClassObj.py
GenFdsOption is used by GenFds.py
When the GenFds tool is used alone (e.g. python3 -m GenFds.GenFds -h)
With the OptionParser function, the first detected function
prints the help message
import TargetTxtClassObj to GenFds,
The BuildOption will be executed and replace GenFdsOption
We removed all objects associated with this problem that
were created directly during the import process
(e.g. BuildOption, BuildTarget = MyOptionParser(),
TargetTxt = TargetTxtDict())
The Patch is going to fix this issue
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Siyuan Fu [Wed, 8 Jan 2020 03:22:30 +0000 (11:22 +0800)]
UefiCpuPkg: Shadow microcode patch according to FIT microcode entry.
The existing MpInitLib will shadow the microcode update patches from
flash to memory and this is done by searching microcode region specified
by PCD PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize.
This brings a limition to platform FW that all the microcode patches must
be placed in one continuous flash space.
This patch shadows microcode update according to FIT microcode entries if
it's present, otherwise it will fallback to original logic (by PCD).
A new featured PCD gUefiCpuPkgTokenSpaceGuid.PcdCpuShadowMicrocodeByFit
is added for enabling/disabling this support.
TEST: Tested on FIT enabled platform.
BZ: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Siyuan Fu [Wed, 8 Jan 2020 03:14:38 +0000 (11:14 +0800)]
MdePkg: Add header file for Firmware Interface Table specification.
This patch add FirmwareInterfaceTable.h for the Firmware Interface Table
BIOS specification.
This is to remove future edk2 dependency on edk2-platforms repo. The file
content comes from
edk2-platforms\Silicon\Intel\IntelSiliconPkg\Include\IndustryStandard
link: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449 Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
BaseTools/PatchCheck.py: Let EmailAddressCheck describe email checked
We are checking different emails from the signature list. We are
going to check more. To be able to differency, add a description
field, so the error reported is clearer.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Jason Voelz [Mon, 23 Dec 2019 06:55:36 +0000 (14:55 +0800)]
MdePkg BaseLib.h: Update IA32_CR4 strut to include all public fields
Based on Intel Software Develeper's Manual, add all fields in IA32_CR4.
Signed-off-by: Jason Voelz <jason.voelz@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Currently, the TPM2 ACPI table is not produced, since we do not
incorporate the Tcg2Smm module, which implements the SMI based
physical presence interface exposed to the OS.
Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Siyuan, Fu [Fri, 3 Jan 2020 06:59:27 +0000 (14:59 +0800)]
UefiCpuPkg: Always load microcode patch on AP processor.
This patch updates the microcode loader to always perform a microcode
detect and load on both BSP and AP processor. This is to fix a potential
microcode revision mismatch issue in below situation:
1. Assume there are two microcode co-exists in flash: one production
version and one debug version microcode.
2. FIT loads production microcode to BSP and all AP.
3. UefiCpuPkg loader loads debug microcode to BSP, and skip the loading
on AP.
As a result, different microcode patches are loaded to BSP and AP, and
trigger microcode mismatch error during OS boot.
link: https://bugzilla.tianocore.org/show_bug.cgi?id=2431 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Siyuan Fu [Fri, 3 Jan 2020 07:11:51 +0000 (15:11 +0800)]
UefiCpuPkg: Remove alignment check when calculate microcode size.
This patch removes the unnecessary alignment check on microcode patch
TotalSize introduced by commit d786a172. The TotalSize has already been
checked with 1K alignment and MAX_ADDRESS in previous code as below:
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Current code use below loops to enumerate the CPUs:
for (Index = mMaxNumberOfCpus; Index-- > 0;) {
it has no issue but not easy for the developers to read the code.
Update above code to below style,
for (Index = 0; Index < mMaxNumberOfCpus; Index++) {
It make the developers easy to read and consistent with other
similar cases in this driver.
Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
Set the below two environment variables in edksetup.bat:
set CLANG_HOST_BIN=n
set CLANG_BIN=C:\Program Files\LLVM\bin\
In Windows, set CLANG_HOST_BIN=n to use nmake command
The CLANG_BIN is only be set if it is not defined.
Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Yu-Chen Lin to have his/her name and email
address displayed properly in the git history.
Cc: Yu-Chen Lin <yuchenlin@synology.com> Reviewed-by: Yu-Chen Lin <yuchenlin@synology.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-33-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Vladimir Olovyannikov to have his/her name and
email address displayed properly in the git history.
Cc: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-31-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Star Zeng to have his/her name and email address
displayed properly in the git history.
Cc: Star Zeng <star.zeng@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-29-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Ray Ni to have his/her name and email address
displayed properly in the git history.
Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-26-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Nikolai Saoukh to have his/her name and email
address displayed properly in the git history.
Cc: Nikolai Saoukh <nms@otdel-1.org> Reviewed-by: Nikolai Saoukh <nms@otdel-1.org> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-24-philmd@redhat.com>
We use .mailmap to display contributors email addresses in an
uniform format.
Add an entry for Ming Tan to have his/her name and email address
displayed properly in the git history.
Cc: Ming Tan <ming.tan@intel.com> Reviewed-by: Ming Tan <ming.tan@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200106115415.11624-23-philmd@redhat.com>
projects / mirror_edk2.git / log