If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.
The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.
Check that *Memory refers to an unallocated page.
UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.
Change the return value.
UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.
Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.
This check is mandated by the UEFI specification.
Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
For debug messages inside EFI API functions we should use the EFI_PRINT
macro which gives us well aligned output like:
EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718)
EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes
EFI: Exit: efi_allocate_pool_ext: 0
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Use a checksum to validate that efi_free_pool() is only called for memory
allocated by efi_allocated_pool().
Add a plausibility check to efi_free_pages() checking that the address
passed is page aligned.
Update related function comments to match Sphinx style.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of
the assigned memory. If we pass the address of a pointer here, an illegal
memory access occurs on 32bit systems.
Fixes: 282a06cbca ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Commit 7b78d6438a ("efi_loader: Reserve unaccessible memory") introduced
a comparison between RAM top and RAM start that was not known at the time
when the patch of commit 49759743bf ("efi_loader: eliminate sandbox
addresses") was written.
The sandbox uses an address space that is only relevant in the sandbox
context. We have to map ram_top from the sandbox address space to the
physical address space before using it in the EFI subsystem.
Fixes: 49759743bf ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a ("efi_loader: Reserve unaccessible memory")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
The UEFI spec mandates that runtime sections are 64kb aligned to enable
support for 64kb page size OSs.
This patch ensures that we extend the runtime section to 64kb to be spec
compliant.
Signed-off-by: Alexander Graf <agraf@suse.de>
When allocating EFI memory pages the size in bytes has to be converted to
pages.
Provide a macro efi_size_in_pages() for this conversion.
Use it in the EFI subsystem and correct related comments.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Do not use the sandbox's virtual address space for the internal structures
of the memory map. This way we can eliminate a whole lot of unnecessary
conversions.
The only conversion remaining is the one when adding known memory.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
On some systems, not all RAM may be usable within U-Boot. Maybe the
memory maps are incomplete, maybe it's used as workaround for broken
DMA. But whatever the reason may be, a platform can say that it does
not wish to have its RAM accessed above a certain address by defining
board_get_usable_ram_top().
In the efi_loader world, we ignored that hint, mostly because very few
boards actually have real restrictions around this.
So let's honor the board's wish to not access high addresses during
boot time. The best way to do so is by indicating the respective pages
as "allocated by firmware". That way, Operating Systems will still
use the pages after boot, but before boot no allocation will use them.
Reported-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Baruch Siach <baruch@tkos.co.il>
If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the
number of memory pages may be incorrectly calculated.
We have to round up the start address and to round down the end address
to determine which complete pages are provided by the memory bank.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
When the max_addr parameter of efi_find_free_memory() is within bounds
of an existing map and fits the reservation, we just return that address
as allocation value.
That breaks however if max_addr is not page aligned. So ensure that it
always comes to us page aligned, simplifying the allocation logic.
Without this, I've seen breakage where we were allocating pages at -1U
(32bit) which fits into a region that spans beyond 0x100000000. In that
case, we would return 0xffffffff as a valid memory allocation, although
we usually do guarantee they are all page aligned.
Fix this by aligning the max address argument always.
Signed-off-by: Alexander Graf <agraf@suse.de>
We currently do not combine memory entries that are adjacent and have
the same attributes. The problem with that is that our memory map can
easily grow multiple hundreds of entries in a simple UEFI Shell
environment.
So let's make sure we always combine all entries to make the memory
map as small as possible. That way every other piece of code that
loops through it should also gain some nice speed ups.
Signed-off-by: Alexander Graf <agraf@suse.de>
This reverts commit ccfc78b820.
Now that the underlying issue is fixed, we can revert the revert and hence
restore the original EFI code.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
In int-ll64.h, we always use the following typedefs:
typedef unsigned int u32;
typedef unsigned long uintptr_t;
typedef unsigned long long u64;
This does not need to match to the compiler's <inttypes.h>.
Do not include it.
The use of PRI* makes the code super-ugly. You can simply use
"l" for printing uintptr_t, "ll" for u64, and no modifier for u32.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Starting with commit 867a6ac86d ("efi: Add start-up library code"),
sparse constantly complains about truncated constant value in efi.h:
include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0)
This can get quite noisy, preventing real issues to be noticed:
$ make defconfig
*** Default configuration is based on 'sandbox_defconfig'
$ make C=2 -j12 2>&1 | grep truncates | wc -l
441
After the patch is applied:
$ make C=2 -j12 2>&1 | grep truncates | wc -l
0
$ sparse --version
v0.5.2
Following the suggestion of Heinrich Schuchardt, instead of only
fixing the root-cause, I replaced the whole enum of _SHIFT values
by ULL defines. This matches both the UEFI 2.7 spec and the Linux
kernel implementation.
Some ELF size comparison before and after the patch (gcc 7.3.0):
efi-x86_payload64_defconfig:
text data bss dec hex filename
407174 29432 278676 715282 aea12 u-boot.old
407152 29464 278676 715292 aea1c u-boot.new
-22 +32 0 +10
efi-x86_payload32_defconfig:
text data bss dec hex filename
447075 30308 280076 757459 b8ed3 u-boot.old
447053 30340 280076 757469 b8edd u-boot.new
-22 +32 0 +10
Fixes: 867a6ac86d ("efi: Add start-up library code")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
We should only dereference parameter memory_map_size after checking that
it is valid.
Fixes: 8e835554b3 ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
This reverts commit aa909462d0. This change
caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for
example when running test/py.
Reverting this change isn't optimal, but at least restores TX1 to a working
state. In the future, we should:
a) Fix whatever problem causes the crash with this patch applied. This
needs further discussion, so isn't something we can immediately do.
b) Undo the revert; re-apply the original patch to efi_allocate_pages.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
The UEFI spec requires that the memory map key is checked in
ExitBootServices().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Check the parameters of boottime service GetMemoryMap().
Return EFI_INVALID_PARAMETER where required by the UEFI spec.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
We currently expose host addresses in the EFI memory map. That can be
bad if we ever want to use sandbox to boot strap a real kernel, because
then the kernel would fetch its memory table from our host virtual address
map. But to make that use case work, we would need to have full control
over the address space the EFI application sees.
So let's expose only U-Boot addresses to the guest until we get to the
point of allocation. EFI's allocation functions are fun - they can take
U-Boot addresses as input values for hints and return host addresses as
allocation results through the same uint64_t * parameter. So we need to
be extra careful on what to pass in when.
With this patch I am successfully able to run the efi selftest suite as
well as grub.efi on aarch64.
Signed-off-by: Alexander Graf <agraf@suse.de>
With sandbox the U-Boot code is not mapped into the sandbox memory range
so does not need to be excluded when allocating EFI memory. Update the EFI
memory init code to take account of that.
Signed-off-by: Simon Glass <sjg@chromium.org>
[agraf: Remove map_sysmem() call and header reference]
Signed-off-by: Alexander Graf <agraf@suse.de>
When running on the sandbox the stack is not necessarily at a higher memory
address than the highest free memory.
There is no reason why the checking of the highest memory address should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
EFI_ALLOCATE_MAX_ADDRESS.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[agraf: use -1ULL instead]
Signed-off-by: Alexander Graf <agraf@suse.de>
efi_mem_carve_out() is used to remove memory pages from a mapping.
As the number of pages to be removed is a 64bit type the return type
should be 64bit too.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Do not use anonymous constants when calling efi_allocage_pages.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
asm/global_data.h is already included via common.h.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
As part of the main conversion a few files were missed. These files had
additional whitespace after the '*' and before the SPDX tag and my
previous regex was too strict. This time I did a grep for all SPDX tags
and then filtered out anything that matched the correct styles.
Fixes: 83d290c56f ("SPDX: Convert all of our single license tags to Linux Kernel style")
Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
The headers are not in the correct order. Fix this. Also drop libfdt_env.h
since it is not needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rebased
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Using the existing predefined constants is less error prone and
makes the code easier to read.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Thomas reported U-Boot failed to build host tools if libfdt-devel
package is installed because tools include libfdt headers from
/usr/include/ instead of using internal ones.
This commit moves the header code:
include/libfdt.h -> include/linux/libfdt.h
include/libfdt_env.h -> include/linux/libfdt_env.h
and replaces include directives:
#include <libfdt.h> -> #include <linux/libfdt.h>
#include <libfdt_env.h> -> #include <linux/libfdt_env.h>
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Add comments describing memory functions.
Fix the formatting of a function declaration.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Consistenly use efi_uintn_t wherever the UEFI spec uses
UINTN in boot services interfaces.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
This avoids printf() spam about file reads (such as loading an image)
into unaligned buffers (and the associated memcpy()). And generally
seems like a good idea.
Signed-off-by: Rob Clark <robdclark@gmail.com>
[agraf: use __aligned]
Signed-off-by: Alexander Graf <agraf@suse.de>
When booting shim -> fallback -> shim -> grub -> linux the memory map is
a bit larger than the size linux passes in on the first call. But in
the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size
to linux so it would loop forever.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
efi_get_memory_map should set a defined value for map_key.
We later can introduce the test against this value in
efi_exit_boot_services as required by the UEFI standard.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
If efi_free_pool is called with argument NULL an illegal memory
access occurs.
So let's check the parameter on entry.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Instead of adding all memory banks, add a hook so individual SoC/board
can has its own implementation.
Signed-off-by: York Sun <york.sun@nxp.com>
CC: Alexander Graf <agraf@suse.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
As soon as a mapping is unlinked from the list, there are no further
references to it, so it should be freed. If it not unlinked,
update the start address and length.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
The code assumes sorted mappings in descending address order. When
splitting a mapping, insert the new part next to the current mapping.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Currently each allocation creates a new mapping. Readding the mapping
as free memory (EFI_CONVENTIONAL_MEMORY) potentially allows to hand out
an existing mapping, thus limiting the number of mapping descriptors in
the memory map.
Mitigates a problem with current (4.8rc7) linux kernels when doing an
efi_get_memory map, resulting in an infinite loop. Space for the memory
map is reserved with allocate_pool (implicitly creating a new mapping) and
filled. If there is insufficient slack space (8 entries) in the map, the
space is freed and a new round is started, with space for one more entry.
As each round increases requirement and allocation by exactly one, there
is never enough slack space. (At least 32 entries are allocated, so as
long as there are less than 24 entries, there is enough slack).
Earlier kernels reserved no slack, and did less allocations, so this
problem was not visible.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
We need a functional free_pool implementation, as otherwise each
allocate_pool causes growth of the memory descriptor table.
Different to free_pages, free_pool does not provide the size for the
to be freed allocation, thus we have to track the size ourselves.
As the only EFI requirement for pool allocation is an alignment of
8 bytes, we can keep allocating a range using the page allocator,
reserve the first 8 bytes for our bookkeeping and hand out the
remainder to the caller. This saves us from having to use any
independent data structures for tracking.
To simplify the conversion between pool allocations and the corresponding
page allocation, we create an auxiliary struct efi_pool_allocation.
Given the allocation size free_pool size can handoff freeing the page
range, which was indirectly allocated by a call to allocate_pool,
to free_pages.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
We currently handle efi_allocate_pool() in our boot time service
file. In the following patch, pool allocation will receive additional
internal semantics that we should preserve inside efi_memory.c instead.
As foundation for those changes, split the function into an externally
facing efi_allocate_pool_ext() for use by payloads and an internal helper
efi_allocate_pool() in efi_memory.c that handles the actual allocation.
While at it, change the magic 0xfff / 12 constants to the more obvious
EFI_PAGE_MASK/SHIFT defines.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
The current efi_get_memory_map() function overwrites the map_size
property before reading its value. That way the sanity check whether our
memory map fits into the given array always succeeds, potentially
overwriting arbitrary payload memory.
This patch moves the property update write after its sanity check, so
that the check actually verifies the correct value.
So far this has not triggered any known bugs, but we're better off safe
than sorry.
If the buffer is to small, the returned memory_map_size indicates the
required size to the caller.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
