linux-kernel - Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver

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: <1457553050.25961.197.camel@rtred1test09.kymeta.local>
Date:	Wed, 9 Mar 2016 19:50:07 +0000
From:	Trent Piepho <tpiepho@...etacorp.com>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
CC:	Andrey Smirnov <andrew.smirnov@...il.com>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>
Subject: Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver

On Wed, 2016-03-09 at 11:13 +0100, Maxime Ripard wrote:
> On Tue, Mar 08, 2016 at 11:24:33PM +0000, Trent Piepho wrote:
> > I think maybe the problem isn't here isn't clear.  For some boards
> > (mxs), only part of a MAC address is stored in nvmem while the rest of
> > the address is fixed data.  Currently embedded in the kernel source,
> > though embedded in the device tree would clearly be better.  While
> > splitting the MAC into two locations like this is not, at least in my
> > opinion, the best design, it's burned into the one time programmable
> > memory so there's not much that can be done.
> > 
> > The kernel looks for 'mac-address' and then 'local-mac-address', with
> > the former having precedence.
> > 
> > So what I did was embed the fixed portion in 'local-mac-address', have
> > the bootloader extract the variable part from nvmem, and then combine
> > the two and place it into 'mac-address' for the kernel to use.
> 
> I guess another solution would be to deal with that at the driver
> level. Read the 3 last bytes from the OTP, add the MAC prefix and give
> that to the net framework without looking it up in the DT. The MAC
> prefix could even be changed then through a kernel parameter, which is
> not possible currently.

How the data is stored in nvmem is specific to each board.  Some boards
use OTP, some use an external EEPROM.  The EEPROM could be on any of
multiple SPI or I2C buses and at different possible addresses.  The data
in OPT might be little-endian or big-endian or "written by someone who
doesn't understand byte order"-endian.

So the ethernet driver would need to deal with many different possible
board configurations.  And each ethernet driver would need to do that
all over again.

So the idea is to create a way that a single "DT binding for a MAC from
nvmem" driver could do the job for all boards and all ethernet drivers.
While there are many possibilities, a DT binding that covers all of them
doesn't need to be that complex.

> > My DT binding that described the placement of data from nvmem into the
> > MAC used a permutation list instead of a series of ranges.  So a list
> > like [0 0 0 1 2 3] could be used to specify the first three bytes of the
> > mac address do not come from nvmem.  This also allows changing byte
> > order concisely.  But doesn't scale well to larger regions.
> 
> Is your code / binding doc somewhere for reference ?

No, it was for a product that never upstreamed those changes :(.  It was
somewhat like the bindings that already exist in c6x/dscr.txt, for
ti,dscr-mac-fuse-regs.  I didn't support EEPROMs for that board, but
once extended to support that it would like something like:

&ethernet-device {
    mac-address   = [ab cd ef 00 00 00]; //already defined binding
    mac-nvmem     = <&otp 0x80 4>;  // these two are new bindings
    mac-nvmem-map = [0 0 0 1 2 3];
};

mac-nvmem = tuple of phandle, offset, length.  phandle is to a nvmem
device (OTP, eeprom, etc.).

mac-nvmem-map = list of bytes the length of a MAC address.  Each byte
indicates what byte from mac-nvmem (starting at 1, not 0) should go into
the corresponding position in the MAC.  0 means no byte from mac-nvmem
should be used for that position.

Thus [0 0 0 1 2 3] means the first three bytes of the mac do not come
from OTP and default to the existing value of mac-address.  The fourth
byte of the MAC should be the 1st byte from mac-nvmem, the fifth byte
shoud be the 2nd byte, and so on.

I believe this concisely handles all the possible cases of byte order,
EEPROMs, bytes in DT combined with bytes in OTP, etc. that I know of as
being used.

It doesn't attempt to be as powerful as Andrey's bindings.  E.g., it
doesn't scale to data much longer than a MAC address as the permutation
map list would become cumbersomely long.  It also doesn't support
combining data from more than two sources.