linux-kernel - Re: [PATCH ethtool v1] netlink: add master/slave configuration support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20200609.130517.1373472507830142138.davem@davemloft.net>
Date:   Tue, 09 Jun 2020 13:05:17 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     keescook@...omium.org
Cc:     stephen@...workplumber.org, o.rempel@...gutronix.de,
        andrew@...n.ch, f.fainelli@...il.com, hkallweit1@...il.com,
        kuba@...nel.org, corbet@....net, mkubecek@...e.cz,
        linville@...driver.com, david@...tonic.nl, kernel@...gutronix.de,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        linux@...linux.org.uk, mkl@...gutronix.de, marex@...x.de,
        christian.herber@....com, amitc@...lanox.com, petrm@...lanox.com
Subject: Re: [PATCH ethtool v1] netlink: add master/slave configuration
 support

From: Kees Cook <keescook@...omium.org>
Date: Tue, 9 Jun 2020 12:49:48 -0700

> Okay, for now, how about:
> 
> - If we're dealing with an existing spec, match the language.

Yes.

> - If we're dealing with a new spec, ask the authors to fix their language.

Please be more specific about "new", if it's a passed and ratified standard
then to me it is "existing".

> - If a new version of a spec has updated its language, adjust the kernel's.

Unless you're willing to break UAPI, which I'm not, I don't see how this is
tenable.

> - If we're doing with something "internal" to the kernel (including UAPI),
>   stop adding new instances.

Even if it is part of supporting a technology where the standard uses
those terms?  So we'll use inconsitent terms internally?

This is why I'm saying, just make sure new specs use language that is
less controversial.  Then we just use what the specs use.

Then you don't have to figure out what to do about established UAPIs
and such, it's a non-issue.