Replace the dummy C implementation of SpeculationBarrier() with
implementations consisting of the recommended DSB SY + ISB sequence,
as recommended by ARM in the whitepaper "Cache Speculation Side-channels"
version 2.4, dated October 2018.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Introduce two public functions CharToUpper and AsciiCharToUpper.
They have the same functions as InternalCharToUpper and
InternalBaseLibAsciiToUpper.Considering the internal functions will
be removed,so directly I change their function names to the public ones'.
https://bugzilla.tianocore.org/show_bug.cgi?id=1369
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add MM_STANDALONE to the list of module types that are permitted to
link to this library.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1426
When calculating the address of RelocBaseEnd,
the RelocBase address is ImageBase + RelocDir->VirtualAddress,
the size of RelocDir is RelocDir->Size.
So the RelocBaseEnd address is:
ImageBase + RelocDir->VirtualAddress + RelocDir->Size - 1
not
ImageBase + RelocDir->VirtualAddress + RelocDir->Size
This patch is to fix this issue when call PeCoffLoaderImageAddress
function to calculate the address of RelocBaseEnd.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The newly introduced generic MmServicesTableLib can be implemented
for traditional SMM (as we did already), but MM_STANDALONE drivers
require an implementation that is based on standalone MM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1426
V2:
(1) Add NULL pointer check for the input parameters
(2) Add check for the "Adjust" value before applying fix ups.
In function PeCoffLoaderRelocateImageForRuntime, it doesn't
do much check when do relocation. For API level consideration,
it's not safe enough.
So this patch is to replace the same code logic with function
PeCoffLoaderImageAddress which will cover more validation.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The definitions of the rebranded MM protocol stack were chosen such
that the existing SMM based core drivers can be reused. So let's
implement MmServicesTableLib based on gEfiMmBaseProtocolGuid, which
is simply gEfiSmmBase2ProtocolGuid under the hood.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
SMM has been rebranded as MM, and can be implemented in traditional
mode or standalone mode, using the same prototype for the services
table. Expose this table via MmServicesTableLib, permitting the
respective implementations to expose a traditional or standalone
version.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja <jagadeesh.ujja@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Provided functions in UEFILib that abstract driver model protocol
uninstallation. This helps drivers to install and uninstall protocols
using a library to keep things seemless.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1429
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417
X86 specific BaseLib API AsmLfence() was introduced to address the Spectre
Variant 1 (CVE-2017-5753) issue. The purpose of this API is to insert
barriers to stop speculative execution. However, the API is highly
architecture (X86) specific, and thus should be avoided using across
generic code.
To address this issue, this patch will add a new BaseLib API called
SpeculationBarrier(). Different architectures will have different
implementations for this API.
For IA32 and x64, the implementation of SpeculationBarrier() will
directly call AsmLfence().
For ARM and AARCH64, this patch will add a temporary empty implementation
as a placeholder. We hope experts in ARM can help to contribute the actual
implementation.
For EBC, similar to the ARM and AARCH64 cases, a temporary empty
implementation is added.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Instead of #defining MAX_ALLOC_ADDRESS to MAX_ADDRESS as intended,
it is #defined to itself, causing all ARM builds to break.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
On some architectures, the maximum representable address deviates from
the virtual address range that is accessible by the firmware at boot
time. For instance, on AArch64, UEFI mandates a 4 KB page size, which
limits the address space to 48 bits, while more than that may be
populated on a particular platform, for use by the OS.
So introduce a new macro MAX_ALLOC_ADDRESS, which represent the maximum
address the firmware should take into account when allocating memory
ranges that need to be accessible by the CPU at boot time.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
ARM uses the low order bit of a branch target address to decide in
which execution mode (ARM or Thumb) a function needs to be called.
In order for this to work across object files, ELF function symbols
will have the low bit set if they were emitted in Thumb mode and
cleared otherwise. This annotation is only emitted if the ELF symbols
are annotated as function, since taking the address of some data
symbol (e.g., a literal) should not produce a value with the low bit
set, even if it appears in an object file containing Thumb code.
This means that all functions coded in assembler must have this
function annotation, or they may end up getting called in the
wrong mode, crashing the program.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This reverts commit 82379bf660.
On AArch64, we can only use 48 address bits while running in UEFI,
while the GCD and UEFI memory maps may describe up to 52 bits of
physical address space. For this reason, MAX_ADDRESS was reduced
to 48 bits, to ensure that the firmware does not inadvertently
attempt to allocate memory that we cannot access.
However, MAX_ADDRESS is used in runtime drivers as well, and
runtime drivers may deal with kernel virtual addresses, which have
bits [63:48] set. In fact, the OS may be running with 64 KB pages
and pass addresses into the runtime services that use up to 52
bits of address space, either with the top bits set or cleared,
even if the physical address space does not extend beyond 48 bits.
In summary, changing MAX_ADDRESS is a mistake, and needs to be
reverted.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
AArch64 supports the use of more than 48 bits for physical and/or
virtual addressing, but only if the page size is set to 64 KB,
which is not supported by UEFI. So redefine MAX_ADDRESS to cover
only 48 address bits.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BaseIoLibIntrinsicArmVirt was created to prevent LTO from merging
accesses to MMIO regions, resulting in instructions with multiple
output registers that KVM on ARM cannot emulate (since the exception
syndrome information that KVM relies on can only describe a single
output register)
However, using double word loads on ARM amounts to the same thing,
and so code that relies on doing 64-bit MMIO to regions that are
emulated under KVM (such as the GICv3 TYPER register) will still
suffer from the original issue.
So replace ldrd and strd with equivalent two instruction sequences.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1312
Text format for AcpiEx device path in UEFI Spec:
AcpiEx(HID,CID,UID,HIDSTR,CIDSTR,UIDSTR)
AcpiEx(HID|HIDSTR,(CID|CIDSTR,UID|UIDSTR))(Display Only)
When convert device path to text for AcpiEx device path,
current code check AllowShortcuts parameter to convert
the device path to DisplayOnly text format(shorter text
representation) by mistake.
It should check DisplayOnly parameter.
This commit is to fix this issue.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1303
Today's code generates assembly code as below for
InternalSyncIncrement:
__asm__ __volatile__ (
"movl $1, %%eax \n\t"
"lock \n\t"
"xadd %%eax, %1 \n\t"
"inc %%eax \n\t"
: "=a" (Result), // %0
"+m" (*Value) // %1
: // no inputs that aren't also outputs
: "memory",
"cc"
);
0: 55 pushl %ebp
1: 89 e5 movl %esp, %ebp
3: 8b 45 08 movl 8(%ebp), %eax
6: b8 01 00 00 00 movl $1, %eax
b: f0 lock
c: 0f c1 00 xaddl %eax, _InternalSyncIncrement(%eax)
f: 40 incl %eax
10: 5d popl %ebp
11: c3 retl
Line #3 and Line #6 both use EAX as destination register.
Line #c uses EAX and (EAX).
The output operand "=a" tells GCC that EAX is used for output.
But GCC only assumes that EAX will be used in the very last
instruction.
Per GCC document,
"Use the '&' constraint modifier on all output operands that must
not overlap an input. Otherwise, GCC may allocate the output
operand in the same register as an unrelated input operand, on
the assumption that the assembler code consumes its inputs before
producing outputs. This assumption may be false if the assembler
code actually consists of more than one instruction."
"=&a" should be used to tell GCC not use EAX before the assembly.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: 8a94eb9283
Fixes: 17634d026f
Replace the current NULL pointer dereference to retrieve Field's
offset with a call to OFFSET_OF(). This is implemented via
__builtin_offsetof for GCC and Clang, which eliminates UB caught by
Clang UndefinedBehaviorSanitizer.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1243
AcpiExp text device path: AcpiExp(HID,CID,UIDSTR)
And according to UEFI spec, the CID parameter is optional
and has a default value of 0. But current implementation
miss to check following cases for the AcpiExp.
FromText:when text device is AcpiExp(HID,,UIDSTR)/AcpiExp(HID,0,UIDSTR)
ToText: when the CID is 0 in the node structure
This commit is to do the enhancement.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1243
According to UEFI spec,
for the Messaging Device Path with USB Class SubType, some paras
are optional in the text device path.
Take UsbClass(VID,PID,Class,SubClass,Protocol) for example,
The VID is an integer between 0 and 65535 and is optional. The
default value is 0xFFFF.
The PID is an integer between 0 and 65535 and is optional. The
default value is 0xFFFF.
The Class is an integer between 0 and 255 and is optional. The
default value is 0xFF.
The SubClass is an integer between 0 and 255 and is optional. The
default value is 0xFF.
The Protocol is an integer between 0 and 255 and is optional. The
default value is 0xFF.
So if any the optional para is not specified in the text device,
we should set related para in the node structure to default value.
This commit is to do the enhancement for USB Class device path
when optional para is not specified
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Replace multiple, consecutive "\" characters prior to other processing
involving "\" characters. This fixes an issue where "\\..\\..",
"//..//..", and similar input paths are not cleaned properly.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@Intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
