[EXT] Re: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR

[Kostya Porotchkin]

Hello,

> -----Original Message-----
> From: Dennis Gilmore <dgilmore at fedoraproject.org>
> Sent: Friday, September 11, 2020 20:16
> To: Tom Rini <trini at konsulko.com>
> Cc: Andre Heider <a.heider at gmail.com>; Marek Behún
> <marek.behun at nic.cz>; Pali Rohár <pali at kernel.org>; Stefan Roese
> <sr at denx.de>; Kostya Porotchkin <kostap at marvell.com>; U-Boot Mailing
> List <u-boot at lists.denx.de>
> Subject: [EXT] Re: [PATCH] defconfig: espressobin: enable
> NET_RANDOM_ETHADDR
> 
> External Email
> 
> ----------------------------------------------------------------------
> I agree with Tom here, I have a few different systems that use this feature, it
> is useful. I think most if not all of the systems I have using it have Marvell
> SoC's
> 
> Dennis
> 
> On Fri, Sep 11, 2020 at 12:11 PM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Sep 11, 2020 at 06:47:02PM +0200, Andre Heider wrote:
> > > On 11/09/2020 18:22, Marek Behún wrote:
> > > > On Fri, 11 Sep 2020 17:52:26 +0200 Andre Heider
> > > > <a.heider at gmail.com> wrote:
> > > >
> > > > > Hi Marek,
> > > > >
> > > > > On 11/09/2020 13:55, Marek Behún wrote:
> > > > > > On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár <pali at kernel.org>
> > > > > > wrote:
> > > > > > > On Tuesday 08 September 2020 08:52:56 Tom Rini wrote:
> > > > > > > > Note that when CONFIG_NET_RANDOM_ETHADDR is set, we
> only
> > > > > > > > use a random MAC address when we haven't found one either
> > > > > > > > on the hardware or environment.
> > > > > > >
> > > > > > > I know.
> > > > > > > > It also prints a warning that you are using a random MAC,
> > > > > > > > so if it's documented on how to recover the real MAC a
> > > > > > > > user should see that warning and fix it.
> > > > > > >
> > > > > > > In case you did backup of MAC address or you have MAC
> > > > > > > address printed on sticker, you can restore it. If you
> > > > > > > loaded distribution U-Boot which erase MAC address and you
> > > > > > > have not did any backup, then your MAC address is forever lost.
> > > > > >
> > > > > > On Turris MOX we write the MAC address into OTP of the SOC
> > > > > > during manufacturing.
> > > > > >
> > > > > > It is possible to write code that burns the MAC address into
> > > > > > OTP, I consider this a better option than enabling random MAC
> address.
> > > > > >
> > > > > > Maybe we can enable random MAC address, and if MAC address is
> > > > > > not found in environment nor OTP, issue a warning, something like
> > > > > >     "WARNING: MAC address lost, please burn the MAC address of
> > > > > > your device to OTP with command xyz"
> > > > > >
> > > > > > What do you think?
> > > > >
> > > > > if there's a mac stored in otp during manufacturing, that's of
> > > > > course the best solution. There's no need for
> > > > > CONFIG_NET_RANDOM_ETHADDR then. But globalscale does not do
> that.
> > > > >
> > > > > Doing it afterwards, so u-boot claiming some otp space for
> > > > > itself, and instructing the user how to write to it sounds too
> > > > > dangerous/error-prone.
> > > > >
> > > > > For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be
> > > > > enabled if there's no mac address stored in a sane way (where
> > > > > saving it just to an u-boot env during manufacturing doesn't
> > > > > count as sane, especially if the vendor moves the spi env offset
> around in a firmware update).
> > > > >
> > > > > So I think CONFIG_NET_RANDOM_ETHADDR is enough.
> > > > >
> > > >
> > > > I understand Pali's concerns, though.
> > > >
> > > > The thing is that if we enable CONFIG_NET_RANDOM_ETHADDR by
> > > > default, many users that have managed to wipe their env won't care
> > > > about that they are using randomly generated MAC address and won't
> > > > solve the issue, which is again the spirit of correctly configure networks.
> > > >
> > > > If we do not enable CONFIG_NET_RANDOM_ETHADDR, the worst that
> can
> > > > happen is that the device won't boot from network. This will force
> > > > the users to solve the issue, which is not that hard
> > > >    setenv ethaddr aa:bb:cc:dd:ee:ff (address from the sticker)
> > > >    saveenv
> > > > If the users boots from SD/eMMC/SATA/USB, Linux won't have
> problem
> > > > with network, since it will generate random MAC address anyway.
> > >
> > > Good point, so let's assume the user doesn't have a mac stored.
> > >
> > > Without CONFIG_NET_RANDOM_ETHADDR:
> > > * u-boot refuses to do anything network related
> > > * Linux generates a random mac, network works
> > >
> > > With CONFIG_NET_RANDOM_ETHADDR:
> > > * u-boot generates a random mac, network works
> > > * Linux uses the same random mac, passed on from u-boot throught the
> > > device-tree, network works
> > >
> > > It's still random, but at least it's consistent ;)
> >
> > It's also only used when we cannot find the MAC.  At the end of the
> > day, the final decision here is Konstantin's (as the listed
> > maintainer).  I personally think enabling the option is good given the
> > apparent number of ways the real MAC will have been lost from SW, but
> > if the maintainer wants to instead opt for a verbose failure message, that's
> fine too.
I have no objections about this configuration option. 
It is better to have a random MAC address rather then no MAC at all.

Regards
Kosta
> >
> > --
> > Tom