where the first instruction is patched with the contents of
"mRebasedFlag" (so that (*mRebasedFlag) is set to 1), and the second
instruction is patched with the address of
"mSmmRelocationOriginalAddress" (so that we jump to
"mSmmRelocationOriginalAddress").
In its current form the first instruction could not be patched with
PatchInstructionX86(), given that the operand to patch is not encoded
in the trailing bytes of the instruction. Therefore, adopt an
EAX-based version, inspired by both the IA32 and X64 variants of
SmmRelocationSemaphoreComplete():
Laszlo Ersek [Fri, 2 Feb 2018 03:46:26 +0000 (04:46 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmmInitStack" with PatchInstructionX86()
Rename the variable to "gPatchSmmInitStack" so that its association with
PatchInstructionX86() is clear from the declaration, change its type to
X86_ASSEMBLY_PATCH_LABEL, and patch it with PatchInstructionX86(). This
lets us remove the binary (DB) encoding of some instructions in
"SmmInit.nasm".
The size of the patched source operand is (sizeof (UINTN)).
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Fri, 2 Feb 2018 03:12:51 +0000 (04:12 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: eliminate "gSmmJmpAddr" and related DBs
The IA32 version of "SmmInit.nasm" does not need "gSmmJmpAddr" at all (its
PiSmmCpuSmmInitFixupAddress() variant doesn't do anything either). We can
simply use the NASM syntax for the following Mixed-Size Jump:
> jmp PROTECT_MODE_CS : dword @32bit
The generated object code for the instruction is unchanged:
(The NASM manual explains that putting the DWORD prefix after the colon
":" reflects the intent better, since it is the offset that is a DWORD.
Thus, that's what I used. However, both syntaxes are interchangeable,
hence the ndisasm output.)
The X64 version of "SmmInit.nasm" appears to require "gSmmJmpAddr";
however that's accidental, not inherent:
- Bring LONG_MODE_CODE_SEGMENT from
"UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h" to "SmmInit.nasm" as
LONG_MODE_CS, same as PROTECT_MODE_CODE_SEGMENT was brought to the IA32
version as PROTECT_MODE_CS earlier.
- Apply the NASM-native Mixed-Size Jump syntax again, but jump to the
fixed zero offset in LONG_MODE_CS. This will produce no relocation
record at all. Add a label after the instruction.
- Modify PiSmmCpuSmmInitFixupAddress() to patch the jump target backwards
from the label. Because we modify the DWORD offset with a DWORD access,
the segment selector is unharmed in the instruction, and we need not set
it from PiCpuSmmEntry().
According to "objdump --reloc", the X64 version undergoes only the
following relocations, after this patch:
> RELOCATION RECORDS FOR [.text]:
> OFFSET TYPE VALUE
> 0000000000000095 R_X86_64_PC32 SmmInitHandler-0x0000000000000004
> 00000000000000e0 R_X86_64_PC32 mRebasedFlag-0x0000000000000004
> 00000000000000ea R_X86_64_PC32 mSmmRelocationOriginalAddress-0x0000000000000004
Therefore the patch does not regress
<https://bugzilla.tianocore.org/show_bug.cgi?id=849> ("Enable XCODE5 tool
chain for UefiCpuPkg with nasm source code").
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Fri, 2 Feb 2018 01:10:05 +0000 (02:10 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmmCr0" with PatchInstructionX86()
Like "gSmmCr4" in the previous patch, "gSmmCr0" is not only used for
machine code patching, but also as a means to communicate the initial CR0
value from SmmRelocateBases() to InitSmmS3ResumeState(). In other words,
the last four bytes of the "mov eax, Cr0Value" instruction's binary
representation are utilized as normal data too.
In order to get rid of the DB for "mov eax, Cr0Value", we have to split
both roles, patching and data flow. Introduce the "mSmmCr0" global (SMRAM)
variable for the data flow purpose. Rename the "gSmmCr0" variable to
"gPatchSmmCr0" so that its association with PatchInstructionX86() is clear
from the declaration, change its type to X86_ASSEMBLY_PATCH_LABEL, and
patch it with PatchInstructionX86(), to the value now contained in
"mSmmCr0".
This lets us remove the binary (DB) encoding of "mov eax, Cr0Value" in
"SmmInit.nasm".
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Fri, 2 Feb 2018 01:10:05 +0000 (02:10 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmmCr4" with PatchInstructionX86()
Unlike "gSmmCr3" in the previous patch, "gSmmCr4" is not only used for
machine code patching, but also as a means to communicate the initial CR4
value from SmmRelocateBases() to InitSmmS3ResumeState(). In other words,
the last four bytes of the "mov eax, Cr4Value" instruction's binary
representation are utilized as normal data too.
In order to get rid of the DB for "mov eax, Cr4Value", we have to split
both roles, patching and data flow. Introduce the "mSmmCr4" global (SMRAM)
variable for the data flow purpose. Rename the "gSmmCr4" variable to
"gPatchSmmCr4" so that its association with PatchInstructionX86() is clear
from the declaration, change its type to X86_ASSEMBLY_PATCH_LABEL, and
patch it with PatchInstructionX86(), to the value now contained in
"mSmmCr4".
This lets us remove the binary (DB) encoding of "mov eax, Cr4Value" in
"SmmInit.nasm".
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Fri, 2 Feb 2018 00:48:56 +0000 (01:48 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmmCr3" with PatchInstructionX86()
Rename the variable to "gPatchSmmCr3" so that its association with
PatchInstructionX86() is clear from the declaration, change its type to
X86_ASSEMBLY_PATCH_LABEL, and patch it with PatchInstructionX86(). This
lets us remove the binary (DB) encoding of some instructions in
"SmmInit.nasm".
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Fri, 2 Feb 2018 00:23:17 +0000 (01:23 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: remove unneeded DBs from X64 SmmStartup()
(This patch is the 64-bit variant of commit e75ee97224e5,
"UefiCpuPkg/PiSmmCpuDxeSmm: remove unneeded DBs from IA32 SmmStartup()",
2018-01-31.)
The SmmStartup() function executes in SMM, which is very similar to real
mode. Add "BITS 16" before it and "BITS 64" after it (just before the
@LongMode label).
Remove the manual 0x66 operand-size override prefixes, for selecting
32-bit operands -- the sizes of our operands trigger NASM to insert the
prefixes automatically in almost every spot. The one place where we have
to add it back manually is the LGDT instruction. In the LGDT instruction
we also replace the binary 0x2E prefix with the normal NASM syntax for CS
segment override.
The stores to the Control Registers were always 32-bit wide; the source
code only used RAX as source operand because it generated the expected
object code (with NASM compiling the source as if in BITS 64). With BITS
16 added, we can use the actual register width in the source operands
(EAX).
This patch causes NASM to generate byte-identical object code (determined
by disassembling both the pre-patch and post-patch versions, and comparing
the listings), except:
Laszlo Ersek [Thu, 1 Feb 2018 23:17:13 +0000 (00:17 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: patch "XdSupported" with PatchInstructionX86()
"mXdSupported" is a global BOOLEAN variable, initialized to TRUE. The
CheckFeatureSupported() function is executed on all processors (not
concurrently though), called from SmmInitHandler(). If XD support is found
to be missing on any CPU, then "mXdSupported" is set to FALSE, and further
processors omit the check. Afterwards, "mXdSupported" is read by several
assembly and C code locations.
The tricky part is *where* "mXdSupported" is allocated (defined):
- Before commit 717fb60443fb ("UefiCpuPkg/PiSmmCpuDxeSmm: Add paging
protection.", 2016-11-17), it used to be a normal global variable,
defined (allocated) in "SmmProfile.c".
- With said commit, we moved the definition (allocation) of "mXdSupported"
into "SmiEntry.nasm". The variable was defined over the last byte of a
"mov al, 1" instruction, so that setting it to FALSE in
CheckFeatureSupported() would patch the instruction to "mov al, 0". The
subsequent conditional jump would change behavior, plus all further read
references to "mXdSupported" (in C and assembly code) would read back
the source (imm8) operand of the patched MOV instruction as data.
This trick required that the MOV instruction be encoded with DB.
In order to get rid of the DB, we have to split both roles: we need a
label for the code patching, and "mXdSupported" has to be defined
(allocated) independently of the code patching. Of course, their values
must always remain in sync.
(1) Reinstate the "mXdSupported" definition and initialization in
"SmmProfile.c" from before commit 717fb60443fb. Change the assembly
language definition ("global") to a declaration ("extern").
(2) Define the "gPatchXdSupported" label (type X86_ASSEMBLY_PATCH_LABEL)
in "SmiEntry.nasm", and add the C-language declaration to
"SmmProfileInternal.h". Replace the DB with the MOV mnemonic (keeping
the imm8 source operand with value 1).
(3) In CheckFeatureSupported(), whenever "mXdSupported" is set to FALSE,
patch the assembly code in sync, with PatchInstructionX86().
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Thu, 1 Feb 2018 22:40:29 +0000 (23:40 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmiCr3" with PatchInstructionX86()
Rename the variable to "gPatchSmiCr3" so that its association with
PatchInstructionX86() is clear from the declaration, change its type to
X86_ASSEMBLY_PATCH_LABEL, and patch it with PatchInstructionX86(). This
lets us remove the binary (DB) encoding of some instructions in
"SmiEntry.nasm".
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Thu, 1 Feb 2018 22:23:59 +0000 (23:23 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmiStack" with PatchInstructionX86()
Rename the variable to "gPatchSmiStack" so that its association with
PatchInstructionX86() is clear from the declaration. Also change its type
to X86_ASSEMBLY_PATCH_LABEL.
Unlike "gSmbase" in the previous patch, "gSmiStack"'s patched value is
also de-referenced by C code (in other words, it is read back after
patching): the InstallSmiHandler() function stores "CpuIndex" to the given
CPU's SMI stack through "gSmiStack". Introduce the local variable
"CpuSmiStack" in InstallSmiHandler() for calculating the stack location
separately, then use this variable for both patching into the assembly
code, and for storing "CpuIndex" through it.
It's assumed that "volatile" stood in the declaration of "gSmiStack"
because we used to read "gSmiStack" back for de-referencing; with that use
gone, we can remove "volatile" too. (Note that the *target* of the pointer
was never volatile-qualified.)
Finally, replace the binary (DB) encoding of "mov esp, imm32" in
"SmiEntry.nasm".
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Thu, 1 Feb 2018 22:01:08 +0000 (23:01 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmbase" with PatchInstructionX86()
Rename the variable to "gPatchSmbase" so that its association with
PatchInstructionX86() is clear from the declaration, change its type to
X86_ASSEMBLY_PATCH_LABEL, and patch it with PatchInstructionX86(). This
lets us remove the binary (DB) encoding of some instructions in
"SmiEntry.nasm".
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Thu, 1 Feb 2018 21:35:18 +0000 (22:35 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: remove *.S and *.asm assembly files
All edk2 toolchains use NASM for compiling X86 assembly source code. We
plan to remove X86 *.S and *.asm files globally, in order to reduce
maintenance and confusion:
Let's start with UefiCpuPkg/PiSmmCpuDxeSmm: remove the *.S and *.asm
dialects (both Ia32 and X64) of the SmmInit, SmiEntry, SmiException and
MpFuncs sources.
Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=866
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Andrew Fish <afish@apple.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Thu, 1 Feb 2018 20:08:28 +0000 (21:08 +0100)]
MdePkg/BaseLib.h: state preprocessing conditions in comments after #endifs
"#endif" preprocessing directives near the top of "BaseLib.h" helpfully
repeat the preprocessing conditions from their matching "#if", "#ifdef",
and "#ifndef" directives. This practice has been less followed recently;
supplement the missing comments.
Star Zeng [Wed, 28 Feb 2018 05:21:59 +0000 (13:21 +0800)]
UefiCpuPkg PiSmmCpuDxeSmm: Refine some comments about SmmMemoryAttribute
1. Fix some "support" to "supported".
2. Fix some "set" to "clear" in ClearMemoryAttributes interface.
3. Remove redundant comments for GetMemoryAttributes interface.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@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: Star Zeng <star.zeng@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Star Zeng [Wed, 28 Feb 2018 05:20:34 +0000 (13:20 +0800)]
MdeModulePkg SmmMemoryAttribute.h: Refine some comments
1. Fix some "support" to "supported".
2. Fix some "set" to "clear" in ClearMemoryAttributes interface.
3. Remove redundant comments for GetMemoryAttributes interface.
Cc: Jian J Wang <jian.j.wang@intel.com> 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: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Heyi Guo [Thu, 29 Mar 2018 08:19:50 +0000 (16:19 +0800)]
MdeModulePkg/Gcd: Fix bug of attribute conversion
For gDS->SetMemorySpaceAttributes(), when user passes a combined
memory attribute including CPU arch attribute and other attributes,
like EFI_MEMORY_RUNTIME, ConverToCpuArchAttributes() will return
INVALID_CPU_ARCH_ATTRIBUTES and skip setting page/cache attribute for
the specified memory space.
We don't see any reason to forbid combining CPU arch attributes and
non-CPU-arch attributes when calling gDS->SetMemorySpaceAttributes(),
so we remove the check code in ConverToCpuArchAttributes(); the
remaining code is enough to grab the interested bits for
Cpu->SetMemoryAttributes().
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Signed-off-by: Yi Li <phoenix.liyi@huawei.com> Signed-off-by: Renhao Liang <liangrenhao@huawei.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Laszlo Ersek [Wed, 28 Mar 2018 01:04:06 +0000 (03:04 +0200)]
OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS boot
Introduce TlsAuthConfigLib to read the list of trusted CA certificates
from fw_cfg and to store it to EFI_TLS_CA_CERTIFICATE_VARIABLE.
The fw_cfg file is formatted by the "p11-kit" and "update-ca-trust"
utilities on the host side, so that the host settings take effect in guest
HTTPS boot as well. QEMU forwards the file intact to the firmware. The
contents are sanity-checked by NetworkPkg/HttpDxe code that was added in
commit 0fd13678a681.
Link TlsAuthConfigLib via NULL resolution into TlsAuthConfigDxe. This sets
EFI_TLS_CA_CERTIFICATE_VARIABLE in time for both
NetworkPkg/TlsAuthConfigDxe (for possible HII interaction with the user)
and for NetworkPkg/HttpDxe (for the effective TLS configuration).
The file formatted by "p11-kit" can be large. On a RHEL-7 host, the the
Mozilla CA root certificate bundle -- installed with the "ca-certificates"
package -- is processed into a 182KB file. Thus, create
EFI_TLS_CA_CERTIFICATE_VARIABLE as a volatile & boot-time only variable.
Also, in TLS_ENABLE builds, set the cumulative limit for volatile
variables (PcdVariableStoreSize) to 512KB, and the individual limit for
the same (PcdMaxVolatileVariableSize) to 256KB.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
As a continuation of the last patch, clarify in the DSC files that we set
PcdVariableStoreSize to the same value as PcdFlashNvStorageVariableSize
just for convenience; the equality is not a technical requirement.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Laszlo Ersek [Tue, 27 Mar 2018 22:45:23 +0000 (00:45 +0200)]
OvmfPkg/EmuVariableFvbRuntimeDxe: stop using PcdVariableStoreSize
In commit 62f43f7c1947c, we set PcdVariableStoreSize to the same value as
PcdFlashNvStorageVariableSize (which in turn comes from VARS_LIVE_SIZE in
"OvmfPkg.fdf.inc").
This equality between both PCDs is a false requirement from
EmuVariableFvbRuntimeDxe. FVB drivers should use
PcdFlashNvStorageVariableSize for supporting non-volatile variables (even
if they happen to be kept in RAM only), along the other PcdFlashNvStorage*
PCDs. Whereas PcdVariableStoreSize is for variables that are volatile at
the gRT->SetVariable() / gRT->GetVariable() API level.
(PlatformPei too bases the preallocation for EmuVariableFvbRuntimeDxe on
PcdFlashNvStorageFtwSpareSize.)
Replace PcdVariableStoreSize in EmuVariableFvbRuntimeDxe with the
same-value PcdFlashNvStorageVariableSize. This means no change in
behavior, and it allows us to increase PcdVariableStoreSize in a later
patch without disturbing EmuVariableFvbRuntimeDxe (or PlatformPei).
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The variable driver doesn't distinguish "non-volatile non-authenticated"
variables from "volatile non-authenticated" variables, when checking
individual variable sizes against the permitted maximum.
PcdMaxVariableSize covers both kinds.
This prevents volatile non-authenticated variables from carrying large
data between UEFI drivers, despite having no flash impact. One example is
EFI_TLS_CA_CERTIFICATE_VARIABLE, which platforms might want to create as
volatile on every boot: the certificate list can be several hundred KB in
size.
Introduce PcdMaxVolatileVariableSize to represent the limit on individual
volatile non-authenticated variables. The default value is zero, which
makes Variable/RuntimeDxe fall back to PcdMaxVariableSize (i.e. the
current behavior). This is similar to the PcdMaxAuthVariableSize fallback.
Whenever the size limit is enforced, consult MaxVolatileVariableSize as
the last option, after checking
- MaxAuthVariableSize for VARIABLE_ATTRIBUTE_AT_AW,
- and MaxVariableSize for EFI_VARIABLE_NON_VOLATILE.
EFI_VARIABLE_HARDWARE_ERROR_RECORD is always handled separately; it always
takes priority over the three cases listed above.
Introduce the GetMaxVariableSize() helper to consider
PcdMaxVolatileVariableSize, in addition to
GetNonVolatileMaxVariableSize(). GetNonVolatileMaxVariableSize() is
currently called at three sites, and two of those need to start using
GetMaxVariableSize() instead:
- VariableServiceInitialize() [VariableSmm.c]: the SMM comms buffer must
accommodate all kinds of variables,
- VariableCommonInitialize() [Variable.c]: the preallocated scratch space
must also accommodate all kinds of variables,
- InitNonVolatileVariableStore() [Variable.c] can continue using
GetNonVolatileMaxVariableSize().
Don't modify the ReclaimForOS() function as it is specific to non-volatile
variables and should ignore PcdMaxVolatileVariableSize.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com>
[lersek@redhat.com: set MaxVolatileVariableSize where Star suggested] Reviewed-by: Star Zeng <star.zeng@intel.com>
Star Zeng [Wed, 28 Mar 2018 09:27:50 +0000 (17:27 +0800)]
MdeModulePkg Variable: Align TPL level for (Smm)EndOfDxe callback
VariableRuntimeDxe will have OnEndOfDxe() callback function at
TPL_NOTIFY level on EndOfDxe event when DXE variable solution is
used.
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
TPL_NOTIFY,
OnEndOfDxe,
NULL,
&gEfiEndOfDxeEventGroupGuid,
&EndOfDxeEvent
);
VariableSmm will have SmmEndOfDxeCallback() callback function at
TPL_CALLBACK level on SmmEndOfDxe event when SMM variable solution
is used.
SmmIplGuidedEventNotify() - PiSmmIpl.c TPL_CALLBACK on EndOfDxe
->
SmmEndOfDxeHandler() - PiSmmCore.c install SmmEndOfDxe protocol
->
SmmEndOfDxeCallback() - VariableSmm.c
The TPL level for (Smm)EndOfDxe callback between VariableRuntimeDxe
and VariableSmm is inconsistent, it will make the unified platform
code could not make sure its TPL_NOTIFY EndOfDxe callback function
(to use variable lock/check) executed before (Smm)EndOfDxe callback
function in variable driver. The variable lock/check will start to
protect after (Smm)EndOfDxe callback function in variable driver is
executed.
This patch is to algin the TPL level to TPL_CALLBACK for (Smm)EndOfDxe
callback between VariableRuntimeDxe and VariableSmm.
Cc: Chasel Chiu <chasel.chiu@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Liming Gao <liming.gao@intel.com> 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: Chasel Chiu <chasel.chiu@intel.com>
Alex James [Mon, 26 Mar 2018 16:15:10 +0000 (00:15 +0800)]
CorebootPayloadPkg: Conditionally add DebugAgentLib for DXE drivers
To fix building with SOURCE_DEBUG_ENABLE, add DebugAgentLib for
LibraryClasses.common.DXE_DRIVER, as is done with Vlv2TbltDevicePkg.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Prince Agyeman <prince.agyeman@intel.com> Cc: Benjamin You <benjamin.you@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Alex James <theracermaster@gmail.com> Reviewed-by: Benjamin You <benjamin.you@intel.com>
Bin Wang [Mon, 26 Feb 2018 08:19:30 +0000 (16:19 +0800)]
BaseTools: compare GUID value should not case-sensitive
build report error when the same Guid value in FDF file use lowercase,
in tools_def.txt file use uppercase.
The guid value's compare should not case-sensitive.
Carsey, Jaben [Wed, 28 Mar 2018 16:04:57 +0000 (00:04 +0800)]
BaseTools: FdfParser and FdfParserLite share reg exp
FdfParser can share regular expression from FdfParserLite.
reduce overlap and reduce recompile of the same expression.
v2: fix missed replacement of Pattern with shared variable
* Remove references to drivers that are not present
* Enable the Tianocore boot logo and BGRT table
* Enable full UEFI shell
* Enable more debug messages in DXE phase
Cc: David Wei <david.wei@intel.com> Cc: Mang Guo <mang.guo@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: David Wei <david.wei@intel.com>
There are use cases where a VOID * PCD needs to be generated from multiple
binary input files. This can be in the form of an array of fixed size
elements or a set of variable sized elements.
Update BinToPcd to support multiple one or more -i INPUTFILE arguments.
By default, the contents of each binary input file are concatenated in
the order provided. This supports generating a PCD that is an array of
fixed size elements
Add -x, --xdr flags to BinToPcd to encodes the PCD using the
Variable-Length Opaque Data of RFC 4506 External Data Representation
Standard (XDR).
The data format from RFC 4506 meets the requirements for a PCD that is a
set of variable sized elements in the Variable-Length Opaque Data format.
The overhead of this format is a 32-bit length and 0 to 3 bytes of padding
to align the next element at a 32-bit boundary.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
Laszlo Ersek [Wed, 28 Mar 2018 11:26:35 +0000 (13:26 +0200)]
OvmfPkg/PlatformPei: debug log "etc/reserved-memory-end" from fw_cfg
QEMU calculates the UINT64 value in "etc/reserved-memory-end" in a quite
complex way, in the pc_memory_init() function. Log the value as a
DEBUG_VERBOSE message to support debugging.
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1353591
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
If the platform creates the "TlsCaCertificate" variable as volatile, then
EnrollX509toVariable() shouldn't fail to extend it just because
TLS_AUTH_CONFIG_VAR_BASE_ATTR contains the EFI_VARIABLE_NON_VOLATILE
attribute.
Thus, if the variable exists, add the EFI_VARIABLE_APPEND_WRITE attribute
to the variable's current attributes. This is what DeleteCert() does
already.
Laszlo Ersek [Thu, 22 Mar 2018 11:00:55 +0000 (12:00 +0100)]
NetworkPkg/HttpDxe: sanity-check the TlsCaCertificate variable before use
In TlsConfigCertificate(), make sure that the set of EFI_SIGNATURE_LIST
objects that the platform stored to "TlsCaCertificate" is well-formed.
In addition, because HttpInstance->TlsConfiguration->SetData() expects
X509 certificates only, ensure that the EFI_SIGNATURE_LIST objects only
report X509 certificates, as described under EFI_CERT_X509_GUID in the
UEFI-2.7 spec.
Laszlo Ersek [Thu, 22 Mar 2018 09:59:59 +0000 (10:59 +0100)]
NetworkPkg/HttpDxe: drop misleading comment / status code in cert config
For TlsConfigureSession(), it makes sense to exempt EFI_NOT_FOUND from
TlsConfigCipherList() / gRT->GetVariable(), because there is a default
cipher list (SSL_DEFAULT_CIPHER_LIST) we can fall back to.
The same is not true of TlsConfigCertificate(), because there is no
default CA cert list. The platform (or the user of the Setup utility) is
required to configure a CA cert list first.
Remove the misleading comment and status code mapping in
TlsConfigCertificate().
Laszlo Ersek [Thu, 22 Mar 2018 13:22:40 +0000 (14:22 +0100)]
NetworkPkg/HttpBootDxe: fix typo in DHCPv4 packet parsing
The string "HTTPClient" has 10 non-NUL characters; the value 9 is a
copy-paste leftover from "PXEClient". Check for all 10 characters in the
vendor-class-identifier option when determining whether the DHCP offer is
an HTTP offer.
Dandan Bi [Fri, 23 Mar 2018 03:21:56 +0000 (11:21 +0800)]
OvmfPkg:Fix VS2012 build failure
Initialize local variable to suppress warning C4701/C4703:
potentially uninitialized local variable/pointer variable.
1.In VirtualMemory.c:
Read of "PageMapLevel4Entry" in SetMemoryEncDe() is only
reached when "PageMapLevel4Entry" is got correctly.
2.In VirtioBlk.c:
Reads (dereferences) of "BufferMapping" and "BufferDeviceAddress"
in SynchronousRequest() are only reached if "BufferSize > 0" *and*
we map the data buffer successfully.
3.In VirtioScsi.c:
Reads (dereferences) of "InDataMapping" and "InDataDeviceAddress",
in VirtioScsiPassThru() are only reached if
"Packet->InTransferLength > 0" on input, *and* we map the
input buffer successfully. The similar reason for "OutDataMapping"
and "OutDataDeviceAddress".
Liming Gao [Tue, 27 Mar 2018 02:29:48 +0000 (10:29 +0800)]
BaseTools: Update Rsa2048Sha256Sign to use openssl standard options
sha256 is not the standard option. It should be replaced by sha -sha256.
Otherwise, it doesn't work in MAC OS.
In V2, update the option to sha1 -sha256.
In late openssl version >= 1.1, there is no sha option, but has sha1,sha256.
In previous openssl version < 1.1, there is no sha256, but has sha,sha1.
To work with all openssl version, use sha1 -sha256 for it.
Booting from USB may fail while the macro USB_BOOT_IO_BLOCKS
set to 128 because the block size of some USB devices are exceeded
512, like some virtual CD-ROM from BMC, the block size is 2048.
So,the count blocks to transfer should be calculated by block
size of the USB devices.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang <ming.huang@linaro.org> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Commit 5563281fa2b31093a1cbd415553b9264c5136e89
* ShellPkg/[hex]edit: use SimpleTextInEx to read console
changes shell edit and hexedit to read input through SimpleTextInEx.
It exposes a issue in UsbKeyboard driver:
Per UEFI Spec,
When interpreting the data from this function (ReadKeyStrokeEx), it
should be noted that if a class of printable characters that are
normally adjusted by shift modifiers (e.g. Shift Key + "f" key) would
be presented solely as a KeyData.Key.UnicodeChar without the
associated shift state. So in the previous example of a Shift Key +
"f" key being pressed, the only pertinent data returned would be
KeyData.Key.UnicodeChar with the value of "F".
UsbKeyboard driver does convert Shift Key + "f" to "F" without the
shift state. But it doesn't do the conversion for all printable
characters, e.g.: Shift Key + "1" --> "!".
The root cause is today's logic to check whether a character is
printable or not is as below:
if ((KeyDescriptor->AffectedAttribute & EFI_AFFECTED_BY_CAPS_LOCK)
!= 0) {
So it only converts Shift + "a"-"z", but doesn't for Shift + "0"-"9",
and Shift + "["...
The patch updates the check logic as below to fix the issue:
if ((KeyDescriptor->Unicode != CHAR_NULL) &&
(KeyDescriptor->ShiftedUnicode != CHAR_NULL) &&
(KeyDescriptor->Unicode != KeyDescriptor->ShiftedUnicode)) {
The above check is TRUE when the character is printable and
it's *really* affected by Shift key.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
When -G option is used to convert a BMP file to a UX capsule,
the bitmap is centered horizontally and placed in the lower
half of the screen below the boot logo.
This matches examples shown in the following pages:
Checks are also made to make sure the bitmap provided
fits in the current GOP mode.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Fix pointer math when more than one capsule is passed
to the CapsuleApp. Use the ContinuationPointer from
the last array entry instead of the first array entry.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Jiaxin Wu [Tue, 13 Mar 2018 08:53:18 +0000 (16:53 +0800)]
NetworkPkg/UefiPxeBcDxe: Configure the ARP Instance/RouteTable with new address
After completed a DHCP D.O.R.A process and got the new address, the ARP Instance
and RouteTable should be configured so as to avoid the later Pxe.Arp failure.
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>
Laszlo Ersek [Wed, 14 Mar 2018 09:58:34 +0000 (10:58 +0100)]
BaseTools/PosixLike: honor pre-set PYTHONPATH
Utilities written in Python may depend on external (preinstalled) Python
packages; for example, Ecc depends on "antlr_python_runtime-3.0.1". Such
packages need not be installed system-wide, as long as they are reachable
through PYTHONPATH. Therefore we shouldn't overwrite the user's PYTHONPATH
with "BaseTools/Source/Python"; instead, we should prepend the latter to
the former.
TPM2.0 command lib always assumes TPM device and transmission channel can
respond correctly. But it is not true when communication channel is exploited
and wrong data is spoofed. Add more logic to prohibit memory overflow attack.
Cc: Long Qin <qin.long@intel.com> Cc: Yao Jiewen <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chao Zhang <chao.b.zhang@intel.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
Yonghong Zhu [Wed, 21 Mar 2018 02:36:59 +0000 (10:36 +0800)]
BaseTools: Override Max size by build Option Pcd for HII type
Current code will generate maxsize for HII type PCD when parser DSC
file, while this HII type PCD value maybe override in build command
per --pcd option, so the max size need re-calculate.
Achin Gupta [Thu, 15 Feb 2018 13:31:50 +0000 (13:31 +0000)]
Maintainers.txt: Add StandaloneMmPkg and maintainers
This patch adds maintainers, reviewer and directory for the
StandaloneMmPkg. This package will host an implementation of Standalone
Management Mode as specified in the Platform Initialization (PI)
Specification, Volume 4: Management Mode Core Interface.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Achin Gupta <achin.gupta@arm.com> Reviewed-by: Jiewen.yao@intel.com Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Star Zeng [Mon, 19 Mar 2018 12:01:58 +0000 (20:01 +0800)]
SourceLevelDebugPkg DebugCommUsb3: Return error when debug cap is reset
When source level debug is enabled, but debug cable is not connected,
XhcResetHC() in XhciReg.c will reset the host controller, the debug
capability registers will be also reset. After the code in
InitializeUsbDebugHardware() sets DCE bit and LSE bit to "1" in DCCTRL,
there will be DMA on 0 (the value of some debug capability registers
for data transfer is 0) address buffer, fault info like below will
appear when IOMMU based on VTd is enabled.
Yonghong Zhu [Tue, 20 Mar 2018 05:16:12 +0000 (13:16 +0800)]
BaseTools: Fix bug for --pcd VOID* type when no max size is specified
when VOID* type non-structure pcd used in --pcd, and its max size is not
specified in DSC or its value is hex value, build break due to the code
int(Pcd.MaxDatumSize,10).
Now this patch remove this code, because tool will calculate the size
info in later phase.
Hao Wu [Mon, 19 Mar 2018 07:02:59 +0000 (15:02 +0800)]
MdeModulePkg/DxeMain: Fix BSP interrupts reenabled in ExitBootServices
Within function CoreExitBootServices(), this commit will move the call
of:
MemoryProtectionExitBootServicesCallback();
before:
SaveAndSetDebugTimerInterrupt (FALSE);
and
gCpu->DisableInterrupt (gCpu);
The reason is that, within MemoryProtectionExitBootServicesCallback(),
APIs like RaiseTpl and RestoreTpl maybe called. An example will be:
DebugLib (using PeiDxeDebugLibReportStatusCode instance)
|
v
ReportStatusCodeLib (using DxeReportStatusCodeLib instance)
|
v
Raise/RestoreTpl
The call of Raise/RestoreTpl APIs will re-enable BSP interrupts. Hence,
this commit refine the calling sequence to ensure BSP interrupts before
leaving CoreExitBootServices().
Cc: Jian J Wang <jian.j.wang@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: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Hao Wu [Mon, 19 Mar 2018 05:00:13 +0000 (13:00 +0800)]
UefiCpuPkg/MpInitLib: Disable interrupt at ExitBootServices AP Mwait
Within function ApWakeupFunction():
When source level debugger is enabled, AP interrupts will be enabled by
EnableDebugAgent(). Then the AP function will be executed by:
Procedure (Parameter);
After the AP function returns, AP interrupts will be disabled when the
APs are placed in loop mode (both HltLoop and MwaiLoop).
However, at ExitBootServices, ApWakeupFunction() is called with
'Procedure' equals to RelocateApLoop().
(ExitBootServices callback registered within InitMpGlobalData())
RelocateApLoop() never returns, so it has to disable the AP interrupts by
itself. However, we find that interrupts are only disabled for the
HltLoop case, but not for the MwaitLoop case (within file MpFuncs.nasm).
This commit adds the missing disabling of AP interrupts for MwaitLoop.
Also, for X64, this commit will disable the interrupts before switching to
32-bit mode.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jian J Wang <jian.j.wang@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: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Pete Batard [Fri, 23 Feb 2018 09:50:03 +0000 (17:50 +0800)]
BaseTools/Conf: Add VS2017/ARM64 support
Build options for ARM64 are the same as for ARM, except for /BASE:0
which is removed from DLINK flags to avoid LNK1355 error:
invalid base address 0x0; ARM64 image cannot have base address below 4GB
projects / mirror_edk2.git / log