netdev - Re: [PATCH v1 net-next] lan743x: Provide Read/Write Access to on chip OTP

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: <20190121223345.GA23208@lunn.ch>
Date:   Mon, 21 Jan 2019 23:33:45 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Bryan.Whitehead@...rochip.com
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH v1 net-next] lan743x: Provide Read/Write Access to on
 chip OTP

> > This is breaking backwards compatibility. I think you need to respect the
> > magic value, independent of how adapter->flags.
> 
> Is backwards compatibility a requirement?

Hi Bryan

You should not change the ABI. And this is an ABI. So yes, backwards
compatibility should be maintained. Maybe there is a manufacturer out
there that has a script in their factory programming MAC addresses
into their devices using the current API. This change is going to
break their system. You really should be trying to avoid that.

> If so, this only breaks OTP backward compatibility, which was
> extremely restrictive and ultimately not very useful.

Was it sufficiently useful to actually program something into the OTP
to make the hardware work? If yes, somebody is probably using it. Or
is there some other way you expect a manufacturer to be programming
the OTP? Do you tell them the current API is horribly broken, don't
use it, always use JTAG?

You also need to think about the new ABI you are putting into
place. Is it really what you want? You cannot change it
afterwards. You need to support this forever.

	    Andrew