linux-kernel - Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap

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: <CACxGe6v7q2=Dxn6BE_V-w9CEKxAsZ6zQd5Uqm4TeYGYCCu76cg@mail.gmail.com>
Date:	Fri, 9 Nov 2012 21:08:14 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	David Gibson <david@...son.dropbear.id.au>
Cc:	Pantelis Antoniou <panto@...oniou-consulting.com>,
	Rob Herring <robherring2@...il.com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Scott Wood <scottwood@...escale.com>,
	Tony Lindgren <tony@...mide.com>,
	Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>, Russ Dill <Russ.Dill@...com>,
	linux-omap@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving
 omap_devices to mach-omap2)

On Fri, Nov 9, 2012 at 2:26 AM, David Gibson
<david@...son.dropbear.id.au> wrote:
>> Summary points:
>> - Create an FDT overlay data format and usage model
>>   - SHALL reliable resolve or validate of phandles between base and
>>     overlay trees
>
> So, I'm not at all clear on what this proposed phandle validation
> would involve.  I'm also not convinced it's as necessary as you
> think, more on that below.

Simply this: I'm taking this example from the omap3-beagle-xm.dts. It
has the following stanza which is currently rolled into the resulting
.dtb when compiled.

&i2c1 {
        clock-frequency = <2600000>;

        twl: twl@48 {
                reg = <0x48>;
                interrupts = <7>; /* SYS_NIRQ cascaded to intc */
                interrupt-parent = <&intc>;

                vsim: regulator-vsim {
                        compatible = "ti,twl4030-vsim";
                        regulator-min-microvolt = <1800000>;
                        regulator-max-microvolt = <3000000>;
                };

                twl_audio: audio {
                        compatible = "ti,twl4030-audio";
                        codec {
                        };
                };
        };
};

However, if it were compiled into a separate dtb overlay it might look
like this:

/ {
    .readonly;
    ocp {
        .readonly;
        interrupt-controller@...00000 {
            phandle = <0x1234>; /* EXPECTED PHANDLE */
            .readonly;
        };
        i2c@...70000 {
            .must-exist;
            clock-frequency = <2600000>;

            twl@48 {
                reg = <0x48>;
                interrupts = <7>;
                interrupt-parent = <0x1234>;   /* RESOLVED PHANDLE */

                vsim: regulator-vsim {
                        compatible = "ti,twl4030-vsim";
                        regulator-min-microvolt = <1800000>;
                        regulator-max-microvolt = <3000000>;
                };

                twl_audio: audio {
                        compatible = "ti,twl4030-audio";
                        codec {
                        };
                };
            };
        };
    };
};

Notice I've included the intc node and it's phandle. By phandle
validation I merely mean that when applying an overly the firmware or
kernel must verify that the phandles in the overlay match the phandle
in the base tree. If they don't match, then refuse to apply the
overhead. This approach avoids the need to find and fixup phandles in
the overlay. And if the phandle is generated from a hash of the
full_name, then the resulting phandle will only change if the node
moves.

Similarly, at application time it should be verified that the nodes
with a .readonly or .must-exist property could be verified to actually
exist before attempting to apply the overlay. I used two different
properties with the idea that only certain nodes would need to be
modified... exactly what the policies should be is yet to be
determined.

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/