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>
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>
"#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.
Cc: Liming Gao <liming.gao@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>
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>
this same function in 2 classes is never called.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
same pattern was compiled 3 places in the file. just compile once and share.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
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>
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 0fd13678a6.
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>
In commit 62f43f7c19, 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>
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>
instead if 3 Startswith for single chars, just use in with a list of chars
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
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>
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.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bin Wang <binx.a.wang@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
Since we only use the item from the list and not the numeric value,
dont bother with enumerate()
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
avoid recompiling the regular expression for each use in a while loop
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
Add the partition type GUID for every partition to the installed handle,
this is required per the UEFI specification.
"The firmware must add the PartitionTypeGuid to the handle of every
active GPT partition using EFI_BOOT_SERVICES.InstallProtocolInterface()."
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jeff Brasen <jbrasen.qdt@qualcommdatacenter.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
move hex character info from GUID expressions into seperate variable to
facilitate reuse.
I had a type with insufficient {} in the first version.
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=911
Update Minnow Max FLASH libraries to match libraries in
the UDK2017 development branch in edk2-platforms.
https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoardMax-UDK2017
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>
Reviewed-by: Guo Mang <mang.guo@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=911
Update PlatformBdsLib to show boot logo when the boot
mode is BOOT_ON_FLASH_UPDATE.
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>
https://bugzilla.tianocore.org/show_bug.cgi?id=911
Fix a the following issues in DSC/FDF files
* 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>
https://bugzilla.tianocore.org/show_bug.cgi?id=911
Fix minor code issues that break VS2015 builds.
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>
https://bugzilla.tianocore.org/show_bug.cgi?id=911
Update build scripts to work with edk2 and Vlv2Binaries
in PACKAGES_PATH.
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>
Reviewed-by: Guo Mang <mang.guo@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=890
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).
https://tools.ietf.org/html/rfc4506https://tools.ietf.org/html/rfc4506#section-4.10
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>
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.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
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.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=909
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
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().
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>