headers
Johannes Berg | 2 Apr 12:06
Favicon

Re: [PATCH 2.6] WE-22 : prevent information leak on 64 bit


> 	Johannes Berg discovered that kernel space was leaking to
> userspace on 64 bit platform. He made a first patch to fix that. This
> is an improved version of his patch.
> 	This was tested on 2.6.21-rc4. Would you mind pushing that
> upstream ?

Just FYI. This patch applies with rejects in net/core/rtnetlink.c and
net/core/wireless.c to wireless-dev. The changes in those two files can
be ignored completely since they affect only the removed
wext-over-netlink interface.

johannes
Permalink | Reply |
headers
Jean Tourrilhes | 17 Apr 19:08
Picon
Favicon

Re: [PATCH 2.6] WE-22 : prevent information leak on 64 bit

On Mon, Apr 02, 2007 at 12:06:50PM +0200, Johannes Berg wrote:
> 
> Jean Tourrilhes wrote :
> > 	Johannes Berg discovered that kernel space was leaking to
> > userspace on 64 bit platform. He made a first patch to fix that. This
> > is an improved version of his patch.
> > 	This was tested on 2.6.21-rc4. Would you mind pushing that
> > upstream ?
> 
> Just FYI. This patch applies with rejects in net/core/rtnetlink.c and
> net/core/wireless.c to wireless-dev. The changes in those two files can
> be ignored completely since they affect only the removed
> wext-over-netlink interface.
> 
> johannes

	I'm sorry to have to write this e-mail. But this incident is
completely opposed to the ideal of FreeSoftware/OpenSource and
demonstrate some of the bad politics happening in Linux.

	First, I'm the current active maintainer of the
wext-over-netlink interface, and nobody bothered to even 'inform' me
about its removal, let alone consult with me.
	This shows a complete lack of courtesy and a total disrespect
to the concept of maintainer, basically some people are just second
class citizens.

	Second, there is no technical justification to such decision,
it's just plain politics. I would agree that for the vast majority of
people, this API was useless, as any work in progress. But, it is
(Continue reading)

Permalink | Reply |
headers
Johannes Berg | 18 Apr 12:18
Favicon

Re: [PATCH 2.6] WE-22 : prevent information leak on 64 bit

Jean,

> 	First, I'm the current active maintainer of the
> wext-over-netlink interface, and nobody bothered to even 'inform' me
> about its removal, let alone consult with me.

I definitely should have copied you on the feature-removal schedule
patch for wext-over-netlink and then the actual removal in wireless-dev;
please accept my apologies for not doing that, it was not done in bad
faith. It was never my intention to demote you to a "second class
citizen", I'm sorry you feel that way.

I have previously (and multiple times) given technical justification for
removing this code (even recorded in the kernel changelog now) and I
contend your allegation that it is a political issue. Others in this
thread have pointed out the technical issues with wext and wext/nl so I
will not repeat them.

I hope that despite my mistakes in handling the wext/nl removal we will
be able to work together in the future to have wext fully supported with
clear semantics for backwards compatibility while the kernel internally
migrates towards cfg80211.

johannes
Permalink | Reply |
headers
Michael Buesch | 18 Apr 01:34
Picon
Favicon

Re: [PATCH 2.6] WE-22 : prevent information leak on 64 bit

On Tuesday 17 April 2007 19:08, Jean Tourrilhes wrote:
> 	I'm sorry to have to write this e-mail. But this incident is
> completely opposed to the ideal of FreeSoftware/OpenSource and
> demonstrate some of the bad politics happening in Linux.
> 
> 	First, I'm the current active maintainer of the
> wext-over-netlink interface, and nobody bothered to even 'inform' me
> about its removal, let alone consult with me.
> 	This shows a complete lack of courtesy and a total disrespect
> to the concept of maintainer, basically some people are just second
> class citizens.
> 
> 	Second, there is no technical justification to such decision,
> it's just plain politics. I would agree that for the vast majority of
> people, this API was useless, as any work in progress. But, it is
> maintained (by me), it is not causing any technical issue, for those
> people it's not compiled in (i.e. no bloat), it is not causing bugs
> and not preventing other code to be merged in the kernel.
> 	Therefore a purely politic decision.

It is _only_ about replacing obsolete code by code that obsoleted it.
That happens all the time. Look at the process scheduler and compare
it to 2.4, for example.

We want to reduce the maintainance burden. Nothing more.
If we remove unused code (which WEXT-NL is), then we don't have to
write compatibility code to support it in future.
Why wait with removal until we can't anymore (when people use it)?

> 	Now, I've got a problem with your attitude in this matter,
(Continue reading)

Permalink | Reply |
headers
Jean Tourrilhes | 18 Apr 18:30
Picon
Favicon

Re: [PATCH 2.6] WE-22 : prevent information leak on 64 bit

On Wed, Apr 18, 2007 at 01:34:50AM +0200, Michael Buesch wrote:
> 
> I'd say nobody but you does fully understand WEXT.

	Not true. If tommorow I was run over by an ICE, you could ask
Jouni, Dan or Pavel to take over.
	Have fun...

	Jean
Permalink | Reply |
headers
John W. Linville | 17 Apr 20:34
Favicon

Re: [PATCH 2.6] WE-22 : prevent information leak on 64 bit

On Tue, Apr 17, 2007 at 10:08:20AM -0700, Jean Tourrilhes wrote:
> On Mon, Apr 02, 2007 at 12:06:50PM +0200, Johannes Berg wrote:
> > 
> > Jean Tourrilhes wrote :
> > > 	Johannes Berg discovered that kernel space was leaking to
> > > userspace on 64 bit platform. He made a first patch to fix that. This
> > > is an improved version of his patch.
> > > 	This was tested on 2.6.21-rc4. Would you mind pushing that
> > > upstream ?
> > 
> > Just FYI. This patch applies with rejects in net/core/rtnetlink.c and
> > net/core/wireless.c to wireless-dev. The changes in those two files can
> > be ignored completely since they affect only the removed
> > wext-over-netlink interface.
> > 
> > johannes
> 
> 	I'm sorry to have to write this e-mail. But this incident is
> completely opposed to the ideal of FreeSoftware/OpenSource and
> demonstrate some of the bad politics happening in Linux.
> 
> 	First, I'm the current active maintainer of the
> wext-over-netlink interface, and nobody bothered to even 'inform' me
> about its removal, let alone consult with me.

Honestly, most of us thought you weren't interested.

> 	This shows a complete lack of courtesy and a total disrespect
> to the concept of maintainer, basically some people are just second
> class citizens.
(Continue reading)

Permalink | Reply |
headers
Jean Tourrilhes | 17 Apr 23:19
Picon
Favicon

Re: [PATCH 2.6] WE-22 : prevent information leak on 64 bit

On Tue, Apr 17, 2007 at 02:34:42PM -0400, John W. Linville wrote:
> On Tue, Apr 17, 2007 at 10:08:20AM -0700, Jean Tourrilhes wrote:
> > 
> > 	First, I'm the current active maintainer of the
> > wext-over-netlink interface, and nobody bothered to even 'inform' me
> > about its removal, let alone consult with me.
> 
> Honestly, most of us thought you weren't interested.

	Please !

> This API was controversial and mostly unwelcome from the start.
> It was ridiculed as "ioctls over netlink" at the last kernel summit.

	Which is complete FUD. In that case, the whole RtNetlink can
be classified as "ioctls over netlink".

> One of the objections to having merged the API was that _if_ it were
> to gain users then we would have to carry that maintenance burden
> ad infinitum.

	More FUD. It does not add any new commands. The proof is in
the pudding, no change was needed in any driver to support it,
therefore it could not have added any burden on any compatibility
layer.

> Regards,
> 
> John
(Continue reading)

Permalink | Reply |
headers
Roland Dreier | 17 Apr 23:59
Picon
Favicon

Re: [PATCH 2.6] WE-22 : prevent information leak on 64 bit

 > > This API was controversial and mostly unwelcome from the start.
 > > It was ridiculed as "ioctls over netlink" at the last kernel summit.
 > 
 > 	Which is complete FUD. In that case, the whole RtNetlink can
 > be classified as "ioctls over netlink".

The problem is that WE over netlink is basically using netlink to
transfer the same binary blobs as the WE ioctls, rather than using
properly structured netlink messages.

 > > One of the objections to having merged the API was that _if_ it were
 > > to gain users then we would have to carry that maintenance burden
 > > ad infinitum.
 > 
 > 	More FUD. It does not add any new commands. The proof is in
 > the pudding, no change was needed in any driver to support it,
 > therefore it could not have added any burden on any compatibility
 > layer.

The point is that if WE over netlink is used by applications, then the
kernel must maintain that ABI (of WE over netlink) forever.

 - R.
Permalink | Reply |

Gmane