On 26 November 2015 at 11:47, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 23 Nov, at 10:06:33AM, Ard Biesheuvel wrote:
>> From: Roy Franz <roy.franz@xxxxxxxxxx>
>>
>> This patch adds EFI stub support for the ARM Linux kernel.
>>
>> The EFI stub operates similarly to the x86 and arm64 stubs: it is a
>> shim between the EFI firmware and the normal zImage entry point, and
>> sets up the environment that the zImage is expecting. This includes
>> optionally loading the initrd and device tree from the system partition
>> based on the kernel command line.
>>
>> Signed-off-by: Roy Franz <roy.franz@xxxxxxxxxx>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
>> ---
>> arch/arm/Kconfig | 19 +++
>> arch/arm/boot/compressed/Makefile | 4 +-
>> arch/arm/boot/compressed/efi-header.S | 130 ++++++++++++++++++++
>> arch/arm/boot/compressed/head.S | 54 +++++++-
>> arch/arm/boot/compressed/vmlinux.lds.S | 7 ++
>> arch/arm/include/asm/efi.h | 23 ++++
>> drivers/firmware/efi/libstub/Makefile | 9 ++
>> drivers/firmware/efi/libstub/arm-stub.c | 4 +-
>> drivers/firmware/efi/libstub/arm32-stub.c | 85 +++++++++++++
>> 9 files changed, 331 insertions(+), 4 deletions(-)
>
> [...]
>
>> +
>> + /*
>> + * Relocate the zImage, if required. ARM doesn't have a
>> + * preferred address, so we set it to 0, as we want to allocate
>> + * as low in memory as possible.
>> + */
>> + *image_size = image->image_size;
>> + status = efi_relocate_kernel(sys_table, image_addr, *image_size,
>> + *image_size, 0, 0);
>> + if (status != EFI_SUCCESS) {
>> + pr_efi_err(sys_table, "Failed to relocate kernel.\n");
>> + efi_free(sys_table, *reserve_size, *reserve_addr);
>> + *reserve_size = 0;
>> + return status;
>> + }
>
> If efi_relocate_kernel() successfully allocates memory at address 0x0,
> is that going to cause issues with NULL pointer checking?
Actually, it is the reservation done a bit earlier that could
potentially end up at 0x0, and the [compressed] kernel is always at
least 32 MB up in memory, so that it can be decompressed as close to
the base of DRAM as possible.
As far as I can tell, efi_free() deals correctly with allocations at
address 0x0, and that is the only dealing we have with the
reservation. So I don't think there is an issue here.
--
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
