Re: [PATCH 2.4] Wireless Extension v17 (resend)
* Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
> On Tue, Feb 08, 2005 at 05:51:29PM -0800, Chris Wright wrote:
> > Hmm, having ability to read kernel data is not so nice.
>
> It's not like you can read any arbitrary address, exploiting
> such a flaw is in my mind theoritical. Let's not overblow things,
> there are some real bugs to take care of.
If the fix is simple (as it appears to be), there's no good reason to
leave the risk there.
> > prism54 uses
> > this, and is a reasonably popular card. Looks to me like this should be
> > plugged. Is the patch below sufficient? (stolen from full 2.6 patch)
>
> Yep, except that you have an extra chunk that should not be
> in. You probably did not use the latest version of the patch (and that
> was not in the one sent to Marcelo). I would not like to introduce a
> real bug in 2.4.X :-(
Yes, you are correct, here it is without that errouneous bit.
thanks,
-chris
= net/core/wireless.c 1.4 vs edited =
--- 1.4/net/core/wireless.c 2003-09-03 04:12:57 -07:00
+++ edited/net/core/wireless.c 2005-02-08 17:45:15 -08:00
@@ -310,7 +310,7 @@ static inline int call_commit_handler(st
/* */
/*
- * Number of private arguments
+ * Calculate size of private arguments
*/
static inline int get_priv_size(__u16 args)
{
@@ -320,6 +320,24 @@ static inline int get_priv_size(__u16 ar
return num * priv_type_size[type];
}
+/* */
+/*
+ * Re-calculate the size of private arguments
+ */
+static inline int adjust_priv_size(__u16 args,
+ union iwreq_data * wrqu)
+{
+ int num = wrqu->data.length;
+ int max = args & IW_PRIV_SIZE_MASK;
+ int type = (args & IW_PRIV_TYPE_MASK) >> 12;
+
+ /* Make sure the driver doesn't goof up */
+ if (max < num)
+ num = max;
+
+ return num * priv_type_size[type];
+}
+
/ /proc/net/wireless SUPPORT /
/*
@@ -701,7 +719,7 @@ static inline int ioctl_private_call(str
((extra_size + offset) <= IFNAMSIZ))
extra_size = 0;
} else {
- /* Size of set arguments */
+ /* Size of get arguments */
extra_size = get_priv_size(descr->get_args);
/* Does it fits in iwr ? */
@@ -771,6 +789,14 @@ static inline int ioctl_private_call(str
/* If we have something to return to the user */
if (!ret && IW_IS_GET(cmd)) {
+
+ /* Adjust for the actual length if it's variable,
+* avoid leaking kernel bits outside. */
+ if (!(descr->get_args & IW_PRIV_SIZE_FIXED)) {
+ extra_size = adjust_priv_size(descr->get_args,
+ &(iwr->u));
+ }
+
err = copy_to_user(iwr->u.data.pointer, extra,
extra_size);
if (err)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 05:51:29PM -0800, Chris Wright wrote:
> * Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
> > The first is the handling of spyoffset which is potentially
> > unsafe. Unfortunately, the fix involve some API/infrastructure change,
> > so is not transparent. Fortunately drivers are clever enough to not
> > trigger this bug.
> > The second is a potential leak of kernel data to user space in
> > private handler handling. Few drivers use that feature, there is no
> > risk of crash or direct attack, so I would not worry about it.
>
> Hmm, having ability to read kernel data is not so nice.
It's not like you can read any arbitrary address, exploiting
such a flaw is in my mind theoritical. Let's not overblow things,
there are some real bugs to take care of.
> prism54 uses
> this, and is a reasonably popular card. Looks to me like this should be
> plugged. Is the patch below sufficient? (stolen from full 2.6 patch)
Yep, except that you have an extra chunk that should not be
in. You probably did not use the latest version of the patch (and that
was not in the one sent to Marcelo). I would not like to introduce a
real bug in 2.4.X :-(
> thanks,
> -chris
This chunk is erroneous :
> @@ -731,7 +749,7 @@ static inline int ioctl_private_call(str
> return -EFAULT;
>
> /* Does it fits within bounds ? */
> - if(iwr->u.data.length > (descr->set_args &
> + if(iwr->u.data.length > (descr->get_args &
>IW_PRIV_SIZE_MASK))
> return -E2BIG;
> } else {
Have fun...
Jean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 08:09:04PM -0500, kernel wrote: > On Tue, 2005-02-08 at 13:41, Marcelo Tosatti wrote: > > > There need to be some unique features in 2.6.X to force people > > > to upgrade, I guess... > > > > Faster, cleaner, way more elegant, handles intense loads more gracefully, > > handles highmem decently, LSM/SELinux, etc, etc... > > > > Please *think* before saying this. It's not always the case. Firewire > support in 2.6 kernel has been less than stellar, for one example. And > yes, for many, solid 1394 support is a requirement for business. Well, if it has problems, like every piece of software is expected to have, then it should be fixed. We all should invest our efforts in having v2.6 the most stable kernel as possible. I'm sure Ben Collins (1394 maintainer) will appreciate 1394 bug reports and he will do his best at fixing them. > (And we've all seen the testing that has shown both sides (2.4, 2.6) > have been faster) > > > IMO everyone should upgrade whenever appropriate. > > > > Not sureon 13 January 2005 Alan Cox posted "Given that base 2.6 > kernels are shipped by Linus with known unfixed > security holes anyone trying to use them really should be doing some > careful thinking. In truth no 2.6 released kernel is suitable for > anything but beta testing until you add a few patches anyway." Alan means that _mainline_ v2.6 kernel might not be as polished as distribution kernels. He does not mean, at all, that individuals should not upgrade to v2.6 based kernels. Note his "until you add a few patches anyway". > How do you answer this, when telling folks "everyone should upgrade > whenever appropriate."? Please realize that pretty much all development efforts have been centered at the v2.6 kernel, and that means a lot. > Just some random thoughtsfrom a 2.4 supporter :) :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
* Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
> The first is the handling of spyoffset which is potentially
> unsafe. Unfortunately, the fix involve some API/infrastructure change,
> so is not transparent. Fortunately drivers are clever enough to not
> trigger this bug.
> The second is a potential leak of kernel data to user space in
> private handler handling. Few drivers use that feature, there is no
> risk of crash or direct attack, so I would not worry about it.
Hmm, having ability to read kernel data is not so nice. prism54 uses
this, and is a reasonably popular card. Looks to me like this should be
plugged. Is the patch below sufficient? (stolen from full 2.6 patch)
thanks,
-chris
= net/core/wireless.c 1.4 vs edited =
--- 1.4/net/core/wireless.c 2003-09-03 04:12:57 -07:00
+++ edited/net/core/wireless.c 2005-02-08 17:45:15 -08:00
@@ -310,7 +310,7 @@ static inline int call_commit_handler(st
/* */
/*
- * Number of private arguments
+ * Calculate size of private arguments
*/
static inline int get_priv_size(__u16 args)
{
@@ -320,6 +320,24 @@ static inline int get_priv_size(__u16 ar
return num * priv_type_size[type];
}
+/* */
+/*
+ * Re-calculate the size of private arguments
+ */
+static inline int adjust_priv_size(__u16 args,
+ union iwreq_data * wrqu)
+{
+ int num = wrqu->data.length;
+ int max = args & IW_PRIV_SIZE_MASK;
+ int type = (args & IW_PRIV_TYPE_MASK) >> 12;
+
+ /* Make sure the driver doesn't goof up */
+ if (max < num)
+ num = max;
+
+ return num * priv_type_size[type];
+}
+
/ /proc/net/wireless SUPPORT /
/*
@@ -701,7 +719,7 @@ static inline int ioctl_private_call(str
((extra_size + offset) <= IFNAMSIZ))
extra_size = 0;
} else {
- /* Size of set arguments */
+ /* Size of get arguments */
extra_size = get_priv_size(descr->get_args);
/* Does it fits in iwr ? */
@@ -731,7 +749,7 @@ static inline int ioctl_private_call(str
return -EFAULT;
/* Does it fits within bounds ? */
- if(iwr->u.data.length > (descr->set_args &
+ if(iwr->u.data.length > (descr->get_args &
IW_PRIV_SIZE_MASK))
return -E2BIG;
} else {
@@ -771,6 +789,14 @@ static inline int ioctl_private_call(str
/* If we have something to return to the user */
if (!ret && IW_IS_GET(cmd)) {
+
+ /* Adjust for the actual length if it's variable,
+* avoid leaking kernel bits outside. */
+ if (!(descr->get_args & IW_PRIV_SIZE_FIXED)) {
+ extra_size = adjust_priv_size(descr->get_args,
+ &(iwr->u));
+ }
+
err = copy_to_user(iwr->u.data.pointer, extra,
extra_size);
if (err)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
Message below meant for Marcelo! (sorry rest!) On Tue, 2005-02-08 at 20:09, kernel wrote: > On Tue, 2005-02-08 at 13:41, Marcelo Tosatti wrote: > > > There need to be some unique features in 2.6.X to force people > > > to upgrade, I guess... > > > > Faster, cleaner, way more elegant, handles intense loads more gracefully, > > handles highmem decently, LSM/SELinux, etc, etc... > > > > Please *think* before saying this. It's not always the case. Firewire > support in 2.6 kernel has been less than stellar, for one example. And > yes, for many, solid 1394 support is a requirement for business. > > (And we've all seen the testing that has shown both sides (2.4, 2.6) > have been faster) > > > IMO everyone should upgrade whenever appropriate. > > > > Not sureon 13 January 2005 Alan Cox posted "Given that base 2.6 > kernels are shipped by Linus with known unfixed > security holes anyone trying to use them really should be doing some > careful thinking. In truth no 2.6 released kernel is suitable for > anything but beta testing until you add a few patches anyway." > > How do you answer this, when telling folks "everyone should upgrade > whenever appropriate."? > > > Just some random thoughtsfrom a 2.4 supporter :) > > -fd > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, 2005-02-08 at 13:41, Marcelo Tosatti wrote: > > There need to be some unique features in 2.6.X to force people > > to upgrade, I guess... > > Faster, cleaner, way more elegant, handles intense loads more gracefully, > handles highmem decently, LSM/SELinux, etc, etc... > Please *think* before saying this. It's not always the case. Firewire support in 2.6 kernel has been less than stellar, for one example. And yes, for many, solid 1394 support is a requirement for business. (And we've all seen the testing that has shown both sides (2.4, 2.6) have been faster) > IMO everyone should upgrade whenever appropriate. > Not sureon 13 January 2005 Alan Cox posted "Given that base 2.6 kernels are shipped by Linus with known unfixed security holes anyone trying to use them really should be doing some careful thinking. In truth no 2.6 released kernel is suitable for anything but beta testing until you add a few patches anyway." How do you answer this, when telling folks "everyone should upgrade whenever appropriate."? Just some random thoughtsfrom a 2.4 supporter :) -fd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote: > On Tue, Feb 08, 2005 at 01:51:12PM -0800, Jean Tourrilhes wrote: > > > > You are right, it's not critical, and I was already thinking > > of not pushing WE-18 to you (the WPA update). I'll stop updating 2.4.X > > with respect to wireless, the patches will be available on my web page > > for people who needs it. > > Please dont miss bugfixes for present functionality. Gracias. Depend what you call "bugfix". Fortunately, with the long beta period I do with the WE, bugs are few. There are only two "bugs" in WE-16 I'm aware off (fixed in WE-17), but I don't think they are worth fixing. The first is the handling of spyoffset which is potentially unsafe. Unfortunately, the fix involve some API/infrastructure change, so is not transparent. Fortunately drivers are clever enough to not trigger this bug. The second is a potential leak of kernel data to user space in private handler handling. Few drivers use that feature, there is no risk of crash or direct attack, so I would not worry about it. > Faster, cleaner, way more elegant, handles intense loads more gracefully, > handles highmem decently, LSM/SELinux, etc, etc... > > IMO everyone should upgrade whenever appropriate. If people want to use 2.4.X, I won't prevent them... Have fun... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 11:45:31PM +0100, Willy Tarreau wrote: > Hi Marcelo, > > On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote: > > > > > > There need to be some unique features in 2.6.X to force people > > > to upgrade, I guess... > > > > Faster, cleaner, way more elegant, handles intense loads more gracefully, > > When a CPU-hungry task freezes another one for more than 13 seconds, I cannot > agree with your last statement, and that's why I still don't upgrade. I have > already posted examples of worst case scenarios, but I now start to have a > more meaningful example to show so that people working on the scheduler may > have something clearer to work with. I also did not have time to retest -ck > or staircase recently, but I will do for completeness. v2.6 scheduler regressions cannot be tolerated. Please prepare more detailed data about your problem - I'm sure Ingo and friends will appreciate it. > > handles highmem decently, LSM/SELinux, etc, etc... > > > > IMO everyone should upgrade whenever appropriate. > > I still know about a tens of 2.2 still running around at customers ;-) > However, if it had not been for lazyness, they should have upgraded. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
Hi Marcelo, On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote: > > > > There need to be some unique features in 2.6.X to force people > > to upgrade, I guess... > > Faster, cleaner, way more elegant, handles intense loads more gracefully, When a CPU-hungry task freezes another one for more than 13 seconds, I cannot agree with your last statement, and that's why I still don't upgrade. I have already posted examples of worst case scenarios, but I now start to have a more meaningful example to show so that people working on the scheduler may have something clearer to work with. I also did not have time to retest -ck or staircase recently, but I will do for completeness. > handles highmem decently, LSM/SELinux, etc, etc... > > IMO everyone should upgrade whenever appropriate. I still know about a tens of 2.2 still running around at customers ;-) However, if it had not been for lazyness, they should have upgraded. Cheers, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 01:51:12PM -0800, Jean Tourrilhes wrote: > On Tue, Feb 08, 2005 at 04:01:16PM -0200, Marcelo Tosatti wrote: > > > > Hi Jean, > > > > I'm very ignorant about wireless but it doesnt appear to me that "Wireless > > Extension v17" > > is a critical feature. > > You are right, it's not critical, and I was already thinking > of not pushing WE-18 to you (the WPA update). I'll stop updating 2.4.X > with respect to wireless, the patches will be available on my web page > for people who needs it. Please dont miss bugfixes for present functionality. Gracias. > We may revisit this if there is a public > outcry... OK! > > It seems more appropriate to declare it as 2.6 functionality ? > > There need to be some unique features in 2.6.X to force people > to upgrade, I guess... Faster, cleaner, way more elegant, handles intense loads more gracefully, handles highmem decently, LSM/SELinux, etc, etc... IMO everyone should upgrade whenever appropriate. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 04:01:16PM -0200, Marcelo Tosatti wrote: > > Hi Jean, > > I'm very ignorant about wireless but it doesnt appear to me that "Wireless > Extension v17" > is a critical feature. You are right, it's not critical, and I was already thinking of not pushing WE-18 to you (the WPA update). I'll stop updating 2.4.X with respect to wireless, the patches will be available on my web page for people who needs it. We may revisit this if there is a public outcry... > It seems more appropriate to declare it as 2.6 functionality ? There need to be some unique features in 2.6.X to force people to upgrade, I guess... > Cheers Thanks. Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
Hi Jean, I'm very ignorant about wireless but it doesnt appear to me that "Wireless Extension v17" is a critical feature. It seems more appropriate to declare it as 2.6 functionality ? Cheers On Tue, Feb 08, 2005 at 10:16:37AM -0800, Jean Tourrilhes wrote: > Hi Marcelo, > > I did not receive any feedback on this e-mail either, so I > assume it was also lost on the way. Would you mind pushing that in > 2.4.x ? > Thanks... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.4] Wireless Extension v17 (resend)
Hi Marcelo, I did not receive any feedback on this e-mail either, so I assume it was also lost on the way. Would you mind pushing that in 2.4.x ? Thanks... Jean - Forwarded message from jt - Subject: [PATCH 2.4] Wireless Extension v17 E-mail: [EMAIL PROTECTED] Hi Marcelo, This patch adds Wireless Extensions v17 to kernel 2.4.X. This patch is the same as what went into 2.6.10-rc1, except for the minor differences between 2.4.X and 2.6.X. This was tested on 2.4.29. The main reason of this patch is wireless driver outside the kernel tree. Some of them already support WE-17 (HostAP, Prism54), so having this patch in 2.4.X will allow then simplify their code. The changelog : * - Add flags to frequency -> auto/fixed * - Document (struct iw_quality *)->updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) * - Change the way we get to spy_data method for added safety and hostap * - Remove spy #ifdef, they are always on -> cleaner code * - Allow any size GET request if user specifies length > max * - Start migrating get_wireless_stats to struct iw_handler_def * Based on patch from Pavel Roskin <[EMAIL PROTECTED]> : * - Fix kernel data leak to user space in private handler handling Have fun... Jean diff -u -p linux/include/linux/netdevice.we16.h linux/include/linux/netdevice.h --- linux/include/linux/netdevice.we16.h2005-02-03 14:54:56.0 -0800 +++ linux/include/linux/netdevice.h 2005-02-03 15:43:30.0 -0800 @@ -295,7 +295,9 @@ struct net_device /* List of functions to handle Wireless Extensions (instead of ioctl). * See for details. Jean II */ - struct iw_handler_def * wireless_handlers; + const struct iw_handler_def * wireless_handlers; + /* Instance data managed by the core of Wireless Extensions. */ + struct iw_public_data * wireless_data; struct ethtool_ops *ethtool_ops; diff -u -p linux/include/linux/wireless.we16.h linux/include/linux/wireless.h --- linux/include/linux/wireless.we16.h 2005-02-03 14:55:04.0 -0800 +++ linux/include/linux/wireless.h 2005-02-03 15:44:48.0 -0800 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 21.6.04 * * Authors : Jean Tourrilhes - HPL - <[EMAIL PROTECTED]> - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -47,12 +47,12 @@ * # include/net/iw_handler.h * * Note as well that /proc/net/wireless implementation has now moved in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Wireless Events (2002 -> onward) : * * Events are defined at the end of this file, and implemented in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Other comments : * -- @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,13 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and "struct iw_thrspy" * - Add IW_ENCODE_TEMP and iw_range->encoding_login_index + * + * V16 to V17 + * -- + * - Add flags to frequency -> auto/fixed + * - Document (struct iw_quality *)->updated, add new flags (INVALID) + * - Wireless Event capability in struct iw_range + * - Add support for relative TxPower (yick !) */ / CONSTANTS / @@ -251,7 +258,7 @@ /* DEV PRIVATE IOCTL LIST */ -/* These 16 ioctl are wireless device private. +/* These 32 ioctl are wireless device private, for 16 commands. * Each driver is free to use them for whatever purpose it chooses, * however the driver *must* export the description of those ioctls * with SIOCGIWPRIV and *must* use arguments as defined below. @@ -266,8 +273,8 @@ * We now have 32 commands, so a bit more space ;-). * Also, all 'odd' commands are only usable by root and don't return the * content of ifr/iwr to user (but you are not obliged to use the set/get - * convention, just use every other two command). - * And I repeat : you are not obliged to use them with iwspy, but you + * convention, just use every other two command). More details in iwpriv.c. + * And I repeat : you are not forced to use them with iwpriv, but you * must be compliant with it. */ @@ -352,6 +359,18 @@ #define
[PATCH 2.4] Wireless Extension v17 (resend)
Hi Marcelo, I did not receive any feedback on this e-mail either, so I assume it was also lost on the way. Would you mind pushing that in 2.4.x ? Thanks... Jean - Forwarded message from jt - Subject: [PATCH 2.4] Wireless Extension v17 E-mail: [EMAIL PROTECTED] Hi Marcelo, This patch adds Wireless Extensions v17 to kernel 2.4.X. This patch is the same as what went into 2.6.10-rc1, except for the minor differences between 2.4.X and 2.6.X. This was tested on 2.4.29. The main reason of this patch is wireless driver outside the kernel tree. Some of them already support WE-17 (HostAP, Prism54), so having this patch in 2.4.X will allow then simplify their code. The changelog : * - Add flags to frequency - auto/fixed * - Document (struct iw_quality *)-updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) * - Change the way we get to spy_data method for added safety and hostap * - Remove spy #ifdef, they are always on - cleaner code * - Allow any size GET request if user specifies length max * - Start migrating get_wireless_stats to struct iw_handler_def * Based on patch from Pavel Roskin [EMAIL PROTECTED] : * - Fix kernel data leak to user space in private handler handling Have fun... Jean diff -u -p linux/include/linux/netdevice.we16.h linux/include/linux/netdevice.h --- linux/include/linux/netdevice.we16.h2005-02-03 14:54:56.0 -0800 +++ linux/include/linux/netdevice.h 2005-02-03 15:43:30.0 -0800 @@ -295,7 +295,9 @@ struct net_device /* List of functions to handle Wireless Extensions (instead of ioctl). * See net/iw_handler.h for details. Jean II */ - struct iw_handler_def * wireless_handlers; + const struct iw_handler_def * wireless_handlers; + /* Instance data managed by the core of Wireless Extensions. */ + struct iw_public_data * wireless_data; struct ethtool_ops *ethtool_ops; diff -u -p linux/include/linux/wireless.we16.h linux/include/linux/wireless.h --- linux/include/linux/wireless.we16.h 2005-02-03 14:55:04.0 -0800 +++ linux/include/linux/wireless.h 2005-02-03 15:44:48.0 -0800 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 21.6.04 * * Authors : Jean Tourrilhes - HPL - [EMAIL PROTECTED] - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -47,12 +47,12 @@ * # include/net/iw_handler.h * * Note as well that /proc/net/wireless implementation has now moved in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Wireless Events (2002 - onward) : * * Events are defined at the end of this file, and implemented in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Other comments : * -- @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,13 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and struct iw_thrspy * - Add IW_ENCODE_TEMP and iw_range-encoding_login_index + * + * V16 to V17 + * -- + * - Add flags to frequency - auto/fixed + * - Document (struct iw_quality *)-updated, add new flags (INVALID) + * - Wireless Event capability in struct iw_range + * - Add support for relative TxPower (yick !) */ / CONSTANTS / @@ -251,7 +258,7 @@ /* DEV PRIVATE IOCTL LIST */ -/* These 16 ioctl are wireless device private. +/* These 32 ioctl are wireless device private, for 16 commands. * Each driver is free to use them for whatever purpose it chooses, * however the driver *must* export the description of those ioctls * with SIOCGIWPRIV and *must* use arguments as defined below. @@ -266,8 +273,8 @@ * We now have 32 commands, so a bit more space ;-). * Also, all 'odd' commands are only usable by root and don't return the * content of ifr/iwr to user (but you are not obliged to use the set/get - * convention, just use every other two command). - * And I repeat : you are not obliged to use them with iwspy, but you + * convention, just use every other two command). More details in iwpriv.c. + * And I repeat : you are not forced to use them with iwpriv, but you * must be compliant with it. */ @@ -352,6 +359,18 @@ #define
Re: [PATCH 2.4] Wireless Extension v17 (resend)
Hi Jean, I'm very ignorant about wireless but it doesnt appear to me that Wireless Extension v17 is a critical feature. It seems more appropriate to declare it as 2.6 functionality ? Cheers On Tue, Feb 08, 2005 at 10:16:37AM -0800, Jean Tourrilhes wrote: Hi Marcelo, I did not receive any feedback on this e-mail either, so I assume it was also lost on the way. Would you mind pushing that in 2.4.x ? Thanks... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 04:01:16PM -0200, Marcelo Tosatti wrote: Hi Jean, I'm very ignorant about wireless but it doesnt appear to me that Wireless Extension v17 is a critical feature. You are right, it's not critical, and I was already thinking of not pushing WE-18 to you (the WPA update). I'll stop updating 2.4.X with respect to wireless, the patches will be available on my web page for people who needs it. We may revisit this if there is a public outcry... It seems more appropriate to declare it as 2.6 functionality ? There need to be some unique features in 2.6.X to force people to upgrade, I guess... Cheers Thanks. Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 01:51:12PM -0800, Jean Tourrilhes wrote: On Tue, Feb 08, 2005 at 04:01:16PM -0200, Marcelo Tosatti wrote: Hi Jean, I'm very ignorant about wireless but it doesnt appear to me that Wireless Extension v17 is a critical feature. You are right, it's not critical, and I was already thinking of not pushing WE-18 to you (the WPA update). I'll stop updating 2.4.X with respect to wireless, the patches will be available on my web page for people who needs it. Please dont miss bugfixes for present functionality. Gracias. We may revisit this if there is a public outcry... OK! It seems more appropriate to declare it as 2.6 functionality ? There need to be some unique features in 2.6.X to force people to upgrade, I guess... Faster, cleaner, way more elegant, handles intense loads more gracefully, handles highmem decently, LSM/SELinux, etc, etc... IMO everyone should upgrade whenever appropriate. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
Hi Marcelo, On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote: There need to be some unique features in 2.6.X to force people to upgrade, I guess... Faster, cleaner, way more elegant, handles intense loads more gracefully, When a CPU-hungry task freezes another one for more than 13 seconds, I cannot agree with your last statement, and that's why I still don't upgrade. I have already posted examples of worst case scenarios, but I now start to have a more meaningful example to show so that people working on the scheduler may have something clearer to work with. I also did not have time to retest -ck or staircase recently, but I will do for completeness. handles highmem decently, LSM/SELinux, etc, etc... IMO everyone should upgrade whenever appropriate. I still know about a tens of 2.2 still running around at customers ;-) However, if it had not been for lazyness, they should have upgraded. Cheers, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 11:45:31PM +0100, Willy Tarreau wrote: Hi Marcelo, On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote: There need to be some unique features in 2.6.X to force people to upgrade, I guess... Faster, cleaner, way more elegant, handles intense loads more gracefully, When a CPU-hungry task freezes another one for more than 13 seconds, I cannot agree with your last statement, and that's why I still don't upgrade. I have already posted examples of worst case scenarios, but I now start to have a more meaningful example to show so that people working on the scheduler may have something clearer to work with. I also did not have time to retest -ck or staircase recently, but I will do for completeness. v2.6 scheduler regressions cannot be tolerated. Please prepare more detailed data about your problem - I'm sure Ingo and friends will appreciate it. handles highmem decently, LSM/SELinux, etc, etc... IMO everyone should upgrade whenever appropriate. I still know about a tens of 2.2 still running around at customers ;-) However, if it had not been for lazyness, they should have upgraded. :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote: On Tue, Feb 08, 2005 at 01:51:12PM -0800, Jean Tourrilhes wrote: You are right, it's not critical, and I was already thinking of not pushing WE-18 to you (the WPA update). I'll stop updating 2.4.X with respect to wireless, the patches will be available on my web page for people who needs it. Please dont miss bugfixes for present functionality. Gracias. Depend what you call bugfix. Fortunately, with the long beta period I do with the WE, bugs are few. There are only two bugs in WE-16 I'm aware off (fixed in WE-17), but I don't think they are worth fixing. The first is the handling of spyoffset which is potentially unsafe. Unfortunately, the fix involve some API/infrastructure change, so is not transparent. Fortunately drivers are clever enough to not trigger this bug. The second is a potential leak of kernel data to user space in private handler handling. Few drivers use that feature, there is no risk of crash or direct attack, so I would not worry about it. Faster, cleaner, way more elegant, handles intense loads more gracefully, handles highmem decently, LSM/SELinux, etc, etc... IMO everyone should upgrade whenever appropriate. If people want to use 2.4.X, I won't prevent them... Have fun... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, 2005-02-08 at 13:41, Marcelo Tosatti wrote: There need to be some unique features in 2.6.X to force people to upgrade, I guess... Faster, cleaner, way more elegant, handles intense loads more gracefully, handles highmem decently, LSM/SELinux, etc, etc... Please *think* before saying this. It's not always the case. Firewire support in 2.6 kernel has been less than stellar, for one example. And yes, for many, solid 1394 support is a requirement for business. (And we've all seen the testing that has shown both sides (2.4, 2.6) have been faster) IMO everyone should upgrade whenever appropriate. Not sureon 13 January 2005 Alan Cox posted Given that base 2.6 kernels are shipped by Linus with known unfixed security holes anyone trying to use them really should be doing some careful thinking. In truth no 2.6 released kernel is suitable for anything but beta testing until you add a few patches anyway. How do you answer this, when telling folks everyone should upgrade whenever appropriate.? Just some random thoughtsfrom a 2.4 supporter :) -fd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
Message below meant for Marcelo! (sorry rest!) On Tue, 2005-02-08 at 20:09, kernel wrote: On Tue, 2005-02-08 at 13:41, Marcelo Tosatti wrote: There need to be some unique features in 2.6.X to force people to upgrade, I guess... Faster, cleaner, way more elegant, handles intense loads more gracefully, handles highmem decently, LSM/SELinux, etc, etc... Please *think* before saying this. It's not always the case. Firewire support in 2.6 kernel has been less than stellar, for one example. And yes, for many, solid 1394 support is a requirement for business. (And we've all seen the testing that has shown both sides (2.4, 2.6) have been faster) IMO everyone should upgrade whenever appropriate. Not sureon 13 January 2005 Alan Cox posted Given that base 2.6 kernels are shipped by Linus with known unfixed security holes anyone trying to use them really should be doing some careful thinking. In truth no 2.6 released kernel is suitable for anything but beta testing until you add a few patches anyway. How do you answer this, when telling folks everyone should upgrade whenever appropriate.? Just some random thoughtsfrom a 2.4 supporter :) -fd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
* Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
The first is the handling of spyoffset which is potentially
unsafe. Unfortunately, the fix involve some API/infrastructure change,
so is not transparent. Fortunately drivers are clever enough to not
trigger this bug.
The second is a potential leak of kernel data to user space in
private handler handling. Few drivers use that feature, there is no
risk of crash or direct attack, so I would not worry about it.
Hmm, having ability to read kernel data is not so nice. prism54 uses
this, and is a reasonably popular card. Looks to me like this should be
plugged. Is the patch below sufficient? (stolen from full 2.6 patch)
thanks,
-chris
= net/core/wireless.c 1.4 vs edited =
--- 1.4/net/core/wireless.c 2003-09-03 04:12:57 -07:00
+++ edited/net/core/wireless.c 2005-02-08 17:45:15 -08:00
@@ -310,7 +310,7 @@ static inline int call_commit_handler(st
/* */
/*
- * Number of private arguments
+ * Calculate size of private arguments
*/
static inline int get_priv_size(__u16 args)
{
@@ -320,6 +320,24 @@ static inline int get_priv_size(__u16 ar
return num * priv_type_size[type];
}
+/* */
+/*
+ * Re-calculate the size of private arguments
+ */
+static inline int adjust_priv_size(__u16 args,
+ union iwreq_data * wrqu)
+{
+ int num = wrqu-data.length;
+ int max = args IW_PRIV_SIZE_MASK;
+ int type = (args IW_PRIV_TYPE_MASK) 12;
+
+ /* Make sure the driver doesn't goof up */
+ if (max num)
+ num = max;
+
+ return num * priv_type_size[type];
+}
+
/ /proc/net/wireless SUPPORT /
/*
@@ -701,7 +719,7 @@ static inline int ioctl_private_call(str
((extra_size + offset) = IFNAMSIZ))
extra_size = 0;
} else {
- /* Size of set arguments */
+ /* Size of get arguments */
extra_size = get_priv_size(descr-get_args);
/* Does it fits in iwr ? */
@@ -731,7 +749,7 @@ static inline int ioctl_private_call(str
return -EFAULT;
/* Does it fits within bounds ? */
- if(iwr-u.data.length (descr-set_args
+ if(iwr-u.data.length (descr-get_args
IW_PRIV_SIZE_MASK))
return -E2BIG;
} else {
@@ -771,6 +789,14 @@ static inline int ioctl_private_call(str
/* If we have something to return to the user */
if (!ret IW_IS_GET(cmd)) {
+
+ /* Adjust for the actual length if it's variable,
+* avoid leaking kernel bits outside. */
+ if (!(descr-get_args IW_PRIV_SIZE_FIXED)) {
+ extra_size = adjust_priv_size(descr-get_args,
+ (iwr-u));
+ }
+
err = copy_to_user(iwr-u.data.pointer, extra,
extra_size);
if (err)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 08:09:04PM -0500, kernel wrote: On Tue, 2005-02-08 at 13:41, Marcelo Tosatti wrote: There need to be some unique features in 2.6.X to force people to upgrade, I guess... Faster, cleaner, way more elegant, handles intense loads more gracefully, handles highmem decently, LSM/SELinux, etc, etc... Please *think* before saying this. It's not always the case. Firewire support in 2.6 kernel has been less than stellar, for one example. And yes, for many, solid 1394 support is a requirement for business. Well, if it has problems, like every piece of software is expected to have, then it should be fixed. We all should invest our efforts in having v2.6 the most stable kernel as possible. I'm sure Ben Collins (1394 maintainer) will appreciate 1394 bug reports and he will do his best at fixing them. (And we've all seen the testing that has shown both sides (2.4, 2.6) have been faster) IMO everyone should upgrade whenever appropriate. Not sureon 13 January 2005 Alan Cox posted Given that base 2.6 kernels are shipped by Linus with known unfixed security holes anyone trying to use them really should be doing some careful thinking. In truth no 2.6 released kernel is suitable for anything but beta testing until you add a few patches anyway. Alan means that _mainline_ v2.6 kernel might not be as polished as distribution kernels. He does not mean, at all, that individuals should not upgrade to v2.6 based kernels. Note his until you add a few patches anyway. How do you answer this, when telling folks everyone should upgrade whenever appropriate.? Please realize that pretty much all development efforts have been centered at the v2.6 kernel, and that means a lot. Just some random thoughtsfrom a 2.4 supporter :) :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 05:51:29PM -0800, Chris Wright wrote:
* Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
The first is the handling of spyoffset which is potentially
unsafe. Unfortunately, the fix involve some API/infrastructure change,
so is not transparent. Fortunately drivers are clever enough to not
trigger this bug.
The second is a potential leak of kernel data to user space in
private handler handling. Few drivers use that feature, there is no
risk of crash or direct attack, so I would not worry about it.
Hmm, having ability to read kernel data is not so nice.
It's not like you can read any arbitrary address, exploiting
such a flaw is in my mind theoritical. Let's not overblow things,
there are some real bugs to take care of.
prism54 uses
this, and is a reasonably popular card. Looks to me like this should be
plugged. Is the patch below sufficient? (stolen from full 2.6 patch)
Yep, except that you have an extra chunk that should not be
in. You probably did not use the latest version of the patch (and that
was not in the one sent to Marcelo). I would not like to introduce a
real bug in 2.4.X :-(
thanks,
-chris
This chunk is erroneous :
@@ -731,7 +749,7 @@ static inline int ioctl_private_call(str
return -EFAULT;
/* Does it fits within bounds ? */
- if(iwr-u.data.length (descr-set_args
+ if(iwr-u.data.length (descr-get_args
IW_PRIV_SIZE_MASK))
return -E2BIG;
} else {
Have fun...
Jean
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] Wireless Extension v17 (resend)
* Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
On Tue, Feb 08, 2005 at 05:51:29PM -0800, Chris Wright wrote:
Hmm, having ability to read kernel data is not so nice.
It's not like you can read any arbitrary address, exploiting
such a flaw is in my mind theoritical. Let's not overblow things,
there are some real bugs to take care of.
If the fix is simple (as it appears to be), there's no good reason to
leave the risk there.
prism54 uses
this, and is a reasonably popular card. Looks to me like this should be
plugged. Is the patch below sufficient? (stolen from full 2.6 patch)
Yep, except that you have an extra chunk that should not be
in. You probably did not use the latest version of the patch (and that
was not in the one sent to Marcelo). I would not like to introduce a
real bug in 2.4.X :-(
Yes, you are correct, here it is without that errouneous bit.
thanks,
-chris
= net/core/wireless.c 1.4 vs edited =
--- 1.4/net/core/wireless.c 2003-09-03 04:12:57 -07:00
+++ edited/net/core/wireless.c 2005-02-08 17:45:15 -08:00
@@ -310,7 +310,7 @@ static inline int call_commit_handler(st
/* */
/*
- * Number of private arguments
+ * Calculate size of private arguments
*/
static inline int get_priv_size(__u16 args)
{
@@ -320,6 +320,24 @@ static inline int get_priv_size(__u16 ar
return num * priv_type_size[type];
}
+/* */
+/*
+ * Re-calculate the size of private arguments
+ */
+static inline int adjust_priv_size(__u16 args,
+ union iwreq_data * wrqu)
+{
+ int num = wrqu-data.length;
+ int max = args IW_PRIV_SIZE_MASK;
+ int type = (args IW_PRIV_TYPE_MASK) 12;
+
+ /* Make sure the driver doesn't goof up */
+ if (max num)
+ num = max;
+
+ return num * priv_type_size[type];
+}
+
/ /proc/net/wireless SUPPORT /
/*
@@ -701,7 +719,7 @@ static inline int ioctl_private_call(str
((extra_size + offset) = IFNAMSIZ))
extra_size = 0;
} else {
- /* Size of set arguments */
+ /* Size of get arguments */
extra_size = get_priv_size(descr-get_args);
/* Does it fits in iwr ? */
@@ -771,6 +789,14 @@ static inline int ioctl_private_call(str
/* If we have something to return to the user */
if (!ret IW_IS_GET(cmd)) {
+
+ /* Adjust for the actual length if it's variable,
+* avoid leaking kernel bits outside. */
+ if (!(descr-get_args IW_PRIV_SIZE_FIXED)) {
+ extra_size = adjust_priv_size(descr-get_args,
+ (iwr-u));
+ }
+
err = copy_to_user(iwr-u.data.pointer, extra,
extra_size);
if (err)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
