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:   Thu, 27 Oct 2022 19:47:05 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        UNGLinuxDriver@...rochip.com,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Colin Foster <colin.foster@...advantage.com>,
        Michael Walle <michael@...le.cc>,
        Heiko Thiery <heiko.thiery@...il.com>,
        Tobias Waldekranz <tobias@...dekranz.com>
Subject: Re: [PATCH net] net: dsa: fall back to default tagger if we can't
 load the one from DT



On 10/27/2022 7:54 AM, Vladimir Oltean wrote:
> DSA tagging protocol drivers can be changed at runtime through sysfs and
> at probe time through the device tree (support for the latter was added
> later).
> 
> When changing through sysfs, it is assumed that the module for the new
> tagging protocol was already loaded into the kernel (in fact this is
> only a concern for Ocelot/Felix switches, where we have tag_ocelot.ko
> and tag_ocelot_8021q.ko; for every other switch, the default and
> alternative protocols are compiled within the same .ko, so there is
> nothing for the user to load).
> 
> The kernel cannot currently call request_module(), because it has no way
> of constructing the modalias name of the tagging protocol driver
> ("dsa_tag-%d", where the number is one of DSA_TAG_PROTO_*_VALUE).
> The device tree only contains the string name of the tagging protocol
> ("ocelot-8021q"), and the only mapping between the string and the
> DSA_TAG_PROTO_OCELOT_8021Q_VALUE is present in tag_ocelot_8021q.ko.
> So this is a chicken-and-egg situation and dsa_core.ko has nothing based
> on which it can automatically request the insertion of the module.
> 
> As a consequence, if CONFIG_NET_DSA_TAG_OCELOT_8021Q is built as module,
> the switch will forever defer probing.
> 
> The long-term solution is to make DSA call request_module() somehow,
> but that probably needs some refactoring.
> 
> What we can do to keep operating with existing device tree blobs is to
> cancel the attempt to change the tagging protocol with the one specified
> there, and to remain operating with the default one. Depending on the
> situation, the default protocol might still allow some functionality
> (in the case of ocelot, it does), and it's better to have that than to
> fail to probe.
> 
> Fixes: deff710703d8 ("net: dsa: Allow default tag protocol to be overridden from DT")
> Link: https://lore.kernel.org/lkml/20221027113248.420216-1-michael@walle.cc/
> Reported-by: Heiko Thiery <heiko.thiery@...il.com>
> Reported-by: Michael Walle <michael@...le.cc>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
-- 
Florian

Powered by blists - more mailing lists