linux-kernel - Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full

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:   Fri, 20 Oct 2017 11:06:23 +0300
From:   Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To:     Frank Rowand <frowand.list@...il.com>
Cc:     Moritz Fischer <mdf@...nel.org>, Rob Herring <robh@...nel.org>,
        Alan Tull <atull@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        David Laight <David.Laight@...lab.com>,
        linux-fpga@...r.kernel.org
Subject: Re: [PATCH v2 5/5] of/fdt: only store the device node basename in
 full_name

Hi Frank,

> On Oct 20, 2017, at 00:46 , Frank Rowand <frowand.list@...il.com> wrote:
> 
> On 10/19/17 13:06, Moritz Fischer wrote:
> 
> < snip >
> 
>> We also have plenty of code that is just not aware of overlays, and
>> assumes certain parts of the tree to stay static.
> 
> I would state that somewhat differently.  :-)  There is very little
> code that is aware of overlays, and most code assumes the device tree
> does not change after early boot.
> 
> This is one of the areas where the creation of overlays needs to be
> done with care.
> 

Correct. But this is not breaking the kernel.

In general we have the following case where we load overlays (at least
well formed overlays that are not doing stupid things).

1. Activation of a new device. Usually this works since is something that’s
normally done at boot.

2. Deactivation of a device. This might break because the removal paths
of platform device especially are not well tested (or never executed for that
matter).

3. Modification of properties in an already activated device. If the device driver
has not installed a device tree modification hook (as in almost 99% of the devices)
it will do absolutely nothing, since the device tree is parsed only at probe time.
I can argue that for these cases we could have a catch-all hook that displays a
message that nothing happened.

4. Modification of some part of the tree that’s not part of a device driver, perhaps
the aliases or chosen node. This may potentially be harmful or harmless depending on
what has been modified. For instance modifying an already existing alias might cause
internal inconsistency about device naming, while adding a new aliases should be harmless.
This is a matter of policy per board, whether to allow or not.

Are there other cases that are potentially more harmful?

> 
>> I ran into that issue when I tried to add thermal zones via an overlay,
>> I've been investigating how to fix the thermal framework to work with
>> overlays since then and have some partially working code.
>> Currently the thermal framework parses the thermal-zones node at boot,
>> and assumes this stays static. This breaks with overlays.
>> 
>> I agree we eventually need to fix the parts that break when we use
>> overlays.
> 

Regards

— Pantelis