From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754920AbdJIO7P (ORCPT ); Mon, 9 Oct 2017 10:59:15 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:43818 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752400AbdJIO7J (ORCPT ); Mon, 9 Oct 2017 10:59:09 -0400 X-Google-Smtp-Source: AOwi7QA94BaumrGH/ShgBdmvtdCe8vBuAFpcSAshmSN2AhKKe9PFzLE7PM9YJv1IAsvGa+aq1IWWRQ== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [RFC] yamldt v0.5, now a DTS compiler too From: Pantelis Antoniou In-Reply-To: <59DAAFD3.9070900@gmail.com> Date: Mon, 9 Oct 2017 17:59:04 +0300 Cc: Rob Herring , Grant Likely , David Gibson , Tom Rini , Franklin S Cooper Jr , Matt Porter , Simon Glass , Phil Elwell , Geert Uytterhoeven , Marek Vasut , Devicetree Compiler , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Message-Id: <3D2E2DE3-3A5E-4185-852D-C91A70EA62F7@konsulko.com> References: <1506628736.28192.9.camel@hp800z> <1506973580.17981.5.camel@hp800z> <1507039989.17981.25.camel@hp800z> <1507052352.17981.48.camel@hp800z> <4D25319A-34A8-4FE6-8B14-616686D2192A@konsulko.com> <59DAAFD3.9070900@gmail.com> To: Frank Rowand X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v99ExJCt022697 Hi Frank, > On Oct 9, 2017, at 02:08 , Frank Rowand wrote: > > On 10/07/17 03:23, Pantelis Antoniou wrote: >> Hi Rob, >> >>> On Oct 6, 2017, at 16:55 , Rob Herring wrote: >>> >>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou >>> 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