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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ