netdev - Re: [PATCH] ibmveth: Fix more little endian issues

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: <1387967908.26981.0.camel@deadeye.wl.decadent.org.uk>
Date:	Wed, 25 Dec 2013 10:38:28 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Anton Blanchard <anton@...ba.org>
CC:	Joe Perches <joe@...ches.com>, Alexander Graf <agraf@...e.de>,
	<linuxppc-dev@...ts.ozlabs.org>,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	Dinar Valeev <dvaleev@...e.com>,
	Santiago Leon <santil@...ux.vnet.ibm.com>,
	<netdev@...r.kernel.org>
Subject: Re: [PATCH] ibmveth: Fix more little endian issues


On Tue, 2013-12-24 at 12:55 +1100, Anton Blanchard wrote:
> The hypervisor expects MAC addresses passed in registers to be big
> endian u64. Create a helper function called ibmveth_encode_mac_addr
> which does the right thing in both big and little endian.
> 
> We were storing the MAC address in a long in struct ibmveth_adapter.
> It's never used so remove it - we don't need another place in the
> driver where we create endian issues with MAC addresses.
[...]
> @@ -523,10 +523,20 @@ retry:
>  	return rc;
>  }
>  
> +/* The hypervisor expects MAC addresses passed in registers to be
> + * big endian u64.
> + */
> +static __be64 ibmveth_encode_mac_addr(char *mac)
> +{
> +	unsigned long encoded = 0;

u64

> +	memcpy(((char *)&encoded) + 2, mac, ETH_ALEN);
> +	return cpu_to_be64(encoded);
> +}
[...]

So on big-endian systems the byte order of the result will be:

    0 0 mac0 mac1 mac2 mac3 mac4 mac5

and on little-endian systems it's:

    mac5 mac4 mac3 mac2 mac1 mac0 0 0

It seems to me that 'encoded' is actually in big-endian order and this
function returns the address in CPU order.

So are you sure your explanation isn't backwards, because it looks to me
like the driver was already holding the MAC address in big-endian order
and perhaps the hypercall mechanism does a byte-swap when the guest is
little-endian.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html