linux-kernel - Re: GPL question: using large contiguous memory in proprietary driver.

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: <200810152226.00668.nickpiggin@yahoo.com.au>
Date:	Wed, 15 Oct 2008 22:26:00 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	"Kaz Kylheku" <kkylheku@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-mm@...ck.org
Cc:	"Chris Friesen" <cfriesen@...tel.com>, linux-kernel@...r.kernel.org
Subject: Re: GPL question: using large contiguous memory in proprietary driver.

On Wednesday 15 October 2008 10:39, Kaz Kylheku wrote:
> On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen <cfriesen@...tel.com> wrote:
> > Kaz Kylheku wrote:
> >> I have the following question. Suppose that some proprietary driver
> >> (otherwise completely clean, based only on non-GPL symbols)
> >
> > The fact that it's not using GPL symbols does not actually mean that the
> > driver is not a derivative work of the kernel (and thus subject to the
> > GPL).
>
> One more thing. Here is another question.

I don't know if there are any lawyers on this list, and definitely you
shouldn't take this kind of advice from answers here.

> Suppose that this proprietary driver can be moved entirely into user
> space. It still needs the contiguous buffer, but it can
> map it using mmap, given the address.

The kernel carries a license that states:

'NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".'

Which could be relevant.

> Can this proprietary user-space application read the address
> of this buffer from a custom /proc entry?
>
> Or does this dependency make it a derived work of the kernel?

I would be careful if you were to explicitly modify the kernel you
distribute with the driver in order to allow your driver to live
in userspace. No idea whether that is safe.

However, we do have this pagemap proc API existing in the kernel
which is a kernel service that can be used with a normal system
call. It returns the page frame number that a given virtual address
is mapped to. (God knows WTF that is supposed to be a remotely good
idea for the kernel to export, but there you have it.)

Whether that helps you or allows you to comply with your obligations,
I don't know.

Or, as an alternative, why not instead run the gauntlet with your
other licensor and tell them their license isn't acceptable because
your product contains code with incompatible restrictions?!
--
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/