netdev - Re: [PATCH v3 3/8] net: phy: Add BaseT1 auto-negotiation registers

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] [day] [month] [year] [list]

Message-ID: <20211124152453.21123-1-alexandru.tachici@analog.com>
Date:   Wed, 24 Nov 2021 17:24:53 +0200
From:   <alexandru.tachici@...log.com>
To:     <o.rempel@...gutronix.de>
CC:     <alexandru.tachici@...log.com>, <andrew@...n.ch>,
        <davem@...emloft.net>, <devicetree@...r.kernel.org>,
        <hkallweit1@...il.com>, <kuba@...nel.org>,
        <linux-kernel@...r.kernel.org>, <linux@...linux.org.uk>,
        <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 3/8] net: phy: Add BaseT1 auto-negotiation registers

> Hm.. MDIO_AN_T1_ADV_M_MST is T4 of Link codeword Base Page. The spec says:
> "Transmitted Nonce Field (T[4:0]) is a 5-bit wide field whose lower 4
> bits contains a random or pseudorandom number. A new value shall be
> generated for each entry to the Ability Detect state"
>
> Should we actually do it?

Managed to get some answears from the HW team:

Bits 7.515.3:0 correspond to the lower 4 bits of the Transmitted Nonce Field. We do not allow users to write these bits as they need to be controlled by the auto-negotiation (AN) sequencers in order to ensure that AN remains robust and reliable. However, the Transmitted Nonce value is readable via register 7.515. So we could call these bits out in the documentation and indicate that they are readonly.

Bottom line is that the driver cannot and should not do anything with the lower 4 Transmitted Nonce bits. The PHY controls them.

Also from 802.3 98.2.1.2.3 Transmitted Nonce Field:
If the device has received a DME page with good CRC16 and the link partner has a Transmitted Nonce Field
(T[4:0]) that matches the devices generated T[4:0], the device shall invert its T[0] bit and regenerate a new
random value for T[3:1] and use that as its new T[4:0] value. Since the DME pages are exchanged in a halfduplex manner, it is possible to swap to a new T[4:0] value prior to transmitting the DME page. One device
will always see a DME page with good CRC16 before the other device hence this swapping will guarantee
that nonce_match will never be true.

Seems that there must be hardware to deal with nonce collisions.

Regards,
Alexandru