linux-kernel - Re: [RFC] yamldt v0.5, now a DTS compiler too

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <3D2E2DE3-3A5E-4185-852D-C91A70EA62F7@konsulko.com>
Date:   Mon, 9 Oct 2017 17:59:04 +0300
From:   Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To:     Frank Rowand <frowand.list@...il.com>
Cc:     Rob Herring <robherring2@...il.com>,
        Grant Likely <grant.likely@...retlab.ca>,
        David Gibson <david@...son.dropbear.id.au>,
        Tom Rini <trini@...sulko.com>,
        Franklin S Cooper Jr <fcooper@...com>,
        Matt Porter <mporter@...sulko.com>,
        Simon Glass <sjg@...omium.org>,
        Phil Elwell <philip.j.elwell@...il.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Marek Vasut <marex@...x.de>,
        Devicetree Compiler <devicetree-compiler@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] yamldt v0.5, now a DTS compiler too

Hi Frank,

> On Oct 9, 2017, at 02:08 , Frank Rowand <frowand.list@...il.com> wrote:
> 
> On 10/07/17 03:23, Pantelis Antoniou wrote:
>> Hi Rob,
>> 
>>> On Oct 6, 2017, at 16:55 , Rob Herring <robherring2@...il.com> wrote:
>>> 
>>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
>>> <pantelis.antoniou@...sulko.com> wrote:
>>>> Hi Rob,
> 
> < snip >
> 
>>>> eBPF is portable, can be serialized after compiling in the schema file
>>>> and can be executed in the kernel.
>>> 
>>> Executing in the kernel is a non-goal for me.
> 
> Executing in the kernel is an anti-goal for me.
> 
> We are trying to reduce the device tree footprint inside the kernel,
> not increase it.
> 
> 99.99% of the validation should be possible statically, in the compile
> phase.
> 

That’s not possible when you dynamically alter the tree at runtime.

> 
>>>> By stripping out all documentation related properties and nodes keeping
>>>> only the compiled filters you can generate a dtb blob that passed to
>>>> kernel can be used for verification of all runtime changes in the
>>>> kernel's live tree. eBPF is enforcing an execution model that is 'safe'
>>>> so we can be sure that no foul play is possible.
> 
> Run time changes can be assumed correct (short of bugs in the overlay
> application code), if the base tree is validated, the overlay is validated,
> and the interface between the live tree and the overlay is a connector.
> 

You can validate the base tree statically but not the overlays.

In fact a large percentage of overlay usage simply modifies a status property
to turn on or off a device. There is nothing to validate in such case.

The portable connector is still a long ways off and I haven’t seen anything that
could handle something trickier that a few GPIOs and I2C or SPI busses.

My goal is something that works covering all the cases without any surprising
gotchas.

> 
>>> Humm, if you wanted to ensure dtb's are safe, I'd think that we just
>>> sign them like you would for the kernel or modules.
>>> 
>> 
>> That’s a problem when deploying; the runtime validation is for making sure
>> developers don’t get bogged down chasing problems when working on their
>> own platforms/drivers.
>> 
>> We have absolutely zero checks for stopping badly configured DT blobs
>> hanging the kernel. With runtime validation a bug that might take a few
>> days to figure out can be cut down to a few minutes.
> 
> Same reply as above.
> 
> 
>>>> That means that you can a) run it at boot-time, verifying the dtb blob
>>>> passed by the bootloader for errors (potentially disabling devices
>>>> that their nodes fail) and b) run it when applying overlays to reject
>>>> any that result in an invalid tree.
>>> 
>>> Let's get verification at build time working first, then we can worry
>>> about something like this.
> 
> < snip >
> 

Right, let’s get build verification working first.

> -Frank

Regards

— Pantelis