From: Pantelis Antoniou <pantelis.antoniou@konsulko.com> To: David Gibson <david@gibson.dropbear.id.au> Cc: Frank Rowand <frowand.list@gmail.com>, Rob Herring <robherring2@gmail.com>, Grant Likely <grant.likely@secretlab.ca>, Tom Rini <trini@konsulko.com>, Franklin S Cooper Jr <fcooper@ti.com>, Matt Porter <mporter@konsulko.com>, Simon Glass <sjg@chromium.org>, Phil Elwell <philip.j.elwell@gmail.com>, Geert Uytterhoeven <geert@linux-m68k.org>, Marek Vasut <marex@denx.de>, Devicetree Compiler <devicetree-compiler@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [RFC] yamldt v0.5, now a DTS compiler too Date: Mon, 9 Oct 2017 18:07:28 +0300 [thread overview] Message-ID: <8306BF82-3141-4994-8EFE-D5D2052F9FE1@konsulko.com> (raw) In-Reply-To: <20171009000053.GQ10050@umbus.fritz.box> Hi David, > On Oct 9, 2017, at 03:00 , David Gibson <david@gibson.dropbear.id.au> wrote: > > On Sun, Oct 08, 2017 at 04:08:03PM -0700, Frank Rowand wrote: >> On 10/07/17 03:23, Pantelis Antoniou wrote: >>> Hi Rob, >>> >>>> On Oct 6, 2017, at 16:55 , Rob Herring <robherring2@gmail.com> wrote: >>>> >>>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou >>>> <pantelis.antoniou@konsulko.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. >> >> >>>>> 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. > > In addition, no amount of schema validation can really protect the > kernel from a bad DT. Even if the schemas can 100% verify that the DT > is "syntactically" correct, which is ambitious, it can't protect > against a DT which is in the right form, but contains information that > is simply wrong for the hardware in question. That can stuff the > kernel at least as easily as an incorrectly formatted DT. > I disagree. There are multiple levels of validation. For now we’re only talking about binding validation. There can be SoC level validation, board level validation, revision level validation and finally application specific validation. Binding validation is making sure properties/nodes follow the binding document. For instance that for a foo device there’s a mandatory interrupt property. Simplified interrupt = <X>; Binding validation would ‘catch’ errors like assigning a string or not having the interrupt property available. SoC level validation would list the available interrupt number that a given SoC would support for that device. For example that interrupt can only take the values 10 or 99 in a given SoC. Board level validation would narrow this down even further to a value of 10 for a given board model. Similar revision level validation would place further restriction on the allowed configuration. Finally application specific validation could place restriction based on the intended application that piece of hardware is used for. For instance devices that should not exceed a given power budget would have restrictions on the clock frequency of the processor or bus frequencies etc. > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson Regards — Pantelis
WARNING: multiple messages have this Message-ID (diff)
From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>, Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>, Matt Porter <mporter-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, Phil Elwell <philip.j.elwell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>, Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>, Devicetree Compiler <devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [RFC] yamldt v0.5, now a DTS compiler too Date: Mon, 9 Oct 2017 18:07:28 +0300 [thread overview] Message-ID: <8306BF82-3141-4994-8EFE-D5D2052F9FE1@konsulko.com> (raw) In-Reply-To: <20171009000053.GQ10050-K0bRW+63XPQe6aEkudXLsA@public.gmane.org> Hi David, > On Oct 9, 2017, at 03:00 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote: > > On Sun, Oct 08, 2017 at 04:08:03PM -0700, Frank Rowand wrote: >> On 10/07/17 03:23, Pantelis Antoniou wrote: >>> Hi Rob, >>> >>>> On Oct 6, 2017, at 16:55 , Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>>> >>>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou >>>> <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 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. >> >> >>>>> 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. > > In addition, no amount of schema validation can really protect the > kernel from a bad DT. Even if the schemas can 100% verify that the DT > is "syntactically" correct, which is ambitious, it can't protect > against a DT which is in the right form, but contains information that > is simply wrong for the hardware in question. That can stuff the > kernel at least as easily as an incorrectly formatted DT. > I disagree. There are multiple levels of validation. For now we’re only talking about binding validation. There can be SoC level validation, board level validation, revision level validation and finally application specific validation. Binding validation is making sure properties/nodes follow the binding document. For instance that for a foo device there’s a mandatory interrupt property. Simplified interrupt = <X>; Binding validation would ‘catch’ errors like assigning a string or not having the interrupt property available. SoC level validation would list the available interrupt number that a given SoC would support for that device. For example that interrupt can only take the values 10 or 99 in a given SoC. Board level validation would narrow this down even further to a value of 10 for a given board model. Similar revision level validation would place further restriction on the allowed configuration. Finally application specific validation could place restriction based on the intended application that piece of hardware is used for. For instance devices that should not exceed a given power budget would have restrictions on the clock frequency of the processor or bus frequencies etc. > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-10-09 15:07 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-09-28 19:58 [RFC] yamldt v0.5, now a DTS compiler too Pantelis Antoniou 2017-09-28 19:58 ` Pantelis Antoniou 2017-10-01 22:00 ` Rob Herring 2017-10-01 22:00 ` Rob Herring 2017-10-02 7:36 ` Pantelis Antoniou 2017-10-02 19:46 ` Pantelis Antoniou 2017-10-03 7:17 ` Geert Uytterhoeven 2017-10-03 7:33 ` Pantelis Antoniou 2017-10-03 13:18 ` Rob Herring 2017-10-03 14:13 ` Pantelis Antoniou 2017-10-03 14:13 ` Pantelis Antoniou 2017-10-03 17:13 ` Rob Herring 2017-10-03 17:39 ` Pantelis Antoniou 2017-10-03 17:39 ` Pantelis Antoniou 2017-10-06 13:55 ` Rob Herring 2017-10-06 13:55 ` Rob Herring 2017-10-07 10:23 ` Pantelis Antoniou 2017-10-08 23:08 ` Frank Rowand 2017-10-08 23:08 ` Frank Rowand 2017-10-09 0:00 ` David Gibson 2017-10-09 0:00 ` David Gibson 2017-10-09 15:07 ` Pantelis Antoniou [this message] 2017-10-09 15:07 ` Pantelis Antoniou 2017-10-10 1:50 ` David Gibson 2017-10-10 15:19 ` Pantelis Antoniou 2017-10-10 15:19 ` Pantelis Antoniou 2017-10-11 3:49 ` David Gibson 2017-10-11 3:49 ` David Gibson 2017-10-09 14:59 ` Pantelis Antoniou 2017-10-20 17:46 ` Grant Likely 2017-10-20 17:46 ` Grant Likely 2017-10-20 19:16 ` Pantelis Antoniou 2017-10-22 17:54 ` Grant Likely 2017-10-22 17:54 ` Grant Likely 2017-10-22 18:23 ` Pantelis Antoniou 2017-10-22 18:23 ` Pantelis Antoniou 2017-10-22 19:13 ` Grant Likely 2017-10-22 19:13 ` Grant Likely 2017-10-23 10:08 ` Pantelis Antoniou 2017-10-23 10:08 ` Pantelis Antoniou
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8306BF82-3141-4994-8EFE-D5D2052F9FE1@konsulko.com \ --to=pantelis.antoniou@konsulko.com \ --cc=david@gibson.dropbear.id.au \ --cc=devicetree-compiler@vger.kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=fcooper@ti.com \ --cc=frowand.list@gmail.com \ --cc=geert@linux-m68k.org \ --cc=grant.likely@secretlab.ca \ --cc=linux-kernel@vger.kernel.org \ --cc=marex@denx.de \ --cc=mporter@konsulko.com \ --cc=philip.j.elwell@gmail.com \ --cc=robherring2@gmail.com \ --cc=sjg@chromium.org \ --cc=trini@konsulko.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.