linux-kernel - Re: [PATCH v2 2/2] of: property: Do not link to disabled devices

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]

Date:   Sat, 18 Apr 2020 11:20:34 +0200
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] of: property: Do not link to disabled devices

On Fri, 2020-04-17 at 14:08 -0700, Saravana Kannan wrote:
> On Fri, Apr 17, 2020 at 9:54 AM Nicolas Saenz Julienne
> <nsaenzjulienne@...e.de> wrote:
> > When creating a consumer/supplier relationship between two devices,
> > make sure the supplier node is actually active. Otherwise this will
> > create a link relationship that will never be fulfilled. This, in the
> > worst case scenario, will hang the system during boot.
> > 
> > Note that, in practice, the fact that a device-tree represented
> > consumer/supplier relationship isn't fulfilled will not prevent devices
> > from successfully probing.
> > 
> > Fixes: a3e1d1a7f5fc ("of: property: Add functional dependency link from DT
> > bindings")
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
> > 
> > ---
> > 
> > Changes since v1:
> >  - Move availability check into the compatible search routine and bail
> >    if device node disabled
> > 
> >  drivers/of/property.c | 19 ++++++++++++++++++-
> >  1 file changed, 18 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > index dc034eb45defd..14b6266dd054b 100644
> > --- a/drivers/of/property.c
> > +++ b/drivers/of/property.c
> > @@ -1045,8 +1045,25 @@ static int of_link_to_phandle(struct device *dev,
> > struct device_node *sup_np,
> >          * Find the device node that contains the supplier phandle.  It may
> > be
> >          * @sup_np or it may be an ancestor of @sup_np.
> >          */
> > -       while (sup_np && !of_find_property(sup_np, "compatible", NULL))
> > +       while (sup_np) {
> > +
> > +               /*
> > +                * Don't allow linking a device node as consumer of a
> > disabled
> > +                * node.
> > +                */
> 
> Minor nit: I'd just say "Don't allow linking to a disabled supplier".
> 
> > +               if (!of_device_is_available(sup_np)) {
> > +                       dev_dbg(dev, "Not linking to %pOFP - Not
> > available\n",
> > +                               sup_np);
> > +                       of_node_put(sup_np);
> > +                       return -ENODEV;
> > +               }
> 
> This if block looks very similar to the one right after the loop.
> Maybe there's a nice way to combine it?
> 
> If you replace this if block with this, it'll end up with the same result.
> if (!of_device_is_available(sup_np)) {
>         of_node_put(sup_np);
>         sup_np = NULL;
> }
> 
> of_get_next_parent() handles a NULL input properly. So that won't be a
> problem. And "No device" is a valid statement for both cases I think.
> 
> > +
> > +               if (of_find_property(sup_np, "compatible", NULL))
> > +                       break;
> > +
> >                 sup_np = of_get_next_parent(sup_np);
> > +       }
> > +
> >         if (!sup_np) {
> >                 dev_dbg(dev, "Not linking to %pOFP - No device\n", tmp_np);
> >                 return -ENODEV;
> 
> However, not against this patch as is if Rob/Frank like it as is.

Agree with your suggestions, I'll send an v3.

Regards,
Nicolas


Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)