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: <CAL_Jsq+H0tLUJ+vWSkDHqjYdsAK2Rd3UCDEXv9uJ2v-ZR=XCAw@mail.gmail.com>
Date:   Thu, 1 Dec 2022 12:10:49 -0600
From:   Rob Herring <robh@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Andre Przywara <andre.przywara@....com>,
        Samuel Holland <samuel@...lland.org>
Cc:     Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        LABBE Corentin <clabbe.montjoie@...il.com>,
        Maxime Ripard <mripard@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...ts.linux.dev, netdev@...r.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: net: sun8i-emac: Fix snps,dwmac.yaml inheritance

On Wed, Nov 30, 2022 at 9:45 PM Rob Herring <robh@...nel.org> wrote:
>
> On Sat, Nov 26, 2022 at 03:48:33PM +0100, Krzysztof Kozlowski wrote:
> > On 26/11/2022 15:28, Andre Przywara wrote:
> > > On Sat, 26 Nov 2022 14:26:25 +0100
> > > Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> wrote:
> > >
> > > Hi,
> > >
> > >> On 25/11/2022 21:20, Samuel Holland wrote:
> > >>> The sun8i-emac binding extends snps,dwmac.yaml, and should accept all
> > >>> properties defined there, including "mdio", "resets", and "reset-names".
> > >>> However, validation currently fails for these properties because the
> > >>
> > >> validation does not fail:
> > >> make dt_binding_check -> no problems
> > >>
> > >> Maybe you meant that DTS do not pass dtbs_check?
> > >
> > > Yes, that's what he meant: If a board actually doesn't have Ethernet
> > > configured, dt-validate complains. I saw this before, but didn't find
> > > any solution.
> > > An example is: $ dt-validate ... sun50i-a64-pinephone-1.2.dtb
> > > arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dtb:
> > >   ethernet@...0000: Unevaluated properties are not allowed ('resets', 'reset-names', 'mdio' were unexpected)
> > >   From schema: Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
> > >
> > > Why exactly is beyond me, but this patch removes this message.
> >
> > I don't think this should be fixed like this. That's the problem of
> > dtschema (not ignoring fully disabled nodes) and such patch only moves
> > from one correct syntax to another correct syntax, which fixes dtschema
> > problem, but changes nothing here.
>
> Humm, it looks to me like the 'phy-mode' required in snps,dwmac.yaml
> causes the problem, but I can't get a minimized example to fail.
> Something in 'required' shouldn't matter. Definitely seems like an issue
> in the jsonschema package. I'll keep looking at it.

TLDR: A fix in dtschema for this will be in place soon.

I've simplified this down to:
{
    "$schema": "https://json-schema.org/draft/2019-09/schema",

    "unevaluatedProperties": false,
    "allOf":[
        {
            "properties": {
                "foo": true,
                "bar": true
            },
            "required": [ "foo" ]
        }
    ]
}

An instance { "bar": 1 } will fail due to the 'required' failing. When
you have a subschema (what's under 'allOf'), then it all has to pass
to be 'evaluated'. This seems inconsistent to me, but the json-schema
folks say it is operating as intended.

I've got 2 possible fixes. One is to just ignore unevaluatedProperties
errors on disabled nodes like is already done for 'required'. This
means disabled nodes can have any unknown property or child node added
which isn't great. The other way overrides 'required' validation to
always pass on disabled nodes. This would be better, but there are
some exceptions we need to still fail. 'oneOf' with N entries of
'required' to say 1 of N properties must be present for example.
Excluding each one of these cases will be fragile, so probably going
with the first fix.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ