Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.