linux-kernel - Re: [PATCH net-next v5 12/22] ethtool: provide string sets with GET

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, 28 Mar 2019 15:04:28 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Andrew Lunn <andrew@...n.ch>,
        John Linville <linville@...driver.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v5 12/22] ethtool: provide string sets with
 GET_STRSET request

On Thu, Mar 28, 2019 at 02:43:13PM +0100, Jiri Pirko wrote:
> 
> I don't like this. This should not be bitfield/set. This should be
> simply nested array of enum values:
> 
> enum ethtool_link_mode {
> 	ETHTOOL_LINK_MODE_10baseT_Half,
> 	ETHTOOL_LINK_MODE_10baseT_Full,
> 	ETHTOOL_LINK_MODE_100baseT_Half,
> 	ETHTOOL_LINK_MODE_100baseT_Full,
> 	ETHTOOL_LINK_MODE_1000baseT_Full,
> };

We already have such enum. The problem with your "no string" approach is
that it requires all userspace applications to (1) keep this enum in
sync with kernel and (2) maintain their our tables of names. Experience
shows we are not very good and satisfying these conditions even for the
one which should be best at keeping up.

> and then there should be 2 attrs:
> ETHTOOL_A_LINK_MODE_LIST_OUR	/* nest */
> ETHTOOL_A_LINK_MODE_LIST_PEER	/* nest */
> ETHTOOL_A_LINK_MODE		/* u32 */
> 
> and then the message should look like:
> 
>    ETHTOOL_A_LINK_MODE_LIST_OUR start nest
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_10baseT_Half
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_10baseT_Full
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_100baseT_Half
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_100baseT_Full
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_1000baseT_Full
>    ETHTOOL_A_LINK_MODE_LIST_OUR end nest
>    ETHTOOL_A_LINK_MODE_LIST_PEER start nest
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_10baseT_Half
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_10baseT_Full
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_100baseT_Half
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_100baseT_Full
>      ETHTOOL_A_LINK_MODE = ETHTOOL_LINK_MODE_1000baseT_Full
>    ETHTOOL_A_LINK_MODE_LIST_PEER end nest
> 
> Nice and simple. No bits, no strings.

A bit too simple, actually. You would need third nest to distinguish
supported and advertised modes. And for setting, you would also need two
arrays if you want to set only some of the modes (unless you introduce
something that would be similar to mine except for omitting the names).

More important: you still didn't explain how is your "no strings"
approach supposed to work for bit sets where userspace cannot possibly
know the set of available flags (e.g. the private flags).

Michal