[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 Jun 2017 00:16:43 -0700
From: Kees Cook <keescook@...omium.org>
To: Brad Spengler <spender@...ecurity.net>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Stop the plagiarism
(Hilariously, this email was detected as spam and never hit my inbox.
Dug it out now...)
On Sat, Jun 3, 2017 at 4:30 AM, Brad Spengler <spender@...ecurity.net> wrote:
> http://www.openwall.com/lists/kernel-hardening/2017/06/03/11
>
> Guys, this is your *last warning*. This stops *now* or I'm sending lawyers
> after you and the companies paying you to plagiarize our work and violate
> our *registered* copyright (which for the record entitles us to punitive
> damages which now are very easily provable). It's time to get serious
> about attribution -- what you are doing is completely unacceptable. I'm
> already in contact with lawyers to prepare for the next time this happens.
> If any of this plagiarized and misattributed code actually made it into
> the Linux kernel, you'd all be in a world of pain.
There have been a few cases of grsecurity's copyright notice going
missing from things it shouldn't have, and it got corrected. People
make mistakes, especially those that are new to upstream Linux kernel
work. You've pointed the mistakes out before, and I've asked that
people contact you when there is question about how to do attribution:
http://www.openwall.com/lists/kernel-hardening/2016/05/20/6
Perhaps a more prominent FAQ entry is needed on the KSPP Wiki?
> https://lwn.net/SubscriberLink/724319/830a4de15663b8dd/
> over a dozen mentions of various forms of "Cook's implementation"
Let's see, the paragraph in the article that talks about the proposal
credits PaX/grsecurity. Clicking through to my proposed series shows
the first paragraph crediting PaX/grsecurity. You seem to be arguing
semantics, rather than credit?
> that was blindly copy+pasted from PaX (as evidenced by its bugs and
> complete misunderstanding of how the original PaX code works since
> it didn't copy+paste all the parts it needed). And of course Kees
> is nowhere to be found to correct the misattribution of the work because
> it benefits him and his perceived security ability. There's a word for
> that: charlatan.
Look, you need to stop this kind of personal attack. I'm not going to
suddenly give up on improving Linux kernel security because you're
calling me names. Making Linux more secure isn't all about you, and
your tired rants about how things should be done "better" are hollow.
As for thinking all misattribution is somehow singularly on me to fix
is ridiculous. I can't read everything the instant it is published,
nor can I reply to it all. This email is the first I even knew about
this LWN article being published. And as I already said, it's not
misattributed. You're just willfully misreading it.
Make up your mind about how you want grsecurity attributed and maybe
people will actually do it "right". But you don't seem to actually
want that, since you appear to just want to discourage anything that
even looks like grsecurity from going upstream. If you think you're
amply credited, you get mad that it's TOO MUCH credit because the
resulting code is different from grsecurity and it's giving you a bad
name somehow. If you think you're under credited, you go on these
kinds of rants calling everyone a plagiarist.
> Or how about this one:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2f48641cfc83c3e1fdc81204382e05edf182691a
> First three copied directly from grsecurity, presumably you submitted
> some patch series to a mailing list where only the 0/N cover mail mentioned
> grsecurity, and now there's no mention whatsoever of where the changes
Let's look at that, shall we?
$ git log --oneline | grep "Use designated"
243dd05d39aa mtk-vcodec: Use designated initializers
3ddd396f6b57 drm/amd/powerplay: Use designated initializers
2a9d6d26e2b7 drm/amdgpu: Use designated initializers
234041dfe5ca sgi-xp: Use designated initializers
33006cdf9c03 ovl: Use designated initializers
efacae6d4c09 scsi: qedi: qedf: Use designated initializers
82fe0d2b44e0 af_unix: Use designated initializers
8291798dcf05 TOMOYO: Use designated initializers
ffc7dc8d838c x86/floppy: Use designated initializers
The last 5 here all say:
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
The sgi-xp changes were completely different from grsecurity, and the
other 3 you're specifically mentioning here were fixed by me in code
that was newer than the most current grsecurity patch I was working
from at the time and/or I wasn't even bothering to look at the
grsecurity patch because they're all trivial fixes. The remaining
changes were ERR_CAST() fixes that weren't fixed in grsecurity at all,
and threw warnings during randstruct builds.
> came from in the first place. You guys are seriously playing with fire,
> and it seems like an intentional act of revenge for being cut off from
> our work (lest I remind you of the legal and financial consequences of
> willful copyright infringement).
I do not understand why you think there is a conspiracy against you. I
have no time to try to figure out how to take "revenge", and even if I
did, I'm not upset about being "cut off" from your work. As I
mentioned already, making Linux more secure isn't all about
grsecurity. Just ask arm64 system builders how useful grsecurity was
for them.
> This is exactly how your plagiarism works. This is exactly why you
> no longer have access to our work -- do you not get how incredibly
> infuriating this is?
I really think you need to take a step back and look at what has gone
into upstream. All the gcc plugins from grsecurity have changelog
credit, Kconfig credit, and copyright. The hardened usercopy code has
changelog credit and copyright (and when PaX Team got upset that I
rewrote the Kconfig text, I detailed why the original Kconfig was
inaccurate for upstream, etc). I have repeatedly demonstrated what I
feel to be comprehensive credit-giving and copyright carrying for
things coming out of grsecurity.
You've been upset in the past about seemingly NIHed code like
VMAP_STACK or ARM's use of Domains, but those were implemented without
those authors reading grsecurity, IIUC. In fact, you've regularly
harassed them because you think their implementations are bad. That
can hardly be considered uncredited derivative work.
So, given that grsecurity is amply credited, what is it you're infuriated about?
> This is your last warning. This is not a new problem and it needs to
> end completely, or I will make sure it ends.
You appear to be trying to bully people into not contributing to the
upstream effort to make Linux more secure. Please stop.
I have bent over backwards to credit grsecurity as best as I can see
how, and you're still going on rants. If you want people to credit
grsecurity in some specific way, then please detail the method they
should follow. If you don't have a specific way you want to be
credited, I must conclude that you're just trying to be an
obstructionist.
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
