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]

Message-ID: <CAGETcx81uPQLCurX6N6pMH+2jOZBcs-9u5yhBp83jQWJks0EFw@mail.gmail.com>
Date:   Fri, 17 Apr 2020 14:08:37 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
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, 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.

-Saravana