linux-kernel - Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

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: <1204324265.2316.70.camel@dv>
Date:	Fri, 29 Feb 2008 17:31:05 -0500
From:	Pavel Roskin <proski@....org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Zan Lynx <zlynx@....org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jon Masters <jcm@...masters.org>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only
	symbols


On Fri, 2008-02-29 at 22:15 +0100, Ingo Molnar wrote:
> * Pavel Roskin <proski@....org> wrote:
> 
> > I already know what USB folks will say.  They want proprietary drivers 
> > to be in the userspace.  I doubt ndiswrapper will ever be ported to 
> > the userspace.  It's much more likely that some other approach will be 
> > used.
> 
> btw., what are the technical reasons why ndiswrapper cannot be done in 
> userspace, much like the (wildly successful) FUSE concept?

ndiswrapper contains essentially two drivers in one - PCI and USB.  The
PCI driver uses DMA, which should be a strong argument for keeping it in
the kernel.

As for the USB driver, it may be possible, but some infrastructure may
still be missing.

ndiswrapper needs to register network devices.  For wireless devices, it
needs to be a device with wireless extension support.  I don't think
it's currently possible from the userspace.

> what's the main hardware access method of ndiswrapper - only PIO, or 
> mmio as well? In the former case, ioperm() should work, in the latter 
> case, mmap()ing the device aperture should work.

Both.  I'm afraid DMA is the real problem here.

> Frankly, it would be a great approach for the following reason: it would 
> be _far_ easier for people to write a proper free driver, if the NDIS 
> driver was in user-space, in a nicely debuggable, traceable, observable 
> environment. I dont really see what the technical difficulties there are 
> here.

I agree that it would be great, but it's quite a lot of work.

-- 
Regards,
Pavel Roskin
--
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/