netdev - Re: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead of speed and duplex parameters

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: <20210201134156.14693076@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 1 Feb 2021 13:41:56 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Edwin Peer <edwin.peer@...adcom.com>
Cc:     Danielle Ratson <danieller@...dia.com>,
        Michal Kubecek <mkubecek@...e.cz>,
        netdev <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...dia.com>, Andrew Lunn <andrew@...n.ch>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        mlxsw <mlxsw@...dia.com>, Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead
 of speed and duplex parameters

On Mon, 1 Feb 2021 13:05:10 -0800 Edwin Peer wrote:
> On Mon, Feb 1, 2021 at 12:29 PM Jakub Kicinski <kuba@...nel.org> wrote:
> 
> > > I think it should be deterministic. It should be possible to select
> > > the appropriate mode either based on the current media type or the
> > > current link mode (which implies a media type). Alternatively, if the
> > > user space request only specifies a subset, such as speed, fall back
> > > to the existing behaviour and don't supply the request to the driver
> > > in the form of a compound link mode in those cases (perhaps indicating
> > > this by not setting the capability bit). The former approach has the
> > > potential to tidy up drivers if we decide that drivers providing the
> > > capability can ignore the other fields and rely solely on link mode,
> > > the latter is no worse than what we have today.  
> >
> > The media part is beginning to sound concerning. Every time we
> > under-specify an interface we end up with #vendors different
> > interpretations. And since HW is programmed by FW in most high
> > speed devices we can't even review the right thing is done.  
> 
> Each link mode implies a very specific media type, the kernel can
> reject illegal combinations based on the supported bitmask before
> calling upon the driver to select it.

Are you talking about validation against a driver-supplied list of
HW-supported modes, or SFP-supported modes for a currently plugged 
in module?

If I'm reading prior responses right it is the former.

The concern is around "what happens if user selected nnG-SR4 but user
plugged in nnG-CR4". The MAC/PHY/serdes settings will be identical.