lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 14 Jan 2014 11:35:25 -0800
From:	Roy Franz <roy.franz@...aro.org>
To:	Rob Herring <robherring2@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Matt Fleming <matt.fleming@...el.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Linaro Patches <patches@...aro.org>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Mark Salter <msalter@...hat.com>,
	Grant Likely <grant.likely@...aro.org>,
	Dave P Martin <dave.martin@....com>
Subject: Re: [PATCH V6 6/8] Add EFI stub for ARM

On Tue, Jan 14, 2014 at 11:29 AM, Rob Herring <robherring2@...il.com> wrote:
> On Fri, Jan 10, 2014 at 10:30 AM, Roy Franz <roy.franz@...aro.org> wrote:
>> This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
>> operates similarly to the x86 stub: 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 loading the initrd (optionaly) and
>> device tree from the system partition based on the kernel command line.
>> The stub updates the device tree as necessary, adding entries for EFI
>> runtime services. The PE/COFF "MZ" header at offset 0 results in the
>> first instruction being an add that corrupts r5, which is not used by
>> the zImage interface.
>>
>> Signed-off-by: Roy Franz <roy.franz@...aro.org>
>> Acked-by: Grant Likely <grant.likely@...aro.org>
>> ---
>
> [snip]
>
>> +       /* Look up the base of DRAM from the device tree. */
>> +       fdt = (void *)fdt_addr;
>> +       node = fdt_subnode_offset(fdt, 0, "memory");
>> +       region = fdt_getprop(fdt, node, "reg", NULL);
>> +       if (region) {
>> +               dram_base = fdt64_to_cpu(region->base);
>
> This will not work if the address is 32-bit size.
>
>> +       } else {
>> +               /* There is no way to get amount or addresses of physical
>> +                * memory installed using EFI calls.  If the device tree
>> +                * we read from disk doesn't have this, there is no way
>> +                * for us to construct this informaion.
>> +                */
>> +               pr_efi_err(sys_table, "No 'memory' node in device tree.\n");
>> +               goto fail_free_fdt;
>
> The current pc can't be used to determine the DRAM base like AUTO_ZRELADDR?
>
> Rob

Hi Rob,

   UEFI may load the stub based kernel anywhere, so we don't get any
useful information from where we were loaded.
I am currently working on getting the base address from the EFI memory
map, so all of the above code will go away, the only FDT
operations that the stub will perform is to add the EFI related fields.

Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ