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]
Message-ID: <1399966237.4137.4.camel@jlt4.sipsolutions.net>
Date:	Tue, 13 May 2014 09:30:37 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Joe Perches <joe@...ches.com>
Cc:	Fabian Frederick <fabf@...net.be>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>,
	akpm <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/1] net/wireless/ibss.c: replace memcpy by
 ether_addr_copy

On Mon, 2014-05-12 at 12:17 -0700, Joe Perches wrote:

> > I certainly don't see the benefit in changing all those other files,
> > particularly since it's not just that we have to verify alignment *now*,
> > we also have to add alignment attributes so that we don't break
> > alignment in the future.
> 
> The same alignment requirements exist in quite a
> lot of the code so I don't see that as much of a
> continuing problem.

I disagree. This may be true for some of the cases we're discussing,
e.g. the change in net/wireless/util.c which has the assumption based on
frame alignment assumptions etc.

However, for things like the mac80211/mlme.c change we're operating
entirely on internal structures that are purely in software and don't
belong to any network frames or similar structs that already have
alignment guarantees.

As a consequence, something like this simple patch:

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5c7169b0ac57..fccbba2f4fe1 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1529,7 +1529,7 @@ struct cfg80211_bss {
 
 	u16 beacon_interval;
 	u16 capability;
-
+	u8 my_new_field;
 	u8 bssid[ETH_ALEN];
 
 	u8 priv[0] __aligned(sizeof(void *));

would already break at least one of the patches. The change looks
innocent enough, and is modifying a purely internal struct that doesn't
get used anywhere but the wireless stack (neither wire frame nor
userspace) so this is a perfectly valid change.

Therefore, the patch should mark the bssid with __aligned(2) or such, to
avoid having simple patches like that introduce problems.



> > Additionally doesn't even really save much typing:
> > 
> > memcpy(x, y, ETH_ALEN);
> > ether_addr_copy(x, y);
> 
> To me the general benefit isn't in the reduced
> source code size, but small improvements for
> ARM both in code size and execution speed.

Well, yes, but if it's in a configuration path, which you invoke maybe a
few times an hour, it doesn't seem worth it at all.

If it's in a frame/data hotpath, like the util.c change that already has
other alignment guarantees, it does seem somewhat worthwhile, but beyond
that I'm not so sure.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ