[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170609130138.GA8257@bifrost>
Date: Fri, 9 Jun 2017 15:01:38 +0200
From: Anisse Astier <anisse@...ier.eu>
To: HacKurx <hackurx@...il.com>
Cc: Kees Cook <keescook@...omium.org>, Rik van Riel <riel@...hat.com>,
intrigeri <intrigeri@...m.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Patch for random mac address
On Fri, Jun 09, 2017 at 02:00:37PM +0200, HacKurx wrote:
> Le 26/05/2017 à 14:34, Anisse Astier a écrit :
> > You didn't answer my question regarding why this is different from the
> > function eth_random_addr.
> What do you think by replacing the whole by that?
>
> +#ifdef CONFIG_RANDOM_MAC_ADDRESS
> + /* randomize MAC whenever interface is brought up */
> + if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
> + struct sockaddr sa;
> + eth_random_addr(sa.sa_data);
> + sa.sa_family = dev->type;
> + dev_set_mac_address(dev, &sa);
Yes, I meant something like that.
>
> The network doesn't work with "eth_hw_addr_random(dev);" (the change of MAC addresses works well). Do you know why ?
I think that's because eth_hw_addr_random() is meant to be called by the
driver. Your solution is simpler, although it doesn't set
addr_assign_type to NET_ADDR_RANDOM, athough this field seems to be used
erratically (some use it as bitfield, but it does not look like one).
> Because the eth_hw_addr_randomfunction works better on all types of network cards.
You mean eth_random_addr, correct ?
Regards,
Anisse
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
