lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240117174114.GA2779523-robh@kernel.org>
Date: Wed, 17 Jan 2024 11:41:14 -0600
From: Rob Herring <robh@...nel.org>
To: Stephen Boyd <sboyd@...nel.org>
Cc: Frank Rowand <frowand.list@...il.com>, linux-kernel@...r.kernel.org,
	patches@...ts.linux.dev, linux-um@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org, kunit-dev@...glegroups.com,
	linux-kselftest@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 4/6] of: Create of_root if no dtb provided by firmware

On Tue, Jan 16, 2024 at 05:18:15PM -0800, Stephen Boyd wrote:
> Quoting Rob Herring (2024-01-15 12:32:30)
> > On Fri, Jan 12, 2024 at 12:07:47PM -0800, Stephen Boyd wrote:
> > > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> > > index da9826accb1b..9628e48baa15 100644
> > > --- a/drivers/of/Kconfig
> > > +++ b/drivers/of/Kconfig
> > > @@ -54,9 +54,14 @@ config OF_FLATTREE
> > >       select CRC32
> > >  
> > >  config OF_EARLY_FLATTREE
> > > -     bool
> > > +     bool "Functions for accessing Flat Devicetree (FDT) early in boot"
> > 
> > I think we could instead just get rid of this kconfig option. Or 
> > always enable with CONFIG_OF (except on Sparc). The only cost of 
> > enabling it is init section functions which get freed anyways.
> 
> Getting rid of it is a more massive change. It can be the default and
> kept hidden instead? If it can't be selected on Sparc then it should be
> hidden there anyway.

The easier option is certainly fine for this series. I just don't want 
it visible.

> > >       select DMA_DECLARE_COHERENT if HAS_DMA && HAS_IOMEM
> > >       select OF_FLATTREE
> > > +     help
> > > +       Normally selected by platforms that process an FDT that has been
> > > +       passed to the kernel by the bootloader.  If the bootloader does not
> > > +       pass an FDT to the kernel and you need an empty devicetree that
> > > +       contains only a root node to exist, then say Y here.
> > >  
> > >  config OF_PROMTREE
> > >       bool
> [...]
> > > @@ -195,6 +191,17 @@ static inline int of_node_check_flag(const struct device_node *n, unsigned long
> > >       return test_bit(flag, &n->_flags);
> > >  }
> > >  
> > > +/**
> > > + * of_have_populated_dt() - Has DT been populated by bootloader
> > > + *
> > > + * Return: True if a DTB has been populated by the bootloader and it isn't the
> > > + * empty builtin one. False otherwise.
> > > + */
> > > +static inline bool of_have_populated_dt(void)
> > > +{
> > > +     return of_root != NULL && !of_node_check_flag(of_root, OF_EMPTY_ROOT);
> > 
> > Just a side comment, but I think many/all callers of this function could 
> > just be removed.
> > 
> > I don't love new flags. Another possible way to handle this would be 
> > checking for "compatible" being present in the root node. I guess this 
> > is fine as-is for now at least.
> 
> Ok. I can add a check for a compatible property. That's probably better
> anyway. Should there be a compatible property there to signal that this
> DT isn't compatible with anything? I worry about DT overlays injecting a
> compatible string into the root node, but maybe that is already
> prevented.

I worry about DT overlays injecting anything...

I don't think it is explicitly forbidden, but I have asked that any 
general purpose interface to apply overlays be restricted to nodes 
explicitly allowed (e.g. downstream of a connector node). For now, the 
places (i.e. drivers) overlays are applied are limited.

We could probably restrict the root node to new nodes only and no new 
or changed properties.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ