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: <20080304205117.GA21803@elte.hu>
Date:	Tue, 4 Mar 2008 21:51:17 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pavel Roskin <proski@....org>, Zan Lynx <zlynx@....org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jon Masters <jcm@...masters.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only
	symbols


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, 4 Mar 2008, Ingo Molnar wrote:
> > 
> > so ... i suspect the requirement would be for 
> > NdisMAllocateSharedMemory() to return a linear address that is 
> > DMA-able, and to properly map it to a physical address via 
> > dma_map_single(). I can see only one complication in pushing this to 
> > user-space: physical fragmentation of allocations. What are the 
> > typical buffer sizes that NDIS drivers request from the kernel? Is 
> > it frequently above 4K?
> 
> Ingo, i's simply not possible to put ndiswrapper in user-space sanely.
> 
> Drivers are drivers. They'll want (shared) interrupts, they want DMA, 
> they want to do things like cli/sti.
> 
> The USB drivers *may* be abstracted enough that they don't do any of
> that, but quite frankly, I doubt it.

yeah, i agree that putting it into userspace is quite insane.

it might possible to do it halfways sanely via existing arch/x86/kvm/ 
infrastructure though. VMX/SVM context will properly emulate the IRQ 
flag so cli/sti will work fine, and as long as DMA is properly 
quarantined via an iommu it might even not corrupt the rest of the 
system. Right now KVM is tailored for full system emulation but there's 
no strong reason why it couldnt emulate just a single hardware domain, 
with an NDIS driver sitting in that domain - talking to the rest of the 
system via hypercalls.

> It sounds like there aren't that many symbols affected at the core: 
> the workqueue stuff certainly isn't worth bothering about. The USB 
> things that ndiswrapper wants is much more involved, and more likely 
> to have issues, but I'm cc'ing Greg here to see.
> 
> IOW: I _personally_ don't think there are any license issues, but I do 
> want to have the situation clear to people involved.

the ugliest technical aspect of them being in the Linux host kernel is 
that NDIS drivers are used to a larger kernel stack, so they very 
frequently overflow the Linux kernel stack. Not sure whether recent 
versions of ndiswrapper have solved this problem.

	Ingo
--
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/