netdev - Re: [PATCH net-next] net: ieee802154: Fix compilation error when CONFIG_IEEE802154_NL802154

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, 1 Sep 2022 22:48:10 -0400
From:   Alexander Aring <aahringo@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Leon Romanovsky <leon@...nel.org>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        Alexander Aring <alex.aring@...il.com>,
        Gal Pressman <gal@...dia.com>,
        "David S. Miller" <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>
Subject: Re: [PATCH net-next] net: ieee802154: Fix compilation error when
 CONFIG_IEEE802154_NL802154_EXPERIMENTAL is disabled

Hi,

On Thu, Sep 1, 2022 at 4:23 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 1 Sep 2022 09:38:35 +0300 Leon Romanovsky wrote:
> > There is no such thing like experimental UAPI. Once you put something
> > in UAPI headers and/or allowed users to issue calls from userspace
> > to kernel, they can use it. We don't control how users compile their
> > kernels.
> >
> > So it is not break "experimental commands", but break commands that
> > maybe shouldn't exist in first place.
> >
> > nl802154 code suffers from two basic mistakes:
> > 1. User visible defines are not part of UAPI headers. For example,
> > include/net/nl802154.h should be in include/uapi/net/....
> > 2. Used Kconfig option for pseudo-UAPI header.
> >
> > In this specific case, I checked that Fedora didn't enable this
> > CONFIG_IEEE802154_NL802154_EXPERIMENTAL knob, but someone needs
> > to check debian and other distros too.
> >
> > Most likely it is not used at all.
>
> You're right, FWIW. I didn't want to get sidetracked into that before
> we fix the immediate build issue. It's not the only family playing uAPI
> games :(
>

I am not sure how to proceed here now, if removing the
CONFIG_IEEE802154_NL802154_EXPERIMENTAL option is the way to go. Then
do it?

It was a mistake to introduce that whole thing and a probably better
way is to change nl802154 is to mark it deprecated, after a while
rename the enum value to some reserved value and remove the associated
code. Then after some time it can be reused again? If this sounds like
a better idea how to handle the use case we have here?

I am sorry that this config currently causes such a big problem here.

- Alex