Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752593AbdLEQzu (ORCPT ); Tue, 5 Dec 2017 11:55:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:44206 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752151AbdLEQzs (ORCPT ); Tue, 5 Dec 2017 11:55:48 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44A7221985 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=atull@kernel.org X-Google-Smtp-Source: AGs4zMa8n6eEHuyIPm1WodHjJ+UxK9gfpNbrpyz5+HLeUj7yFfLgK/ygn7zK07P+eidU4dhP7yaUZZbLH6VTkg4Z8cg= MIME-Version: 1.0 In-Reply-To: <157eebaf-89a9-a230-e56b-d98a8e1e26bf@gmail.com> References: <1511816284-12145-1-git-send-email-atull@kernel.org> <157eebaf-89a9-a230-e56b-d98a8e1e26bf@gmail.com> From: Alan Tull Date: Tue, 5 Dec 2017 10:55:05 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 0/2] of: Add whitelist To: Frank Rowand Cc: Rob Herring , Pantelis Antoniou , Moritz Fischer , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-fpga@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2481 Lines: 57 On Thu, Nov 30, 2017 at 6:18 AM, Frank Rowand wrote: > On 11/29/17 08:31, Rob Herring wrote: >> On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand wrote: >>> On 11/27/17 15:58, Alan Tull wrote: >>>> Here's a proposal for a whitelist to lock down the dynamic device tree. >>>> >>>> For an overlay to be accepted, all of its targets are required to be >>>> on a target node whitelist. >>>> >>>> Currently the only way I have to get on the whitelist is calling a >>>> function to add a node. That works for fpga regions, but I think >>>> other uses will need a way of having adding specific nodes from the >>>> base device tree, such as by adding a property like 'allow-overlay;' >>>> or 'allow-overlay = "okay";' If that is acceptable, I could use some >>>> advice on where that particular code should go. >>>> >>>> Alan >>>> >>>> Alan Tull (2): >>>> of: overlay: add whitelist >>>> fpga: of region: add of-fpga-region to whitelist >>>> >>>> drivers/fpga/of-fpga-region.c | 9 ++++++ >>>> drivers/of/overlay.c | 73 +++++++++++++++++++++++++++++++++++++++++++ >>>> include/linux/of.h | 12 +++++++ >>>> 3 files changed, 94 insertions(+) >>>> >>> >>> The plan was to use connectors to restrict where an overlay could be applied. >>> I would prefer not to have multiple methods for accomplishing the same thing >>> unless there is a compelling reason to do so. >> >> Connector nodes need a mechanism to enable themselves, too. I don't >> think connector nodes are going to solve every usecase. >> >> Rob >> > > The overlay code related to connectors does not exist yet, so my comment > is going to be theoretical. > > I would expect the overlay code to check that the target of the overlay > fragment is a connector node, so there is no need to explicitly "enable" > applying an overlay to a connector node. This will depend on how connectors are implemented. My proposal in v1 is that device nodes can have a flag bit. If its not set, then an overlay that contains fragments that target that node can't be applied. There's probably other ways a connector node could be marked as different from other nodes, but a flag bit seems simple. The advantage to this scheme is that it gives me something I can use while connectors don't exist yet and it will still will be useful later for the implementation of connectors (giving connector drivers a way of marking their device nodes as valid targets). > > -Frank