linux-kernel - Re: [PATCH 1/9] dt: Handle passed/built-in DT selection in early_init_dt

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]

Message-Id: <20131121122148.1B43DC40A2C@trevor.secretlab.ca>
Date:	Thu, 21 Nov 2013 12:21:48 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Rob Herring <rob.herring@...xeda.com>
Cc:	devicetree@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH 1/9] dt: Handle passed/built-in DT selection in early_init_dt_scan()

On Tue, 19 Nov 2013 12:12:26 +0100, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> Let early_init_dt_scan() fall-back to the built-in DT if no DT was passed,
> or if it's invalid, so architectures don't have to duplicate this logic.
> 
> Suggested-by: Rob Herring <rob.herring@...xeda.com>
> Signed-off-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> ---
>  drivers/of/fdt.c       |   24 +++++++++++++++++-------
>  include/linux/of_fdt.h |    1 +
>  2 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 2fa024b97c43..a797cd43bc8b 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -868,18 +868,28 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
>  
>  bool __init early_init_dt_scan(void *params)
>  {
> -	if (!params)
> -		return false;
> -
>  	/* Setup flat device-tree pointer */
>  	initial_boot_params = params;
>  
> -	/* check device tree validity */
> -	if (be32_to_cpu(initial_boot_params->magic) != OF_DT_HEADER) {
> -		initial_boot_params = NULL;
> -		return false;
> +	/* check passed device tree validity */
> +	if (initial_boot_params &&
> +	    be32_to_cpu(initial_boot_params->magic) == OF_DT_HEADER) {
> +		pr_info("FDT at %p\n", initial_boot_params);
> +		goto found;
> +	}
> +
> +	/* check built-in device tree validity */
> +	initial_boot_params = &__dtb_start;
> +	if (__dtb_end != (void *)&__dtb_start &&
> +	    be32_to_cpu(initial_boot_params->magic) == OF_DT_HEADER) {
> +		pr_info("Compiled-in FDT at %p\n", initial_boot_params);
> +		goto found;

__dtb_start is in an init section which is discarded after initcalls.
For this to work, the dtb needs to be copied into a region of allocated
memory. The dtb section can also potentially contain multiple .dtb
blobs. In the use case that you care about you are probably only
thinking about one, but it is entirely possible for device drivers to
have a dtb linked in which may break this if it gets linked in a
different order. The specific example I'm thinking about is I want to
have the DT selftest code load an overlay to get testcase data from a
dtb blob.

The other concern I have here is that I don't really want this to be the
default on a lot of platforms. ARM and PowerPC for instance should only
get the default dtb from the boot wrapper. It needs to be configurable
in some way.

Instead of using __dtb_start, it would probably solve both of the above
problems if the build-in DTB has a specific label identifying it as the
default DT.

g.

--
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/