linux-kernel - Re: Why is my copyright code in the linux kernel?

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:	Wed, 02 Mar 2011 13:52:04 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Ted Ts'o" <tytso@....edu>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	dj@...dhat.com, linux-kernel@...r.kernel.org, gregkh@...e.de
Subject: Re: Why is my copyright code in the linux kernel?

On 03/01/2011 03:54 PM, Ted Ts'o wrote:
> On Wed, Mar 02, 2011 at 12:30:45AM +0100, richard -rw- weinberger wrote:
>>> You will see a remarkable resemblance to parts of
>>> linux-2.6.36.2/drivers/staging/rt2860/common/cmm_aes.c. E.G. the AES code,
>>
>> please note, this is a staging driver.
> 
> It's not even the primary driver.  Is there anything that this driver
> provides that isn't provided by the upstream supported, mainline
> rt2x00 project?  I.e., can we just delete the staging driver?
> 
> If we are going to keep the staging driver for some reason, one of the
> things that should be added to the TODO list would be delete its
> driver-specific AES code and replace it with calls to the kernel's
> generic AES code, which among other things, has the advantage that it
> can take advantage of the AES-NI instructions provided on more modern
> x86 CPU's.
> 
>>> I'd like to know who is an appropriate person to discuss this with.
>>
>> the code is from ralink.
> 
> David, you might want to contact ralink directly, since it's likely
> they are distributing that driver with your AES code in other places
> besides just in the mainstream kernel sources.  Even if we delete the
> code in the staging tree, they might be distributing that driver still
> via other means.
> 

I think it's more fundamental than that.  If ralink -- or anyone else --
submitted a plagiarized driver to the staging tree, we should remove it
immediately unless the copyright holder (David in this case) is willing
to allow us to retain it while things are sorted out.

And yes, David still needs to contact ralink about sorting out the
violation.

Finally, obviously, a proper Linux driver should use the AES facilities
in the kernel crypto core.

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