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: <5283B83A.8030206@gmail.com>
Date:	Wed, 13 Nov 2013 11:34:50 -0600
From:	Rob Herring <robherring2@...il.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Vineet Gupta <vgupta@...opsys.com>,
	James Hogan <james.hogan@...tec.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Jonas Bonn <jonas@...thpole.se>,
	Chris Zankel <chris@...kel.net>,
	Rob Herring <rob.herring@...xeda.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 14/17] dt: Consolidate __dtb_start declarations in <linux/of_fdt.h>

On 11/13/2013 11:20 AM, Geert Uytterhoeven wrote:
> On Wed, Nov 13, 2013 at 4:51 PM, Rob Herring <robherring2@...il.com> wrote:
>> On Tue, Nov 12, 2013 at 1:42 PM, Geert Uytterhoeven
>> <geert@...ux-m68k.org> wrote:
>>> The different architectures used their own (and different) declarations:
>>>
>>>     extern struct boot_param_header __dtb_start;
>>>     extern u32 __dtb_start[];
>>>     extern char __dtb_start[];
>>>
>>> Consolidate them using the first variant in <linux/of_fdt.h>.
>>> This requires adding a few "address of" operators on architectures where
>>> __dtb_start was an array before.
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert@...ux-m68k.org>
>>> Cc: Vineet Gupta <vgupta@...opsys.com>
>>> Cc: James Hogan <james.hogan@...tec.com>
>>> Cc: Ralf Baechle <ralf@...ux-mips.org>
>>> Cc: Jonas Bonn <jonas@...thpole.se>
>>> CC: Chris Zankel <chris@...kel.net>
>>> Cc: Rob Herring <rob.herring@...xeda.com>
>>> Cc: devicetree@...r.kernel.org
>>> ---
>>>  arch/arc/include/asm/sections.h             |    1 -
>>>  arch/arc/kernel/setup.c                     |    2 +-
>>>  arch/metag/kernel/setup.c                   |    6 +-----
>>>  arch/mips/include/asm/mips-boards/generic.h |    4 ----
>>>  arch/mips/lantiq/prom.h                     |    2 --
>>>  arch/mips/netlogic/xlp/dt.c                 |    4 ++--
>>>  arch/mips/ralink/of.c                       |    2 --
>>>  arch/openrisc/kernel/setup.c                |    2 +-
>>>  arch/openrisc/kernel/vmlinux.h              |    2 --
>>>  arch/xtensa/kernel/setup.c                  |    3 +--
>>>  include/linux/of_fdt.h                      |    3 +++
>>>  11 files changed, 9 insertions(+), 22 deletions(-)
>>
>> This is great, but I would like to see this taken one step further and
>> move the selection logic into the core code. We can try to use the
>> built-in dtb if early_init_dt_scan is passed a NULL or invalid dtb. This
>> should work for most arches I think and still allows an arch to do a
>> different selection algorithm if desired.
> 
> Yes, that makes sense.
> 
>> Are the DT related patches dependent on the rest of the series?
> 
> Not really. There may be small rejects if you apply it out-of-order,
> but nothing serious.
> 
>> Something like this is what I have in mind:
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 5c47910..723f854d 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -869,14 +869,16 @@ 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;
>>
>> +       if (!initial_boot_params ||
>> +           (be32_to_cpu(initial_boot_params->magic) != OF_DT_HEADER))
>> +               initial_boot_params = &__dtb_start;
>> +
>>         /* check device tree validity */
>> -       if (be32_to_cpu(initial_boot_params->magic) != OF_DT_HEADER) {
>> +       if (!initial_boot_params ||
> 
> initial_boot_params cannot be NULL here, so no need to check.

What about the case of no built-in dtb like on arm?

> 
>> +           (be32_to_cpu(initial_boot_params->magic) != OF_DT_HEADER)) {
> 
> However, if __dtb_end == __dtb_start, you may be reading random
> data here from the next section. The OF_DT_HEADER check should cover
> this, but better safe than sorry?

Then we should also check that (__dtb_end != __dtb_start).

Rob

> 
>>                 initial_boot_params = NULL;
>>                 return false;
>>         }
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 

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