linux-kernel - Re: [RFC PATCH 08/77] dtc: Introduce update_phandles

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260116122630.35d4fba3@bootlin.com>
Date: Fri, 16 Jan 2026 12:26:30 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: David Gibson <david@...son.dropbear.id.au>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Ayush Singh <ayush@...gleboard.org>,
 Geert Uytterhoeven <geert@...ux-m68k.org>,
 devicetree-compiler@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, devicetree-spec@...r.kernel.org, Hui Pu
 <hui.pu@...ealthcare.com>, Ian Ray <ian.ray@...ealthcare.com>, Luca
 Ceresoli <luca.ceresoli@...tlin.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: [RFC PATCH 08/77] dtc: Introduce update_phandles_ref()

On Thu, 15 Jan 2026 11:46:52 +1100
David Gibson <david@...son.dropbear.id.au> wrote:

> On Mon, Jan 12, 2026 at 03:18:58PM +0100, Herve Codina wrote:
> > With the introduction of FDT_REF_LOCAL dtb tag, a local phandle used
> > by a property is identify when a dtb is parsed.
> > 
> > In order to have consistent internal data, the reference related to this
> > phandle usage needs to be updated based on the phandle value.
> > 
> > This is done by update_phandles_ref().
> > 
> > Signed-off-by: Herve Codina <herve.codina@...tlin.com>
> > ---
> >  dtc.c      |  2 ++
> >  dtc.h      |  2 ++
> >  livetree.c | 38 ++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 42 insertions(+)
> > 
> > diff --git a/dtc.c b/dtc.c
> > index b3445b7..88f03ff 100644
> > --- a/dtc.c
> > +++ b/dtc.c
> > @@ -333,6 +333,8 @@ int main(int argc, char *argv[])
> >  		generate_fixups = 1;
> >  	}
> >  
> > +	update_phandles_ref(dti);
> > +
> >  	process_checks(force, dti);
> >  
> >  	if (auto_label_aliases)
> > diff --git a/dtc.h b/dtc.h
> > index 965321c..351fe41 100644
> > --- a/dtc.h
> > +++ b/dtc.h
> > @@ -345,6 +345,8 @@ void generate_label_tree(struct dt_info *dti, const char *name, bool allocph);
> >  void generate_fixups_tree(struct dt_info *dti, const char *name);
> >  void generate_local_fixups_tree(struct dt_info *dti, const char *name);
> >  
> > +void update_phandles_ref(struct dt_info *dti);
> > +
> >  /* Checks */
> >  
> >  void parse_checks_option(bool warn, bool error, const char *arg);
> > diff --git a/livetree.c b/livetree.c
> > index 9b67934..9e30a63 100644
> > --- a/livetree.c
> > +++ b/livetree.c
> > @@ -1158,3 +1158,41 @@ void generate_local_fixups_tree(struct dt_info *dti, const char *name)
> >  			"Warning: Preexisting data in %s malformed, some content could not be added.\n",
> >  			name);
> >  }
> > +
> > +static void update_phandles_ref_internal(struct dt_info *dti, struct node *node)
> > +{
> > +	struct node *c;
> > +	struct property *prop;
> > +	struct marker *m;
> > +	struct node *refnode;
> > +	cell_t phandle;
> > +
> > +	for_each_property(node, prop) {
> > +		m = prop->val.markers;
> > +		for_each_marker_of_type(m, REF_PHANDLE) {
> > +			if (m->ref)
> > +				continue;  
> 
> IIUC this means that REF_PHANDLE markers can be missing their ref.

Yes, no ref are present in dtb for phandle pointing to local node, only
the phandle value is present. We need at some point to set the ref from
this phandle value.

> Allowing the markers to be in an incomplete state is a footgun.  If
> possible it would be better to fully generate the markers when we
> create them.  If not, we should use a different marker type when it's
> introduced, and convert it later.
> 
> I think what's going on here is one type is saying "you have a
> reference, fill in the phandle", the other is saying "you have a
> phandle, fill in the reference".  Those seem like they should be
> different types to me, even if they can be converted once all the
> fixups are applied.

Right, I can introduce
- REF_PHANDLE_FILL_PHANDLE: "you have a phandle, fill in the reference"

- REF_PHANDLE_FILL_REF: "you have a reference, fill the phandle"
  Well, fill the phandle or not... Indeed, this reference can be external and
  so this can be an unresolved symbol.

But anyway those new marker types will exist only between the parsing step and
the step where we convert them to REF_PHANDLE markers.

Will see what I can propose in the next series iteration.

Best regards,
Hervé