From: Frank Rowand <frowand.list@gmail.com> To: Pantelis Antoniou <pantelis.antoniou@konsulko.com>, Rob Herring <robherring2@gmail.com> Cc: Grant Likely <grant.likely@secretlab.ca>, David Gibson <david@gibson.dropbear.id.au>, 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: Sun, 8 Oct 2017 16:08:03 -0700 [thread overview] Message-ID: <59DAAFD3.9070900@gmail.com> (raw) In-Reply-To: <4D25319A-34A8-4FE6-8B14-616686D2192A@konsulko.com> 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. >> 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 > -Frank
WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>, David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@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: Sun, 8 Oct 2017 16:08:03 -0700 [thread overview] Message-ID: <59DAAFD3.9070900@gmail.com> (raw) In-Reply-To: <4D25319A-34A8-4FE6-8B14-616686D2192A-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 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. >> 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 > -Frank
next prev parent reply other threads:[~2017-10-08 23:08 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 [this message] 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 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=59DAAFD3.9070900@gmail.com \ --to=frowand.list@gmail.com \ --cc=david@gibson.dropbear.id.au \ --cc=devicetree-compiler@vger.kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=fcooper@ti.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=pantelis.antoniou@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.