| 511d0b97 | 01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping
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 s
efi_loader: Do not leak memory when unlinking a mapping
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>
show more ...
|
| b6a95172 | 01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry
The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping
efi_loader: Keep memory mapping sorted when splitting an entry
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>
show more ...
|
| b61d857b | 01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool
Currently each allocation creates a new mapping. Readding the mapping as free memory (EFI_CONVENTIONAL_MEMORY) potentially allows to hand out an existing
efi_loader: Readd freed pages to memory pool
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>
show more ...
|
| 42417bc8 | 09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing
We need a functional free_pool implementation, as otherwise each allocate_pool causes growth of the memory descriptor table.
Different to
efi_loader: Track size of pool allocations to allow freeing
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>
show more ...
|
| ead1274b | 09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c
We currently handle efi_allocate_pool() in our boot time service file. In the following patch, pool allocation will receive addition
efi_loader: Move efi_allocate_pool implementation to efi_memory.c
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>
show more ...
|
| 991d62fa | 13-Sep-2016 |
Robin Randhawa <robin.randhawa@arm.com> |
efi_loader: Fix crash on 32-bit systems
A type mismatch in the efi_allocate_pool boot service flow causes hazardous memory scribbling on 32-bit systems.
This is efi_allocate_pool's prototype:
stat
efi_loader: Fix crash on 32-bit systems
A type mismatch in the efi_allocate_pool boot service flow causes hazardous memory scribbling on 32-bit systems.
This is efi_allocate_pool's prototype:
static efi_status_t EFIAPI efi_allocate_pool(int pool_type, unsigned long size, void **buffer);
Internally, it invokes efi_allocate_pages as follows:
efi_allocate_pages(0, pool_type, (size + 0xfff) >> 12, (void*)buffer);
This is efi_allocate_pages' prototype:
efi_status_t efi_allocate_pages(int type, int memory_type, unsigned long pages, uint64_t *memory);
The problem: efi_allocate_pages does this internally:
*memory = addr;
This fix in efi_allocate_pool uses a transitional uintptr_t cast to ensure the correct outcome, irrespective of the system's native word size.
This was observed when bootefi'ing the EFI instance of FreeBSD's first stage bootstrap (boot1.efi) on a 32-bit ARM platform (Qemu VExpress + Cortex-a9).
Signed-off-by: Robin Randhawa <robin.randhawa@arm.com> Signed-off-by: Alexander Graf <agraf@suse.de>
show more ...
|
| bdf5c1b3 | 09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access
The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whe
efi_loader: Fix memory map size check to avoid out-of-bounds access
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>
show more ...
|
| 0812d1a0 | 05-Aug-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: disk: Sanitize exposed devices
When a target device is 0 bytes long, there's no point in exposing it to the user. Let's just skip them.
Also, when an offset is passed into the efi disk
efi_loader: disk: Sanitize exposed devices
When a target device is 0 bytes long, there's no point in exposing it to the user. Let's just skip them.
Also, when an offset is passed into the efi disk creation, we should remove this offset from the total number of sectors we can handle.
This patch fixes both things.
Signed-off-by: Alexander Graf <agraf@suse.de>
show more ...
|
| a8122410 | 05-Jun-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Add DM_VIDEO support
Some systems are starting to shift to support DM_VIDEO which exposes the frame buffer through a slightly different interface.
This is a poor man's effort to support
efi_loader: Add DM_VIDEO support
Some systems are starting to shift to support DM_VIDEO which exposes the frame buffer through a slightly different interface.
This is a poor man's effort to support the dm video interface instead of the lcd one. We still only support a single display device.
Signed-off-by: Alexander Graf <agraf@suse.de> [trini: Remove fb_size / fb_base as they were not used] Signed-off-by: Tom Rini <trini@konsulko.com>
show more ...
|
| 74c16acc | 27-May-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Don't allocate from memory holes
When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however e
efi_loader: Don't allocate from memory holes
When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory.
This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram.
Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>
show more ...
|
| edcef3ba | 02-Jun-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Move to normal debug infrastructure
We introduced special "DEBUG_EFI" defines when the efi loader support was new. After giving it a bit of thought, turns out we really didn't have to -
efi_loader: Move to normal debug infrastructure
We introduced special "DEBUG_EFI" defines when the efi loader support was new. After giving it a bit of thought, turns out we really didn't have to - the normal #define DEBUG infrastructure works well enough for efi loader as well.
So this patch switches to the common debug() and #define DEBUG way of printing debug information.
Signed-off-by: Alexander Graf <agraf@suse.de>
show more ...
|
| c9cfac5d | 18-May-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: gop: Don't expose fb address
Recently Linux is gaining support for efifb on AArch64 and that support actually tries to make use of the frame buffer address we expose to it via gop.
Whil
efi_loader: gop: Don't expose fb address
Recently Linux is gaining support for efifb on AArch64 and that support actually tries to make use of the frame buffer address we expose to it via gop.
While this wouldn't be bad in theory, in practice it means a few bad things
1) We expose 16bit frame buffers as 32bit today 2) Linux can't deal with overlapping non-PCI regions between efifb and a different frame buffer driver
For now, let's just disable exposure of the frame buffer address. Most OSs that get booted will have a native driver for the GPU anyway.
Signed-off-by: Alexander Graf <agraf@suse.de> [trini: Remove line_len entirely] Signed-off-by: Tom Rini <trini@konsulko.com>
show more ...
|