| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.tianocore.org/show_bug.cgi?id=1373
Replace BSD 2-Clause License with BSD+Patent License. This change is
based on the following emails:
https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html
RFCs with detailed process for the license change:
V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of looking at the PCD gArmTokenSpaceGuid.PcdSystemMemoryBase
to decide which DT node covers the memory we are already using, query
the GCD memory space map, which is the authoritative source for this
kind of information
This fixes a problem observed by Michael on platforms where this PCD
is of the 'Patchable' type, which means updates to its value do not
propagate to other modules.
Reported-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of invoking gDS->SetMemorySpaceAttributes to set the EFI_MEMORY_XP
attribute on newly added regions, which is guaranteed to fail if the same
attribute was not declared as a capability of the region when it as added,
invoke the CPU arch protocol directly to set the EFI_MEMORY_XP attribute
if our memory protection policy demands it.
Reported-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using DxeServices::SetMemorySpaceAttributes to set cacheability
attributes has the side effect of stripping permission attributes,
given that those are bits in the same bitfield, and so setting the
Attributes argument to EFI_MEMORY_WB implies not setting EFI_MEMORY_XP
or EFI_MEMORY_RO attributes.
In fact, the situation is even worse, given that the descriptor returned
by DxeServices::GetMemorySpaceDescriptor does not reflect the permission
attributes that may have been set by the preceding call to
DxeServices::AddMemorySpace if PcdDxeNxMemoryProtectionPolicy has been
configured to map EfiConventionalMemory with non-executable permissions.
Note that this applies equally to the non-executable stack and to PE/COFF
sections that may have been mapped with R-X or RW- permissions. This is
due to the ambiguity in the meaning of the EFI_MEMORY_RO/EFI_MEMORY_XP
attributes when used in the GCD memory map, i.e., between signifying
that an underlying RAM region has the controls to be configured as
read-only or non-executable, and signifying that the contents of a
certain UEFI memory region allow them to be mapped with certain
restricted permissions.
So let's check the policy in PcdDxeNxMemoryProtectionPolicy directly,
and set the EFI_MEMORY_XP attribute if appropriate for
EfiConventionalMemory regions.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use the FDT client protocol rather than parsing the DT directly using
fdtlib. While we're at it, update the code so it deals correctly with
memory nodes that describe multiple disjoint regions in their "reg"
properties, and make the code work with #address-cells/#size-cells
properties of <1> as well as <2>.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general, on an ARM system, mapping normal memory as device memory may
have unintended side effects, given that unaligned accesses or loads and
stores with special semantics (e.g., load/store exclusive) may fault or
may not work as expected.
Under KVM, the situation is even worse, since the host may not expect the
guest to perform uncached accesses, and so writes to such an uncached
region may get lost completely.
Since the only safe mapping type under KVM is EFI_MEMORY_WB, remove all
other memory type attributes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Redefine the reference to PcdSystemMemoryBase in HighMemDxe.inf as
a plain [Pcd] rather than [FixedPcd] (and fix up the code as
appropriate). This allows us to align ArmVirtQemuKernel with
ArmVirtQemu, given that the former uses a patchable PCD not a fixed
PCD.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
Here we add the memory space for the high memory nodes except the lowest
one in FDT. So these spaces will show up in the UEFI memory map.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: rewrap at 79 chars, use NULL, print Status]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19124 6f19259b-4bc3-4df7-8a09-765794883524
|
