Hi Frank, > On Oct 9, 2017, at 02:08 , Frank Rowand <frowand.list@xxxxxxxxx> wrote: > > On 10/07/17 03:23, Pantelis Antoniou wrote: >> Hi Rob, >> >>> On Oct 6, 2017, at 16:55 , Rob Herring <robherring2@xxxxxxxxx> wrote: >>> >>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou >>> <pantelis.antoniou@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
