netdev - Re: wireless extensions vs. 64-bit architectures

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: <1173393326.3831.21.camel@johannes.berg>
Date:	Thu, 08 Mar 2007 23:35:26 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	jt@....hp.com
Cc:	Jouni Malinen <jkm@...icescape.com>, Michael Buesch <mb@...sch.de>,
	linux-wireless@...r.kernel.org, netdev <netdev@...r.kernel.org>,
	Jeff Garzik <jgarzik@...ox.com>, Dan Williams <dcbw@...hat.com>
Subject: Re: wireless extensions vs. 64-bit architectures

On Thu, 2007-03-08 at 14:11 -0800, Jean Tourrilhes wrote:

> 	First possiblity, we could stick with this band-aid
> permanently.

It sucks for various reasons, one for example being that I don't even
understand your recognition code but all userspace programs that use
wext will have to include such code!

> 	Second possiblity : we do the right thing and plan a API
> change to return struct always aligned on 32 bits. This way, when we
> get 128 bit processor, we don't have to add another band aid ;-)
> 	It would work like the ESSID changeover. We pick a WE version
> changeover. We introduce userspace that can deal with before and
> after. After 1 or 2 years, we flip the switch. After another 1 or 2
> years, we get rid of backward compatibility.

Probably doesn't make much sense, we might as well schedule wext for
removal by then and just make the effort to replace at least for all
IEEE 802.11 hardware. And then we rip out the compat ioctls completely
(just deny them) so if someone's stupid enough to use really really old
hw in new machines (where that even works) they need a 64-bit userspace.

> 	Third possibility : we declare 32 bit userspace on 64 bit
> kernel as not supported and advise users to get a 64 bit
> userspace. The number of bug report on that issue would suggest that
> very few users are in this case.

Randy is right here, most a lot of powerpc64 users don't bother
compiling 64-bit userspace apps since there's not much point in it.
Also, a lot of distros don't even distinguish between powerpc32 and
powerpc64 so debian for example can't possibly fix this by shipping
64-bit versions of the affected tools. Besides, a 64-bit network manager
couldn't integrate with gnome-panel I'd think.

The only real fix to me is fixing it in the kernel, but as you say
that's very icky.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)