netdev - Re: [PATCH net-next v2 7/7] netlink: specs: wireless: add a spec for nl80211

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: <CAD4GDZz3xSyA2zJcs-wbZa4yD-ZT90PeOLFReOcr286-nycA6g@mail.gmail.com>
Date: Wed, 18 Dec 2024 14:32:17 +0000
From: Donald Hunter <donald.hunter@...il.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, linux-wireless@...r.kernel.org, 
	donald.hunter@...hat.com
Subject: Re: [PATCH net-next v2 7/7] netlink: specs: wireless: add a spec for nl80211

On Thu, 12 Dec 2024 at 08:36, Johannes Berg <johannes@...solutions.net> wrote:
>
> On Tue, 2024-12-10 at 16:14 +0000, Donald Hunter wrote:
> >
> > +  -
> > +    name: wlan-cipher-suites
> > +    type: enum
>
> I'm not sure exactly what this does, but I'm not sure 'enum' is the
> right way to think about it. Pretty much every number (OUI + subvalue)
> could be valid here, if the driver advertises support for it and you
> have a supplicant that understands it.

It was an attempt to enumerate the valid values, but from what you are
saying I think it will need to remain as u32, probably with
'display-hint: hex".

> > +  -
> > +    name: wiphy-bands
> > +    attributes:
> > +      -
> > +        name: 2ghz
> > +        doc: 2.4 GHz ISM band
> > +        value: 0
> > +        type: nest
> > +        nested-attributes: band-attrs
> > +      -
> > +        name: 5ghz
> > +        doc: around 5 GHz band (4.9 - 5.7 GHz)
> > +        type: nest
> > +        nested-attributes: band-attrs
> > +      -
> > +        name: 60ghz
> > +        doc: around 60 GHz band (58.32 - 69.12 GHz)
> > +        type: binary
>
> This (and s1g/lc) should also nest, with the same attributes? There
> should be no structural difference between the bands, even if most of
> the values are only used/valid for some of the bands.

That makes sense. I'll add the nest type to them all.

> > +operations:
> > +  enum-model: directional
> > +  list:
> > +    -
> > +      name: get-wiphy
> > +      doc: |
> > +        Get information about a wiphy or dump a list of all wiphys. Requests to dump get-wiphy
> > +        should unconditionally include the split-wiphy-dump flag in the request.
> > +      attribute-set: nl80211-attrs
> > +      do:
> > +        request:
> > +          value: 1
> > +          attributes:
> > +            - wiphy
> > +            - wdev
> > +            - ifindex
> > +        reply:
> > +          value: 3
>
> could the value not reference "get-wiphy" and "new-wiphy" from the
> command list? That might be easier to understand?

There is currently no schema or tool support for referencing enum
constants when defining protocol message ids. Most of the netlink
families don't have any need for an enumeration of commands in the
spec; nl80211 is unusual in reporting available commands.

I'm currently working on completeness of nl80211 and a couple of
feature gaps in ynl-gen-c.py to resolve 'make -C tools/net/ynl'
failures. I doubt that I will have a v3 patchset ready before net-next
closes for the holidays.

Thanks,
Donald.