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: <1224021942.16038.66.camel@lappy.programming.kicks-ass.net>
Date:	Wed, 15 Oct 2008 00:05:42 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Kaz Kylheku <kkylheku@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: GPL question: using large contiguous memory in proprietary
	driver.

On Tue, 2008-10-14 at 14:56 -0700, Kaz Kylheku wrote:
> Hi all,
> 
> I have the following question. Suppose that some proprietary driver
> (otherwise completely clean, based only on non-GPL symbols)
> requires a large buffer of physically contiguous memory.
> 
> A GPL-ed driver could get this memory by having some boot-time
> code compiled into the kernel which calls bootmem_alloc during
> kernel initialization. This function would stash the address of the
> memory into some global variable which is exported for the
> module to use.
> 
> How do you solve this problem in a proprietary driver? It seems
> like the above solution taints the kernel, because the kernel
> provides a symbol which exists only for the sake of supporting
> a proprietary driver.
> 
> Would it be okay to have a mechanism like this:
> Suppose that  on the kernel command line, you could
> request a boot-time memory allocation and give it a name.
> For instance, the parameter:
> 
>    boot_alloc=foo,8192K
> 
> would create an 8192 kilobyte allocation, and associate it
> with the string "foo".   A non-GPL function would be provided to
> find the address of this memory, using the string "foo"
> as the key. The proprietary driver would document the
> requirement that it needs a memory region of at least
> 8192K, under the name "foo".

Any GPL driver doing that deserves to be taken out and shot just as bad
as anyone else ;-)

That said, I don't think you'll find much sympathy here for non-GPL
kernel modules.

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