netdev - Re: Initializing MAC address at run-time

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]

Date:   Thu, 19 Jan 2017 17:26:52 +0100
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Mason <slash.tmp@...e.fr>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        DT <devicetree@...r.kernel.org>, netdev <netdev@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Kevin Hilman <khilman@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thibaud Cornic <thibaud_cornic@...madesigns.com>
Subject: Re: Initializing MAC address at run-time

Hello,

On Thu, Jan 19, 2017 at 04:31:56PM +0100, Mason wrote:
> Do you agree that such boot loader would execute code that is roughly
> identical to the one posted for illustration purposes?
>   1. find the MAC address to use for eth0
>   2. find the eth0 node in the DT
>   3. insert the right prop in the eth0 node

yes.
 
> In which case, it seems a waste to add the DT library to the boot
> loader, when the operation can be done in Linux, which requires the
> DT library anyway. (Additionally, adding DT support to some custom
> legacy boot loader might be a complex task.)

With this reasoning you can discuss away the bootloader. Linux relies on
a bootloader for a reason. It's there to initialize RAM and some further
things that Linux might not be able to and provide a machine description
to Linux (either in form of a dtb or an ATAG list) such that Linux
doesn't need to fiddle with machine specific stuff in early init code.

> >  c) Adapt the dtb before it is written to the boot medium.
> 
> This is not applicable, as the DTB is not written to the board.

Ah, then adapt the dtb before it is put into the tftp folder.

> >  d) Let the bootloader configure the device and teach the driver to pick
> >     up the mac from the device's address space.
> 
> I'm not sure what you call "the device" ?

The network device. IIRC the fec driver checks if there is something
configured in the two registers configuring the MAC before falling back
to a random MAC.

> >  e) Accept that the mac address is random during development, and make
> >     Userspace configure the MAC address, which is early enough for
> >     production use.
> 
> During development, some devs configure the DHCP server to provide
> a specific uImage and/or rootfs to their board, based on the MAC
> address. This scheme would fall apart with a random MAC.
> 
> > Not sure d) is considered ok today, but some drivers have this feature.
> > I'd say b) is the best choice.
> 
> In my mind, doing it early in Linux is similar in spirit to doing it
> at the boot loader stage, in that it's neatly separated from the rest
> of the setup.

Sure you can do this. But it won't be accepted mainline for sure.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |