[kernel-hardening] Stop the plagiarism

[kernel-hardening] Stop the plagiarism

[Brad Spengler]

[-- Attachment #1: Type: text/plain, Size: 4572 bytes --]

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.

Matt -- did you not see in the directory the Kconfig file was copy+pasted
from the following:

# grsecurity - access control and security hardening for Linux
# All code in this directory and various hooks located throughout the Linux kernel are
# Copyright (C) 2001-2014 Bradley Spengler, Open Source Security, Inc.
# http://www.grsecurity.net spender@grsecurity.net
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License version 2
# as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

Yet you are claiming copyright entirely over my work.  Your copy+pasted
Kconfig entry didn't even adjust for your renaming of my sysctl variables.
Search+replace of config and function names is not transformative, and
I dare to think how much of your tpe_lsm.c is copy+pasted from cormander's
LSM.

I know it must be hard for the KSPP, having no original ideas of its
own, but this is not security or development.  It's mindless plagiarism
and illegal.  Then to slap your own copyright over the whole copy+pasted
thing is a total insult and demonstrates the complete lack of respect
KSPP has for the work it can't accomplish anything without.  The KSPP
and the companies funding it wouldn't be able to show a shred of perceived
progress were it not for its ability to simply copy+paste portions of
our work, because every time you modify something you introduce bugs and
new vulnerabilities, demonstrating your cluelessness.

While I'm here:
http://openwall.com/lists/kernel-hardening/2017/06/02/3

"a value linux-hardened and grsecurity have used for a long time now"
Rik, you're giving credit to a project that didn't even exist a couple
weeks ago, yet they've somehow used it "for a long time", even though
it only exists there because it was copy+pasted from grsecurity?  Is
that what we do now, credit plagiarists instead of the actual authors of
the work?  Sorry, but the "work" of struggling to understand code that
isn't yours doesn't suddenly make it your code.

https://lwn.net/SubscriberLink/724319/830a4de15663b8dd/
over a dozen mentions of various forms of "Cook's implementation"
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.

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

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?

This is your last warning.  This is not a new problem and it needs to
end completely, or I will make sure it ends.

-Brad


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [kernel-hardening] Stop the plagiarism

[Daniel Micay]

> "a value linux-hardened and grsecurity have used for a long time now"
> Rik, you're giving credit to a project that didn't even exist a couple
> weeks ago, yet they've somehow used it "for a long time", even though
> it only exists there because it was copy+pasted from grsecurity?

You're going out of the way to misinterpret that wording.

You don't document where changes came from in the PaX and grsecurity
patches. There's code written by other people in there, and there's
neither a Git repository crediting them in a commit history or with a
few exceptions inline credit given to those people. When I extract
something from the PaX or grsecurity patches or base code on the ideas
there, I can't state with certainty who authored the code. I've been
stating 'extracted from PaX' or 'extracted from grsecurity' for code not
part of PaX and documenting changes from the implementation there. Code
being from PaX or grsecurity isn't necessarily 'code authored by the PaX
Team or Brad Spengler'. It could be code written by Emese, minipli,
someone else who contributed code to you or a patch that you took from
elsewhere that was ignored / rejected by upstream. How is anyone else
supposed to know?

People were given credit in the original PaX changelogs at the top of
the patches in most cases but all but the latest patch for kernel
branches was taken down. Similarly, the grsecurity changelogs gave
credit but are all taken down and it's not like many people actually
looked at those at the time.

For example, the MODIFY_LDT sysctl in grsecurity is someone else's code.
It isn't stated in grsecurity where it came from. That's true to an even
larger extent when it comes to ideas rather than implementation. You
give credit to Willy Tarreau for NO_SIMULT_CONNECT but not that
MODIFY_LDT one, and I can think of a bunch of other examples.

It looks to me like people contributing these changes upstream have been
more consistently giving credit than the grsecurity patches do. When the
grsecurity patches are not mentioning who wrote changes or came up with
the idea how are people supposed to know who to credit... ? It applies
to an even larger extent to ideas rather than code. Most of the code and
ideas there are from the PaX Team and yourself, sure, but not all.

Maybe stop calling me a plagiarist when I'm trying my best to give
credit and actually do a better job than you do in practice.

>   Is
> that what we do now, credit plagiarists instead of the actual authors
> of
> the work?  Sorry, but the "work" of struggling to understand code that
> isn't yours doesn't suddenly make it your code.

These commits reference the PaX implementation there. You've told me to
stop doing that but rather reference the specific PaX version in the
future which I intend to do. 

https://github.com/thestinger/linux-hardened/commit/4c355f98910e01256ee2b01dd1a02ac08dd316b2.patch
https://github.com/thestinger/linux-hardened/commit/711e5650589c9d3c99706c6a5d52d2659519dc74.patch
https://github.com/thestinger/linux-hardened/commit/cd9cdbff4bc69d2e88b37d106e6ee8ef33a3a1b8.patch

The Linux kernel is GPL2 and grsecurity is a derivative work. I'm not
sure how it's plagiarism to tweak the upstream implementation of ASLR
based on the PaX implementation while describing the differences with
the PaX implementation which I'm trying to do in depth:

Making the stack entropy depend on the mainline mmap sysctl isn't based
on PaX and therefore doesn't reference it.

I needed to move the ET_DYN base on arm64 to 4G because the address
range overlapped when using the sysctl for the stack which I noticed in
testing. I then did x86_64 and the 32-bit architectures. I don't know
how the values were chosen in PaX and they don't meet the compatibility
requirements that I need on 64-bit where there are projects using 32-bit 
pointers by mapping certain things in the lower 32 bits of the address
space and they cannot necessarily cope with any fragmentation there.

https://gist.github.com/thestinger/b43b460cfccfade51b5a2220a0550c35

Re: [kernel-hardening] Stop the plagiarism

[Brad Spengler]

[-- Attachment #1: Type: text/plain, Size: 5619 bytes --]

commit 813d0df7042a8430481d245618cbab39b76876fc
Author: Brad Spengler <spender@grsecurity.net>
Date:   Sat Jul 25 11:28:15 2015 -0400

    Implement modify_ldt sysctl toggle from https://lkml.org/lkml/2015/7/25/103,
    make it not depend on CONFIG_MODIFY_LDT_SYSCALL, force modify_ldt to off
    regardless of config setting if grsec is enabled (with the allowance to
    turn it on at runtime), and harden up the implementation a bit
    
    Conflicts:
    
        arch/x86/Kconfig
        kernel/sysctl.c


It's right there in the changelogs (which you can still find online).  Here's a
google cache entry for the link:
https://webcache.googleusercontent.com/search?q=cache:2IlruFKV2RIJ:https://lkml.org/lkml/2015/7/25/103+&cd=1&hl=en&ct=clnk&gl=us
I did not and have never removed someone's copyright notice and added my
own to the copy+pasted code, as is the case of what's happening here
that I'm complaining about and that I had to complain about in the past
when Intel did it.

Unlike you and the KSPP, our security reputation isn't entirely based on
the work of others.  If properly crediting work is such a difficult problem
that you don't want to be bothered with, there's a very simple solution:
come up with your own ideas and write your own code!

-Brad

On Sat, Jun 03, 2017 at 09:53:47AM -0400, Daniel Micay wrote:
> > "a value linux-hardened and grsecurity have used for a long time now"
> > Rik, you're giving credit to a project that didn't even exist a couple
> > weeks ago, yet they've somehow used it "for a long time", even though
> > it only exists there because it was copy+pasted from grsecurity?
> 
> You're going out of the way to misinterpret that wording.
> 
> You don't document where changes came from in the PaX and grsecurity
> patches. There's code written by other people in there, and there's
> neither a Git repository crediting them in a commit history or with a
> few exceptions inline credit given to those people. When I extract
> something from the PaX or grsecurity patches or base code on the ideas
> there, I can't state with certainty who authored the code. I've been
> stating 'extracted from PaX' or 'extracted from grsecurity' for code not
> part of PaX and documenting changes from the implementation there. Code
> being from PaX or grsecurity isn't necessarily 'code authored by the PaX
> Team or Brad Spengler'. It could be code written by Emese, minipli,
> someone else who contributed code to you or a patch that you took from
> elsewhere that was ignored / rejected by upstream. How is anyone else
> supposed to know?
> 
> People were given credit in the original PaX changelogs at the top of
> the patches in most cases but all but the latest patch for kernel
> branches was taken down. Similarly, the grsecurity changelogs gave
> credit but are all taken down and it's not like many people actually
> looked at those at the time.
> 
> For example, the MODIFY_LDT sysctl in grsecurity is someone else's code.
> It isn't stated in grsecurity where it came from. That's true to an even
> larger extent when it comes to ideas rather than implementation. You
> give credit to Willy Tarreau for NO_SIMULT_CONNECT but not that
> MODIFY_LDT one, and I can think of a bunch of other examples.
> 
> It looks to me like people contributing these changes upstream have been
> more consistently giving credit than the grsecurity patches do. When the
> grsecurity patches are not mentioning who wrote changes or came up with
> the idea how are people supposed to know who to credit... ? It applies
> to an even larger extent to ideas rather than code. Most of the code and
> ideas there are from the PaX Team and yourself, sure, but not all.
> 
> Maybe stop calling me a plagiarist when I'm trying my best to give
> credit and actually do a better job than you do in practice.
> 
> >   Is
> > that what we do now, credit plagiarists instead of the actual authors
> > of
> > the work?  Sorry, but the "work" of struggling to understand code that
> > isn't yours doesn't suddenly make it your code.
> 
> These commits reference the PaX implementation there. You've told me to
> stop doing that but rather reference the specific PaX version in the
> future which I intend to do. 
> 
> https://github.com/thestinger/linux-hardened/commit/4c355f98910e01256ee2b01dd1a02ac08dd316b2.patch
> https://github.com/thestinger/linux-hardened/commit/711e5650589c9d3c99706c6a5d52d2659519dc74.patch
> https://github.com/thestinger/linux-hardened/commit/cd9cdbff4bc69d2e88b37d106e6ee8ef33a3a1b8.patch
> 
> The Linux kernel is GPL2 and grsecurity is a derivative work. I'm not
> sure how it's plagiarism to tweak the upstream implementation of ASLR
> based on the PaX implementation while describing the differences with
> the PaX implementation which I'm trying to do in depth:
> 
> Making the stack entropy depend on the mainline mmap sysctl isn't based
> on PaX and therefore doesn't reference it.
> 
> I needed to move the ET_DYN base on arm64 to 4G because the address
> range overlapped when using the sysctl for the stack which I noticed in
> testing. I then did x86_64 and the 32-bit architectures. I don't know
> how the values were chosen in PaX and they don't meet the compatibility
> requirements that I need on 64-bit where there are projects using 32-bit 
> pointers by mapping certain things in the lower 32 bits of the address
> space and they cannot necessarily cope with any fragmentation there.
> 
> https://gist.github.com/thestinger/b43b460cfccfade51b5a2220a0550c35

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [kernel-hardening] Stop the plagiarism

[Lionel Debroux]

[-- Attachment #1.1: Type: text/plain, Size: 2381 bytes --]

Hi Brad,

You're right to demand proper attribution for the hard work made by
the PaX Team, yourself, Emese, minipli, and other people involved into
the making of PaX + grsecurity. Though doing better than "extracted
from PaX/grsecurity" is less than straightforward in some (many?) cases.


But now that you uttered the nasty word "copyright" along with an
asserted will of enforcing yours... chances are that what you'll achieve
is lawyers at Intel, Google, the LF and friends freaking out and getting
in the way of mankind progress by ruining the day for techies (people
doing actual useful work, unlike them) and end users alike.
I mean: instead of pushing back and mandating proper attribution when
people attempt to mainline a more or less close derivative of your work,
they'll consider your organization as a _potential_ copyright troll,
your (plural) useful work - or features strongly inspired by it - as
_potentially_ toxic, and will therefore attempt to hamper its inclusion
to mainline, just in case...
Needless to say, that would further set back, for years, the security of
real-world Linux (that is: the Linux that most Linux-running computers
use, as opposed to a tiny set of computers running your commercial
PaX+grsecurity-patched Linux). At a time the main proprietary OSs, which
have other downsides, are upping their game wrt. self-defense...

BTW:
* even your organization is arguably hurt by the new patch availability
policy and now the displayed will to assert your copyright: for
instance, less mainlining work won't lower your work forward porting
the monster patch, and a narrower set of computers running your work
reduces the testing and bug reporting which users of the free patch
used to perform;
* it's absurdly counter-productive to reinvent a working wheel,
especially when said wheel is the byproduct of _many_ good ideas (so
coming up with more is harder) and a thoughtful cost / benefit risk
analysis.


Just my two cents. For once, I'm not interested into spending way too
much time on this non-technical discussion about a matter I think is
important; I just wanted to raise one of the bad, likely outcomes of
your _legitimate_ motives, and the actions that come out of these
motives.
I accept that I may be wrong on the consequences of both sides'
actions; time will tell.


Bye,
Lionel.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [kernel-hardening] Stop the plagiarism

[Matt Brown]

On 6/3/17 7:30 AM, Brad Spengler 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

I actually do not get paid to do this work. I was a happy user of your
patch while it was public. Now you took it away from the public and I'm
doing my small part to pick up the baton.

> 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.
> 
> Matt -- did you not see in the directory the Kconfig file was copy+pasted
> from the following:
> 
> # grsecurity - access control and security hardening for Linux
> # All code in this directory and various hooks located throughout the Linux kernel are
> # Copyright (C) 2001-2014 Bradley Spengler, Open Source Security, Inc.
> # http://www.grsecurity.net spender@grsecurity.net
> #
> # This program is free software; you can redistribute it and/or
> # modify it under the terms of the GNU General Public License version 2
> # as published by the Free Software Foundation.
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> # GNU General Public License for more details.
> #
> # You should have received a copy of the GNU General Public License
> # along with this program; if not, write to the Free Software
> # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
> 

I am sincerely sorry about this. It will be corrected in v2. Would you
like this license included in the Kconfig and tpe_lsm.c or just one of
them? I didn't see a license at the top of grsecurity/grsec_tpe.c so I
didn't know what to include.

> Yet you are claiming copyright entirely over my work.  Your copy+pasted
> Kconfig entry didn't even adjust for your renaming of my sysctl variables.
> Search+replace of config and function names is not transformative, and
> I dare to think how much of your tpe_lsm.c is copy+pasted from cormander's
> LSM.
> 
> I know it must be hard for the KSPP, having no original ideas of its

I am not a part of KSPP nor do my patches/comments reflect on them.

> own, but this is not security or development.  It's mindless plagiarism
> and illegal.  Then to slap your own copyright over the whole copy+pasted
> thing is a total insult and demonstrates the complete lack of respect
> KSPP has for the work it can't accomplish anything without.  The KSPP
> and the companies funding it wouldn't be able to show a shred of perceived
> progress were it not for its ability to simply copy+paste portions of
> our work, because every time you modify something you introduce bugs and
> new vulnerabilities, demonstrating your cluelessness.

Re: [kernel-hardening] Stop the plagiarism

[Daniel Micay]

On 3 June 2017 at 10:21, Brad Spengler <spender@grsecurity.net> wrote:
> commit 813d0df7042a8430481d245618cbab39b76876fc
> Author: Brad Spengler <spender@grsecurity.net>
> Date:   Sat Jul 25 11:28:15 2015 -0400
>
>     Implement modify_ldt sysctl toggle from https://lkml.org/lkml/2015/7/25/103,
>     make it not depend on CONFIG_MODIFY_LDT_SYSCALL, force modify_ldt to off
>     regardless of config setting if grsec is enabled (with the allowance to
>     turn it on at runtime), and harden up the implementation a bit
>
>     Conflicts:
>
>         arch/x86/Kconfig
>         kernel/sysctl.c
>
>
> It's right there in the changelogs (which you can still find online).  Here's a
> google cache entry for the link:
> https://webcache.googleusercontent.com/search?q=cache:2IlruFKV2RIJ:https://lkml.org/lkml/2015/7/25/103+&cd=1&hl=en&ct=clnk&gl=us
> I did not and have never removed someone's copyright notice and added my
> own to the copy+pasted code, as is the case of what's happening here
> that I'm complaining about and that I had to complain about in the past
> when Intel did it.

That's what I said: at one point, it was mentioned in a changelog
which was removed when grsecurity moved to the next major kernel
version along with other cases. The attribution wasn't made in the
patch and there isn't anything similar to the Linux kernel's Git
history providing a long-term attribution. Only changelogs that were
removed after each major release and are now entirely gone. It's as if
you've taken ownership of the code. A third party archive of your
changelogs hosted lesewhere and the fact that it can be found via a
search doesn't really change that there isn't attribution in the
patches either via available commit history or inline comments /
documentation. I'm not saying that wrong. I'm saying that you're
getting mad about something less than that.

A copyright header in a separate file is not exactly the same thing.
Lawyers like to have the headers in every file so it doesn't get lost
if a file is extracted / distributed alone, especially if people don't
look at the other files. It doesn't really work because it's normal to
move code around between files with different headers and to base code
on other files without copying headers back and forth everywhere,
which is definitely true for grsecurity. It's not as if there wasn't
attribution given. It's not attribution in the form you want and when
people do give you attribution you talk about them coasting on your
reputation or implying that their interpretation of the code is
comparable to where it came from. If they independently write the
features without using your code as a reference (KSTACKOVERFLOW vs.
VMAP_STACK, ARM memory domain PAN emulation), you're not happy with
that either. You simply don't think it's right for any features that
are in grsecurity to land upstream in any form. No matter how it
happens, you'll see it as wrong / plagiarism. If it's done entirely
separate from upstream (as it was in CopperheadOS), you've never had
an issue with it. You weren't truly interested in being paid to
upstream it yourself either, only to develop code downstream in a
massive out-of-tree patch set.

It was only a few years ago that you were arguing that upstream should
take these features from grsecurity. How was that supposed to happen
then?

> Unlike you and the KSPP, our security reputation isn't entirely based on
> the work of others.  If properly crediting work is such a difficult problem
> that you don't want to be bothered with, there's a very simple solution:
> come up with your own ideas and write your own code!

I don't do much Linux kernel work in the first place... that hasn't
been what I've worked on and I don't have a problem with crediting
you. You've only taken issue with a tweet where I said 'from PaX /
grsecurity' instead of clarifying that it came from the last publicly
available patch. Sending me a legal threat over that tweet was
ridiculous especially considering that the post linked to by that
thread of tweets even already did what you want: stating it's a
comparison with the last publicly available patch. You also took issue
with a stack canary fix which you're adamant must have come from PaX
but that's not what happened: it was noticed and fixed when adding a
zero byte there to match the earlier changes changing userspace junk
filling to zeroing and adding a zero byte to the heap canaries and
stack canaries in userspace.

And how is grsecurity not entirely based on the work of others i.e.
the Linux kernel, just as CopperheadOS is based on Android Open Source
Project and all of the baseline functionality and security model
provided by it?

It wasn't until I turned the CopperheadOS kernel change set into
linux-hardened for mainline that you had a problem with it and I doubt
you would have been against it if the intention wasn't to upstream any
of it and you weren't already mad at me simply for pointing out that
the USERCOPY useroffset/usersize feature exists along with the slub
free list XOR mangling, which I find ridiculous. It's it being
upstreamed that bothers you.

Re: [kernel-hardening] Stop the plagiarism

[Rik van Riel]

On Sat, 2017-06-03 at 07:30 -0400, Brad Spengler wrote:

> While I'm here:
> http://openwall.com/lists/kernel-hardening/2017/06/02/3
> 
> "a value linux-hardened and grsecurity have used for a long time now"
> Rik, you're giving credit to a project that didn't even exist a
> couple
> weeks ago, yet they've somehow used it "for a long time", even though

CopperheadOS has been around for a few years now, with
a hardened Linux kernel as one of its components.

> it only exists there because it was copy+pasted from grsecurity?  Is
> that what we do now, credit plagiarists instead of the actual authors
> of
> the work?  Sorry, but the "work" of struggling to understand code
> that
> isn't yours doesn't suddenly make it your code.

The actual code in my patch is different from the #ifdef
stuff in both linux-hardened and grsecurity. 

The only thing that is the same is an integer constant.

> This is exactly how your plagiarism works.

If I wanted to do plagiarism, I would have copied the
ugly-as-all-hell #ifdef magic from grsecurity. What
do you think would have happened if I had submitted
something like this to lkml?

#ifdef CONFIG_PAX_SEGMEXEC
#define ELF_ET_DYN_BASE         ((current->mm->pax_flags &
MF_PAX_SEGMEXEC) ? SEGMEXEC_TASK_SIZE/3*2 : TASK_SIZE/3*2)
#else
#define ELF_ET_DYN_BASE         (TASK_SIZE / 3 * 2)
#endif

#ifdef CONFIG_PAX_ASLR
#ifdef CONFIG_X86_32
#define PAX_ELF_ET_DYN_BASE     0x10000000UL

#define PAX_DELTA_MMAP_LEN      (current->mm->pax_flags &
MF_PAX_SEGMEXEC ? 15 : 16)
#define PAX_DELTA_STACK_LEN     (current->mm->pax_flags &
MF_PAX_SEGMEXEC ? 15 : 16)
#else
#define PAX_ELF_ET_DYN_BASE     0x400000UL

#define PAX_DELTA_MMAP_LEN      ((test_thread_flag(TIF_ADDR32)) ? 16 :
TASK_SIZE_MAX_SHIFT - PAGE_SHIFT - 3)
#define PAX_DELTA_STACK_LEN     ((test_thread_flag(TIF_ADDR32)) ? 16 :
TASK_SIZE_MAX_SHIFT - PAGE_SHIFT - 3)
#endif
#endif

Notice how the code in my patch does not look like that,
at all?

> This is your last warning.  This is not a new problem and it needs to
> end completely, or I will make sure it ends.

The grsecurity code you published is licensed under the
GPLv2. I would be happy to add your copyright in if I
ever copied around a larger piece of code, but most of
the time the code I end up submitting is a rewrite and
not a copy.

Re: [kernel-hardening] Stop the plagiarism

[Brad Spengler]

[-- Attachment #1: Type: text/plain, Size: 3571 bytes --]

> That's what I said: at one point, it was mentioned in a changelog
> which was removed when grsecurity moved to the next major kernel
> version along with other cases. The attribution wasn't made in the
> patch and there isn't anything similar to the Linux kernel's Git
> history providing a long-term attribution. Only changelogs that were
> removed after each major release and are now entirely gone. It's as if
> you've taken ownership of the code. A third party archive of your
> changelogs hosted lesewhere and the fact that it can be found via a
> search doesn't really change that there isn't attribution in the
> patches either via available commit history or inline comments /
> documentation. I'm not saying that wrong. I'm saying that you're
> getting mad about something less than that.

What are you talking about?  This is like complaining that we don't
have a single file containing all 16 years of history, some 400MB download
if someone wanted to see what the latest changes are.  That commit message
was in changelog-stable.txt which you can still find online in the various
historical git repos and it's still present in the 3.14 changelog that
customers have access to now.  You seem to be blaming your own laziness
on me -- it'd be like me complaining I have to use extra means to find
out who authored something prior to git history.  And now you want to
use your laziness as a reason to try to claim that you don't know what
the authorship is of some code you copy and paste, so you choose to take
credit for it yourself:
https://twitter.com/CopperheadOS/status/871017018010595328
Have you ever even contacted either of us when you were unsure or too
lazy to look it up?  I know the answer to that question, and you know
the answer to that question, so quit with the BS.

> comparison with the last publicly available patch. You also took issue
> with a stack canary fix which you're adamant must have come from PaX
> but that's not what happened: it was noticed and fixed when adding a
> zero byte there to match the earlier changes changing userspace junk
> filling to zeroing and adding a zero byte to the heap canaries and
> stack canaries in userspace.

Cryptomnesia I guess, you looked at every other line of PaX to rip out
stuff like:
https://github.com/thestinger/linux-hardened/commit/e63d5e4db605e74b2d9631219dd58301be484bd7
https://github.com/thestinger/linux-hardened/commit/93b646fed97b51e62cb48e0a25c2664cc2f86e0b
but totally never saw that line that's been there ever since SSP existed
in the kernel.  It also doesn't mesh with your lengthy excuse on github
when I pointed it out to you.  Are the above changes your own work too?


> And how is grsecurity not entirely based on the work of others i.e.
> the Linux kernel, just as CopperheadOS is based on Android Open Source
> Project and all of the baseline functionality and security model
> provided by it?

These false equivalences of yours are nonsense -- anyone can look at
https://github.com/thestinger/linux-hardened/issues
and see how utterly dependent you are.  You are comparing apples and
oranges because you need to to justify your existence.  You didn't
contribute a line of code to our work in 16 years and now you're trying
to make a name for yourself off our work and reputation.  But you just
make a fool of yourself when on one hand you're desperately copy+pasting
and on the other trying to pretend you don't depend on it, or that your
dependence on copy+pasting our work is somehow equivalent to building on
top of whatever version of Linux that exists.

-Brad

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [kernel-hardening] Stop the plagiarism

[Kees Cook]

(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@grsecurity.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

Re: [kernel-hardening] Stop the plagiarism

[Brad Spengler]

[-- Attachment #1: Type: text/plain, Size: 10742 bytes --]

On Sun, Jun 04, 2017 at 12:16:43AM -0700, Kees Cook wrote:
> (Hilariously, this email was detected as spam and never hit my inbox.
> Dug it out now...)

I'm glad you're taking this so seriously that you find it all hilarious.
It really sets a great example for the rest of the KSPP and demonstrates
the great deal of respect for the work your entire career has been based off.

> 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?
That might help, and also self-policing so that we don't need to be the
ones monitoring every commit and having to bring these issues up again
and again.  For the record, to my knowledge I don't know of anyone
who has contributed code to the KSPP who has emailed us to ask how to
do that attribution.  Copyright attribution is a legal mandate, questions
about how to do that are better suited for a lawyer.  Attribution of
ideas/"inspired" code etc is a moral issue (and this is where plagiarism
comes into play).

The problem is that there are two issues here, there's the use of
the grsecurity trademark and the verbatim lifting of code, use of ideas
and various other "inspiration".  Frankly, the KSPP code quality and
security understanding is so poor that I wish we weren't associated with
it in any way at all.  But since there's so much marketing happening
by KSPP-funding companies, we need to make sure that people understand
both where the original work comes from, the extent to which that work
is verbatim, and that we have nothing to do with the bugs and omissions
resulting from non-skilled non-security-expert understanding of that code.

As far as what would make us happy, something like this would be perfect,
especially if the changelog makes certain claims about larger features.
Obviously it's overkill for smaller changes, but since you asked:

Blah is verbatim/modified from Brad Spengler/PaX Team's code in the last
public patch of grsecurity/PaX based on my understanding of the code.  Changes
or omissions from the original code are mine and don't reflect the original
grsecurity/PaX code.

But if you also want to know how to attribute, there's the Linux kernel's
own DCO, which you and the rest of the KSPP are violating left and right.
Here are some select quotes:
"  If you are a subsystem or branch maintainer, sometimes you need to slightly
   modify patches you receive in order to merge them, because the code is not
   exactly the same in your tree and the submitters'. If you stick strictly to
   rule (c), you should ask the submitter to rediff, but this is a totally
   counter-productive waste of time and energy. Rule (b) allows you to adjust
   the code, but then it is very impolite to change one submitter's code and
   make him endorse your bugs. To solve this problem, it is recommended that
   you add a line between the last Signed-off-by header and yours, indicating
   the nature of your changes. While there is nothing mandatory about this, it
   seems like prepending the description with your mail and/or name, all
   enclosed in square brackets, is noticeable enough to make it obvious that
   you are responsible for last-minute changes.
"

"  Note that under no circumstances can you change the author's identity 
   (the From header), as it is the one which appears in the changelog.
"

"  The canonical patch message body contains the following:

   - A ``from`` line specifying the patch author (only needed if the person
     sending the patch is not the author).
"

"  From: Original Author <author@example.com>

   The ``from`` line specifies who will be credited as the author of the
   patch in the permanent changelog.  If the ``from`` line is missing,
   then the ``From:`` line from the email header will be used to determine
   the patch author in the changelog.
"

As far as I know, none of these rules have ever been followed for our code.
Further, the author field has been used in the past (eg. by James Bottomley)
as "proof" of our lack of authorship of code in the Linux kernel:
https://lwn.net/Articles/663629/
"
  > as for getting code upstream, how about you check the kernel git logs
  > (minus the stuff that was not properly credited)?
  jejb@jarvis> git log|grep -i 'Author: pax.*team'|wc -l
  1
  Stellar, I must say.
"

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

Did you not see:
https://lwn.net/Articles/724396/
https://lwn.net/Articles/724401/

> this LWN article being published. And as I already said, it's not
> misattributed. You're just willfully misreading it.

Clearly based on other comments other people found it misleading as well --
perhaps you are just in denial about how damaging this kind of stuff is?
As was mentioned there, you properly credited it, but others misattributed
it to you.  It'd be as if I backported an ext4 encryption patch, and then
LWN writes an article about "my" implementation and "my" code and "my" work.
You don't find that misleading at all?  Assuming you had seen the article,
would you have corrected it yourself, or would you act in the same way as
you've demonstrated with every other misattribution and misleading marketing
that benefits you and the KSPP and ignore it, expecting it to magically
resolve itself?  Because going forward those kinds of lies and damaging
claims are going to be resolved with lawsuits.  This has been going on
for almost two years now and forced us to remove the public patches
entirely because of all this nonsense to try to put and end to it, but
clearly no matter of complaining is stopping it, so we have no other
option left.

> your tired rants about how things should be done "better" are hollow.

Oh man, you're going to have a rude awakening soon -- hold that thought
for now ;)  Here's a hash of the title of the blog post (with newline):
a7c3bde4c22b57a3edc03d40f4228300e6a022a00eeaccedfc06b31e0d8a3743

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

Yes, as I mentioned above, it's due to two separate issues.  One is using
the grsecurity reputation as a crutch for your own ability and marketing
based off it, and the other is ensuring attribution of the original
ideas/code.  It seems pretty simple to me.

> grsecurity. Just ask arm64 system builders how useful grsecurity was
> for them.

Yeah just ask those same system builders how much they were willing
to pay for any arm64 work, Google included.  ARM64 is your hobby horse,
you like bringing it out as an example every chance you can get, because
it's the only example you can bring up of any original work being done.
I learned my lesson with my ARM work not to do any more free work for
that industry.

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

I don't just think they're bad, they are bad -- I explained what's wrong
with them.  How many dozen CVEs for VMAP_STACK are needed to prove it in
your mind?  Three? Four?  Also I tend not to believe people who post on
LKML about deep details of some code they looked at, who then try to claim
later that they never looked at it deeply:
https://lwn.net/Articles/692208/

As for the ARM PAN code, I'm glad you brought it up because it's time to
put the facts of this one to rest.

I do hope one day for the mystery to be solved of how a public mail from Google:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/365056.html
magically got responded to within 3 days with a patch ready:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/365662.html
mentioning prior private discussions (with Google?) and Catalin Marinas,
whom I had told explicitly of my ARM work (the LPAE TTBR0 trick, a bug
in marking sections read-only under LPAE, and the domain
implementation) in 3 emails on Jan 2nd 2013, Jan 3rd 2013, and Jan 21
2013, and then also followed up on Feb 19 2013 with a link to the ARM
KERNEXEC/UDEREF blog post.  Lo and behold, the patchset based on
private discussions with the person I directly shared the
implementation ideas with (and long after I had already presented on
them, published the code, and the detailed blog) appears without any
credit.  Perhaps caught the cryptomnesia bug that's been going around.

> You appear to be trying to bully people into not contributing to the
> upstream effort to make Linux more secure. Please stop.

You appear to be justifying plagiarism and copyright/trademark infringements
in the name of making 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.

I'm still going on "rants" because the KSPP as a whole continues to
surround itself with misleading marketing no member ever takes initiative
to correct, and continues to remove copyright notices and/or replace them
with someone else's.  A rant will be the least of your worries if this
continues, and as creator of the KSPP and effective figurehead/spokesperson
you'd be wise to start taking it seriously.

-Brad

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [kernel-hardening] Stop the plagiarism

[Brad Spengler]

[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]

> comparable to where it came from. If they independently write the
> features without using your code as a reference (KSTACKOVERFLOW vs.
> VMAP_STACK

This is demonstrably false given Andy's own public statements:
https://lwn.net/Articles/692208/

> ARM memory domain PAN emulation

As posted in the other message, I emailed directly with the person
solely credited for ideas for that work, detailing everything
exactly and linking to the blog post about it.  I leave it up to
others to decide if they think it's at all likely if during discussions
of the topic, it never came in the head of that person that they had
discussed this very exact same thing a few years prior, while coming
up with the same solution.

> an issue with it. You weren't truly interested in being paid to
> upstream it yourself either, only to develop code downstream in a
> massive out-of-tree patch set.

Where's the evidence?  The PaX Team gave permission for anyone to publish
any private contracts and financial terms of real offers made.  Where are
they?  I don't recall if you and I ever had a real discussion about
upstreaming where I laid out the (what should be obvious) concerns --
namely that given that we have limited time, any paid upstreaming work,
being largely a waste of time and non-technical in nature, would need to
also ensure the continuity of the actual technical grsecurity work
and allow us to expand our pool of available hours.  Otherwise there's no
possibility for stable funding to continue any work and no time to do it,
which is exactly the short-sighted thinking I had mentioned to Kees since
the very beginning of the KSPP.  It's pointless to rehash it at this point
since again as mentioned, there is no evidence whatsoever that the
companies funding KSPP ever made any real offers to fund the work.  That
decision was made long ago, and we're simply continuing our work and doing
what needs to be done to ensure it continues.  As a reminder, upstreaming
doesn't solve all problems, and grsecurity would need to continue to exist
regardless of any upstreaming efforts.  You need look no further at the
100 or so KSPP emails about a single-line TIOCSTI change that not one
user has complained about in years.

> available patch. Sending me a legal threat over that tweet was
> ridiculous especially considering that the post linked to by that

You missed a step in there in your public portrayal of private messages
(it's not the first time, but I don't expect much else from someone
who needs to cultivate an image to fool the public into assisting him
with code his business depends on to sell).  Instead of replying to
or acknowledging my initial simple mail, you went on IRC to joke about
it publicly with other people.

-Brad

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [kernel-hardening] Stop the plagiarism

[Hector Martin]

On 2017-06-04 21:49, Brad Spengler wrote:
> Instead of replying to
> or acknowledging my initial simple mail, you went on IRC to joke about
> it publicly with other people.

It's somewhat ironic that someone who repeatedly complains about his
limited amount of time precluding upstreaming work somehow finds time to
stealth-idle on IRC channels to find out when people are talking about him.

Brad, you've been setting yourself up for everything going on. Of course
if you make it as hard as possible for people to upstream your work,
people will make mistakes. Of course if you make it as hard as possible
for people to tease coherent authorship information from your monolithic
patch, people will have no clue who actually wrote the code. Of course
if you start blocking people randomly on Twitter, people will troll you
to see if they get blocked.

We're all grateful for your contributions to Linux security, but
grsecurity has gotten as far as it has in spite of your attitude, not
because of it. You took your toys and went home (or "passed the baton"
as you put it) and the community is doing exactly what you'd expect them
to: try to make as much sense of what you left them and stop relying on you.

"A single file containing all 16 years of history" is exactly what
everyone else uses. We have Git for a reason. Your choice not to open up
your development process is yours and yours alone, but it comes with
consequences. You can't deliberately make everyone else's life as hard
as possible and then complain that they aren't doing their "due
diligence". You can't pull down all your historical patchsets and the
expect people to piece together the attribution information from cached
sources or mirrors. I'm sure any legitimate mistakes you point out will
be fixed. Or you could, you know, actually make people's life easier.

As much as it may sound unbelievable to you, yes, some of the stuff in
grsecurity is actually trivial, and it's entirely reasonable for someone
else to have come up with materially the same solution independently.
You can't copyright an integer constant. There is little point in
arguing over copyright on whole-tree cleanup work; things like
converting to designated initializers aren't even, in my opinion
(IANAL), clear-cut copyrightable changes. And you can't copyright ideas,
so if someone reimplements a grsecurity feature without copying any of
the code, that's entirely fair game copyright-wise.

Honestly, I'm not entirely sure why I'm writing this, because with moves
like the GCC plugin licensing shenanigans and the general licensing
approach for grsecurity you've demonstrated that you're not above using
ridiculous (and in my opinion license-violating) legal contortions to
try to exert further control over usage of your software than the GPLv2
allows; software which wouldn't exist were it not for the upstream
codebase it's based on, and GPLed contributions from many others. But,
and recognizing the chances of you giving a damn are slim at this point,
I ask: can you please decide whether you're going to help the community
with this endeavor, or whether you're going to sit back and let people
figure things out the best they can? You can't have it both ways. Either
get involved in a positive manner, or please stop obstructing everyone
else's work. Throwing around the L-word is, at best, going to make
people dislike your approach even more, and, at worst, actively stifle
the improvement of Linux security.

P.S. I had to reboot my router a few months ago, so I no longer have the
old IP address that you had blocked from your web server. Feel free to
remove that iptables rule now and shave a microsecond or two off your
packet processing time.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

Re: [kernel-hardening] Stop the plagiarism

[Daniel Micay]

> Cryptomnesia I guess, you looked at every other line of PaX to rip out
> stuff like:

Searching for __read_only and categorizing them as ones requiring
pax_open_kernel and not requiring it != reading the entire patch set
line by line, and you have the timeline very wrong.

> when I pointed it out to you.  Are the above changes your own work
> too?

Clearly not, and they aren't submitted upstream like that. I've been
treating it as a scratch space for putting together changes to send
upstream and they haven't all had commit messages written. For the
__ro_after_init changes that I submitted, I wrote commit messages
stating which parts came from PaX. I'll write full commit messages
before pushing there from now on. I hadn't done it for those because I
wasn't finished and I couldn't yet write a commit message that I
wouldn't need to change later.

My knowledge of the SSP canary issue predates making linux-hardened or
being on bad terms from you.

> but totally never saw that line that's been there ever since SSP
existed
> in the kernel.  It also doesn't mesh with your lengthy excuse on
github
> when I pointed it out to you.  Are the above changes your own work
too?

I don't have total knowledge about what exists in PaX. I had no idea
that it made changes like effectively disabling the cr4 caching or
partially protecting page tables on x86 until recently. How would I know
that it made a one line change fixing that stack canary issue? I wasn't
familiar with the ASLR implementation then including the
pax_get_random_long function which it used as the fix.

And yes my "excuse" is consistent with what I said on GitHub. I became
of the stack canary issue when Jann Horn told me about it months ago. I
might have IRC logs from back then. I then assumed it was going to get
fixed and promptly forgot about it as I do with pretty much every other
specific bug. I noticed it again when making related changes in
CopperheadOS but: that's a 3.18 LTS kernel and 3.10 LTS kernels for
older devices, so it didn't occur to me than Jann might not have gotten
it fixed in master, and arm64 doesn't use the per-task canaries so I
didn't need to fix that or add the zero byte there yet. Not sure what is
so hard to understand about that. I noticed it still wasn't fixed when
first making linux-hardened by porting those changes ahead.

If I *had* done research into the issue to point to when it had been
first discovered by someone, I wouldn't have found PaX. You don't have
patches uploaded on the site from before the earliest mailing list post
that you pointed me at, which doesn't mention PaX.

It's a one line fix for a bug that barely even matters. I'm not sure why
it's so important to you that I do impossible historical research (you
don't have the patches uploaded, I don't see them anywhere else) to
figure out who to credit, and as I've pointed out it cannot be assumed
that a change in PaX is something to credit to you or pipacs rather than
a fix you picked up from a mailing list, even if I had access to those
earlier patches and had decided to go on a research expedition to fix a
minor bug.

If it was so important to you that you get credit for fixing the bug,
why didn't you submit it yourself? It was trivial to get it landed when
it was simply sent to the right people without needing any discussion.

> 
> > > And how is grsecurity not entirely based on the work of others
> > > i.e.
> > the Linux kernel, just as CopperheadOS is based on Android Open
> > Source
> > Project and all of the baseline functionality and security model
> > provided by it?
> 
> These false equivalences of yours are nonsense -- anyone can look at
> https://github.com/thestinger/linux-hardened/issues
> and see how utterly dependent you are.  You are comparing apples and
> oranges because you need to to justify your existence.  You didn't
> contribute a line of code to our work in 16 years and now you're
> trying
> to make a name for yourself off our work and reputation.  But you just
> make a fool of yourself when on one hand you're desperately
> copy+pasting
> and on the other trying to pretend you don't depend on it, or that
> your
> dependence on copy+pasting our work is somehow equivalent to building
> on
> top of whatever version of Linux that exists.
> 
> -Brad

The linux-hardened project was just created. The initial work is porting
existing hardening features to a mainline kernel split out as components
since that's the lowest hanging fruit: working towards parity with what
we already had before. Changes like slab canaries, SSP tweaks and
fortify aren't linux-hardened work, they existed in CopperheadOS for a
long time.

Re: [kernel-hardening] Stop the plagiarism

[Brad Spengler]

[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]

> It's somewhat ironic that someone who repeatedly complains about his
> limited amount of time precluding upstreaming work somehow finds time to
> stealth-idle on IRC channels to find out when people are talking about him.

And your evidence is what exactly? That sounds like a statement of fact rather
than opinion.  Have you considered that there might be others in whatever
channels those are that disagree with you and happen to mention to me
ridiculous things that are said about me in public?

> You can't copyright an integer constant. There is little point in
> arguing over copyright on whole-tree cleanup work; things like
> converting to designated initializers aren't even, in my opinion
> (IANAL), clear-cut copyrightable changes. And you can't copyright ideas,
> so if someone reimplements a grsecurity feature without copying any of
> the code, that's entirely fair game copyright-wise.

Point me to where I claimed "copyright" over an integer constant.  I also
even agree the designated initializers changes aren't copyrightable.  My entire
point was simply mentioning where those changes come from, which is a moral
issue in these cases, not a copyright issue -- I'm sorry if you think
not violating copyright means one doesn't engage in plagiarism; the bar for
copyright is terribly low.  Credit is something people do that respect the
work that they're copying.  Same as we're not *required* to credit people
who report bugs to us, but we respect their time and so it's something we've
always done.  Also since not crediting would give the impression that
particular issue was found via some internal audit, which would be misleading.

> Honestly, I'm not entirely sure why I'm writing this, because with moves
> like the GCC plugin licensing shenanigans and the general licensing
> approach for grsecurity you've demonstrated that you're not above using
> ridiculous (and in my opinion license-violating) legal contortions to
> try to exert further control over usage of your software than the GPLv2
> allows;

I don't know, maybe to draw more attention for yourself in a way that 
doesn't require doing any real work and dig yourself into a deeper hole 
with more libel that you'll be held accountable for later?

When you and comex started making your plugin licensing claims we 
contacted the FSF ourselves given how damaging such claims are 
(particularly given that a few of them are now included in Linux).  It 
has been nearly 4 months now and despite repeated follow-ups, I still 
haven't received anything back more than an automated reply.  Likewise 
regarding some supposed claims by RMS which were published last year by 
internet troll mikeeusa -- I have been trying since June 3rd of last 
year to get any response from him, but have been unable to.  So when you 
claim we're violating the GPL by releasing some GCC plugins under GPLv2,
is that a claim of fact you're making?  Because last I checked, you're
not a GCC copyright holder, only the FSF is, so you don't even meet the
minimum threshold of being a person anyone should care about or listen to
wrt this topic.  I think you'd be wise to stop talking, because we've really
had enough of it.

> P.S. I had to reboot my router a few months ago, so I no longer have the
> old IP address that you had blocked from your web server. Feel free to
> remove that iptables rule now and shave a microsecond or two off your
> packet processing time.

Don't worry about it, there's nothing for a "grateful" user like yourself
to download anymore.  Boy, if I had more "grateful" users like yourself
obsessed with harrassing us on Twitter, Reddit, and IRC so that they
can go around and paint themselves as some kind of victim, I wouldn't
know what to do with myself.

-Brad

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [kernel-hardening] Stop the plagiarism

[Hector Martin]

On 2017-06-04 23:44, Brad Spengler wrote:
> And your evidence is what exactly? That sounds like a statement of fact rather
> than opinion.  Have you considered that there might be others in whatever
> channels those are that disagree with you and happen to mention to me
> ridiculous things that are said about me in public?

That might well be the case, but honestly, things like [1] suggest
you're taking a particularly keen interest in the issue, regardless of
whether you personally idle in said channels or not. I mean, honestly,
if you're really that busy, why spend the time?

> I also even agree the designated initializers changes aren't copyrightable.

I'm glad we actually agree on this.

> My entire
> point was simply mentioning where those changes come from, which is a moral
> issue in these cases, not a copyright issue -- I'm sorry if you think
> not violating copyright means one doesn't engage in plagiarism; the bar for
> copyright is terribly low.

I wouldn't say the bar for copyright is "low", but indeed, it's fair to
point out where such changes came from (if they indeed came directly
from grsec and weren't just re-done; as mostly mechanical changes, it's
entirely expected that they could be). But this comes back to the issue
of making life easy for people. If you're offering nothing beyond your
legal obligations to the GPLv2, making your changes available only in a
format extremely inconvenient to be merged, and lacking fine-grained
attribution, why should people spend their time to meet more than their
bare minimum legal obligations to you in turn?

Ultimately, be nice to people and they'll have more of an incentive to
be nice to you. And an easier technical time getting the right info too.

> Credit is something people do that respect the
> work that they're copying.  Same as we're not *required* to credit people
> who report bugs to us, but we respect their time and so it's something we've
> always done.  Also since not crediting would give the impression that
> particular issue was found via some internal audit, which would be misleading.

To be fair, I was expecting you to credit me as an "infosec anklebiter"
in your changelog for my bug report, so kudos to you for actually
mentioning me by name in an otherwise passive-aggressive entry ;)

> I don't know, maybe to draw more attention for yourself in a way that 
> doesn't require doing any real work and dig yourself into a deeper hole 
> with more libel that you'll be held accountable for later?

Is this a legal threat?

> When you and comex started making your plugin licensing claims we 
> contacted the FSF ourselves given how damaging such claims are 
> (particularly given that a few of them are now included in Linux).  It 
> has been nearly 4 months now and despite repeated follow-ups, I still 
> haven't received anything back more than an automated reply.  Likewise 
> regarding some supposed claims by RMS which were published last year by 
> internet troll mikeeusa -- I have been trying since June 3rd of last 
> year to get any response from him, but have been unable to.

Well, if you're (potentially) violating someone else's license, it's no
surprise the might want to be cautious about replying outright...

Suffice it to say I've had better luck communicating with the FSF about
licensing issues.

> So when you 
> claim we're violating the GPL by releasing some GCC plugins under GPLv2,
> is that a claim of fact you're making?  Because last I checked, you're
> not a GCC copyright holder, only the FSF is, so you don't even meet the
> minimum threshold of being a person anyone should care about or listen to
> wrt this topic.  I think you'd be wise to stop talking, because we've really
> had enough of it.

Being a GCC copyright holder is only required to take *legal action* for
a licensing violation. It is not a requirement to point out a potential
licensing violation. I may not be a GCC copyright holder, but I am a
(minor) Linux kernel copyright holder, as well as heavily depend on both
pieces of software for my professional work and personal usage, and
therefore I have an interest in ensuring that upstream doesn't wind up
in a legal mess because grsecurity decided to license its plugins for
GPLv3'd GCC as GPLv2 in order to supposedly prevent their usage outside
of the kernel through a hilariously convoluted (and misinformed)
licensing hack involving libgcc usage and its exception clause.

And yes, I maintain that in my opinion this approach violates the GCC
license, and that upstream Linux therefore now contains a GCC license
violation, and that possibly nobody cares *in practice*, but that's
still really sad and should be fixed (and the only ways to fix it are
for you/PaX to relicense the code, or for it to be dropped and rewritten).

> Don't worry about it, there's nothing for a "grateful" user like yourself
> to download anymore.  Boy, if I had more "grateful" users like yourself
> obsessed with harrassing us on Twitter, Reddit, and IRC so that they
> can go around and paint themselves as some kind of victim, I wouldn't
> know what to do with myself.

Victim? Come on Brad, you know full well I'm only trolling you because
you troll everyone else[2]. I really don't mind the attitude; in my
case, I don't think it's hurting anyone but yourself. However, I do know
that your way of handling things has discouraged *other* people less
hardened against this kind of drama from working in infosec and Linux
security in particular, and that hurts the entire community. So, while I
invite you to keep being your usual self towards me, I would appreciate
it if you treated people who *haven't* poked fun at grsecurity on
Twitter nicely. There is no need to make a toxic atmosphere for the
community and for contributors who are just trying to help out.

[1] https://grsecurity.net/~spender/snakes.txt
[2] And I still think it's pretty funny that you could panic grsec with
'script /dev/null </dev/zero' as any user, and that the first bugfix
attempt was not tested and just made it worse.

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

Re: [kernel-hardening] Stop the plagiarism

[Brad Spengler]

[-- Attachment #1: Type: text/plain, Size: 3074 bytes --]

> And yes my "excuse" is consistent with what I said on GitHub. I became
> of the stack canary issue when Jann Horn told me about it months ago. I
> might have IRC logs from back then. I then assumed it was going to get
> fixed and promptly forgot about it as I do with pretty much every other
> specific bug. I noticed it again when making related changes in
> CopperheadOS but: that's a 3.18 LTS kernel and 3.10 LTS kernels for
> older devices, so it didn't occur to me than Jann might not have gotten
> it fixed in master, and arm64 doesn't use the per-task canaries so I
> didn't need to fix that or add the zero byte there yet. Not sure what is
> so hard to understand about that. I noticed it still wasn't fixed when
> first making linux-hardened by porting those changes ahead.

> 
> If I *had* done research into the issue to point to when it had been
> first discovered by someone, I wouldn't have found PaX. You don't have

You wouldn't have found PaX eh?

Here's some more history then:
From "months ago", October 2016:
https://patchwork.kernel.org/patch/9405499/
Here's a thread where Jann submitted the same patch as you, where he
mentions it's from PaX (just that PaX used pax_get_random_long()).
You participated in this thread, it's even in the reply context your
reply includes -- look for yourself.  Here's a direct link:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262143.html
Then you submitted it upstream and took credit for yourself:
https://marc.info/?l=linux-kernel&m=149390477311752&w=2

> You don't have
> patches uploaded on the site from before the earliest mailing list post
> that you pointed me at, which doesn't mention PaX.

There are no patches currently on the website that you can download at all,
does it mean it's fine to take credit for everything in PaX because of that?
Sorry but this is a really lame excuse.

You can agree that 2006 is < 2007 right?  I thought we had already
established that on github, but now you're claiming any amount of research
wouldn't have led to PaX.  So let me show you for future reference how
trivial this is:
https://github.com/linux-scraping/linux-grsecurity/blame/grsec-test/kernel/fork.c
ctrl+f get_random_long
note: "11 years ago" on the left
That took all of 10 seconds.

Again not that any of this matters, it's one of many stupid security
weaknesses upstream developers never cared to fix for years, but if
we're going to be making up stories as excuses, let's at least get it
right.  So can we agree it's a case of cryptomnesia, or at minimum you
remembered the facts wrong?

BTW while doing research I found:
http://linux-arm-kernel.infradead.narkive.com/mAf9QhdP/patch-1-5-random-stackprotect-introduce-get-random-canary-function
which credits "ascii armor" to execshield and PaX/grsecurity.
We've never done ascii armoring in PaX/grsecurity and the technique was
created by solar designer in 1997:
http://insecure.org/sploits/linux.libc.return.lpr.sploit.html
Exec Shield arrived at least 5 years later.

-Brad

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [kernel-hardening] Stop the plagiarism

[Daniel Micay]

On Sun, 2017-06-04 at 20:12 -0400, Brad Spengler wrote:
> > And yes my "excuse" is consistent with what I said on GitHub. I
> > became
> > of the stack canary issue when Jann Horn told me about it months
> > ago. I
> > might have IRC logs from back then. I then assumed it was going to
> > get
> > fixed and promptly forgot about it as I do with pretty much every
> > other
> > specific bug. I noticed it again when making related changes in
> > CopperheadOS but: that's a 3.18 LTS kernel and 3.10 LTS kernels for
> > older devices, so it didn't occur to me than Jann might not have
> > gotten
> > it fixed in master, and arm64 doesn't use the per-task canaries so I
> > didn't need to fix that or add the zero byte there yet. Not sure
> > what is
> > so hard to understand about that. I noticed it still wasn't fixed
> > when
> > first making linux-hardened by porting those changes ahead.
> > 
> > If I *had* done research into the issue to point to when it had been
> > first discovered by someone, I wouldn't have found PaX. You don't
> > have
> 
> You wouldn't have found PaX eh?

I'm stating that I wouldn't have found PaX as the origin, as I've said
several times. You linked me to an early mention from 2007 on a mailing
list after deciding to throw a fit about this on IRC. That mailing list
post from 2007 with a fix for this doesn't mention PaX.

> Here's some more history then:
> From "months ago", October 2016:
> https://patchwork.kernel.org/patch/9405499/
> Here's a thread where Jann submitted the same patch as you, where he
> mentions it's from PaX (just that PaX used pax_get_random_long()).
> You participated in this thread, it's even in the reply context your
> reply includes -- look for yourself.  Here's a direct link:
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262143.ht
> ml

He doesn't say it's *from* PaX. He states that the change is already in
PaX. My understanding then was that Jann found the problem. That's why I
talked to Jann about it when I stumbled on it again and noticed it
hadn't been fixed. As far as I was concerned, it was one of his bug
finds since that's what he does: finding bugs in the Linux kernel,
including ones that he reported to you for grsecurity features.

> Then you submitted it upstream and took credit for yourself:
> https://marc.info/?l=linux-kernel&m=149390477311752&w=2

I submitted that patch after talking to Jann about it again. I am not
'taking credit' for discovering anything by submitting a one line change
migrating it to get_random_long to the write people with a justification
for doing it. We both simply wanted to get a one line change fixing it
landed upstream.

The change in PaX isn't even the same thing: pax_get_random_long is not
a CSPRNG, get_random_long is a CSPRNG (since recently at least).

> > You don't have
> > patches uploaded on the site from before the earliest mailing list
> > post
> > that you pointed me at, which doesn't mention PaX.
> 
> There are no patches currently on the website that you can download at
> all,
> does it mean it's fine to take credit for everything in PaX because of
> that?
> Sorry but this is a really lame excuse.

I didn't take this change from PaX. What actually happened != an excuse.

I'm also simply not going to do deep research into whether someone else
has made tiny changes like this before. I didn't do any research into
whether anyone had previously fixed the assorted buffer overflows that
needed to be fixed for FORTIFY_SOURCE either. I'm not concerned with
whether someone else found one of those bugs before and didn't get a fix
for it landed upstream. If I'm actually using their fix for it, I'll
credit them for it.

I'm pointing out that if for some reason I HAD felt like wasting my time
doing research into it, Google wouldn't have found what you're pointing
to. At best I would have found the mailing list post you showed me.

> You can agree that 2006 is < 2007

Sure, but I don't agree that there's any relevance to who actually found
this bug first. What if someone found it even earlier than PaX and
suddenly shows up here claiming that? Is that relevant? No. The fix
didn't come from them, and it didn't come from PaX.

If you were so concerned about getting credit for this, you could have
gotten the bug fixed upstream.

> established that on github

No, we didn't. You also deleted your GitHub account so I wasn't able to
look back at what you said anymore. I have no idea what you said there.
I remember you saying PaX fixed it in January 2007 and then it seems
someone else found and fixed it independently later in 2007.

> wouldn't have led to PaX.  So let me show you for future reference how
> trivial this is:
> https://github.com/linux-scraping/linux-grsecurity/blame/grsec-test/ke
> rnel/fork.c
> ctrl+f get_random_long
> note: "11 years ago" on the left
> That took all of 10 seconds.
>
> Again not that any of this matters, it's one of many stupid security
> weaknesses upstream developers never cared to fix for years, but if
> we're going to be making up stories as excuses, let's at least get it
> right.  So can we agree it's a case of cryptomnesia, or at minimum you
> remembered the facts wrong?

I'm not making excuses, lying, or forgetting why I was aware of this.

It's fine if you don't believe me and you want to believe that there was
a conspiracy to steal credit for this from you.

> BTW while doing research I found:
> http://linux-arm-kernel.infradead.narkive.com/mAf9QhdP/patch-1-5-rando
> m-stackprotect-introduce-get-random-canary-function
> which credits "ascii armor" to execshield and PaX/grsecurity.
> We've never done ascii armoring in PaX/grsecurity and the technique
> was
> created by solar designer in 1997:
> http://insecure.org/sploits/linux.libc.return.lpr.sploit.html
> Exec Shield arrived at least 5 years later.
> 
> -Brad

I've never written a commit message referencing 'ascii armor' or 'exec
shield'. Not something that's ever been on my radar, unlike glibc using
the leading zero byte for the SSP canary even on 32-bit.

Re: [kernel-hardening] Stop the plagiarism

[Daniel Micay]

> migrating it to get_random_long to the write people with a 

s/write/right/

Which is why Jann's submission of a patch earlier didn't land despite it
being really clearly cut, and I really have no idea about any previous
attempts. I have no interest in researching any previous attempts to get
it fixed and guessing at why those never landed. You care who found and
fixed it first, I didn't, so I didn't look into it. That doesn't mean I
wanted credit for fixing it. I would have been happier if Jann, Kees or
Riel had submitted it instead since it's less to deal with.

It needed to be fixed before masking out one of the bytes so I made yet
another fix for it and submitted it.

When you showed up on IRC mad at me, I thought it was about the
__ro_after_init changes which referenced PaX so I couldn't understand
what you were talking about because *I didn't take this change from PaX
like those ones*. Apparently quite hard to understand.

Re: [kernel-hardening] Stop the plagiarism

[Pavel Labushev]

[-- Attachment #1: Type: text/plain, Size: 5725 bytes --]

On Sun, 4 Jun 2017 00:16:43 -0700
Kees Cook <keescook@chromium.org> wrote:

Hello, Kees.

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

Did you actually ask people, i.e. the broader audience on the internet,
about their perception of the "crediting" done that way? Ever wonder if it
really fulfills its purpose, and why LWN articles, like the one linked
above, misattribute the code and ideas even further?

> You seem to be arguing semantics, rather than credit?

Let's see.

[quoted from the patch description]
> This is heavily based on the "__read_only" portion of the KERNEXEC
> infrastructure

"Heavily based" is ambiguous here. It's not clear if your patch set is just
inspired by KERNEXEC, or is it e.g. mostly a copy-paste.

[quoted from the LWN article]
> a mechanism based on similar functionality that exists in the
> PaX/grsecurity patch set

Don't you see how vague wording in the first place have turned it into a
"Cook's implementation"? Now it's not "heavily based", but just "based on
similar functionality".

This "evolution of meaning" doesn't end there. People will and do come up
with wonderful guesses that the original PaX/Grsecurity implementation had
some significant flaws that prevented it from upstreaming as is, and that
you have accomplished a great deal of work on actually fixing it, as in
re-implementing it properly.

Btw, instead of writing lengthy emails to defend yourself, you could spend
that time on writing more specific and correct patch set descriptions in
the first place and/or on speaking up publicly to prevent further spread of
misattribution of the code and ideas.

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

The "personal attack", as you call it, consists of some valid points
that you just chose to downplay and ignore.

The most important one is misunderstanding of how the original PaX code
works. It is a major issue, in case you actually care about improving Linux
kernel security, not just your job security.

> And as I already said, it's not misattributed. You're just willfully
> misreading it.

Wording like "Cook's implementation" is ambiguous enough to interpret it in
many ways, willfully or not. And the surrounding (con)text, as well as your
patch set description in the first place, doesn't make it clear enough which
interpretation is the right one.

Also, people on the internet do misattribute the work when they read such
vague descriptions and their further "variations". And unless you deny that
fact, Brad is totally in his right to be furious.

> Make up your mind about how you want grsecurity attributed and maybe
> people will actually do it "right".

Could you point to some particular case of the conflicting requirements,
that you seem to imply there are?

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

That is another concern, independent of the misattribution. And your
emotionally colored description of it is far from being accurate, to say
the least. Even though you're pretty much familiar with the opinions and
facts behind it, aren't you?

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

The circumstances that make the proper crediting a somewhat difficult task
didn't emerge by themselves. After all, it's *your* decision to do the work
in a hurry, without gaining in-depth understanding of the code (not before,
not after). So it's no wonder that the results are of questionable quality.
And it's no wonder if Brad doesn't want his work, reputation or trademark
to be tainted by any unnecessarily broad associations with the security
theatre going on.

If only you and KSPP in general could be more rigorous and consistent in
following the declared goals, there would be so much less ground for the
controversies.

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

Speaking of arm64, should you be reminded about when and why development of
grsec on ARM has been effectively stopped, by intention?

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

It doesn't seem so. Nothing prevents people from contributing as long as
they're being careful with the copyright statements.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [kernel-hardening] Stop the plagiarism

[Kees Cook]

On Sun, Jun 4, 2017 at 4:43 AM, Brad Spengler <spender@grsecurity.net> wrote:
> On Sun, Jun 04, 2017 at 12:16:43AM -0700, Kees Cook wrote:
>> (Hilariously, this email was detected as spam and never hit my inbox.
>> Dug it out now...)
>
> I'm glad you're taking this so seriously that you find it all hilarious.
> It really sets a great example for the rest of the KSPP and demonstrates
> the great deal of respect for the work your entire career has been based off.

I am taking it seriously, and I've been quite clear about the respect
I have for PaX Team and your work. I found it ironically funny that
automated spam systems hid a very important email from me for almost a
day. There's no need to read malice into everything.

Of similar dark humor is the laughable proposition you can claim
credit for my entire career. I genuinely wonder if you're able to
write an email without personal attacks.

>> Perhaps a more prominent FAQ entry is needed on the KSPP Wiki?
>
> That might help, and also self-policing so that we don't need to be the
> ones monitoring every commit and having to bring these issues up again
> and again.  For the record, to my knowledge I don't know of anyone
> who has contributed code to the KSPP who has emailed us to ask how to
> do that attribution.  Copyright attribution is a legal mandate, questions
> about how to do that are better suited for a lawyer.  Attribution of
> ideas/"inspired" code etc is a moral issue (and this is where plagiarism
> comes into play).

Well, as I've shown repeatedly, I don't think I've screwed this up. As
for the self-policing, that's something I've encouraged people to do
(see the link I sent). It does appear to be insufficient, and, while
it seems highly redundant to me since both projects are Open Source,
I've still added a section to the Wiki about it, so it'll be easier to
point out to people:

http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Get_Involved

> As far as what would make us happy, something like this would be perfect,
> especially if the changelog makes certain claims about larger features.
> Obviously it's overkill for smaller changes, but since you asked:
>
> Blah is verbatim/modified from Brad Spengler/PaX Team's code in the last
> public patch of grsecurity/PaX based on my understanding of the code.  Changes
> or omissions from the original code are mine and don't reflect the original
> grsecurity/PaX code.

I've added this to the Wiki as well (linked above), please double
check that you're happy with the wording. I will update my own pending
patches to update their commit logs to include this.

> But if you also want to know how to attribute, there's the Linux kernel's
> own DCO, which you and the rest of the KSPP are violating left and right.
> Here are some select quotes:
> "  If you are a subsystem or branch maintainer, sometimes you need to slightly
>    modify patches you receive in order to merge them, because the code is not
>    exactly the same in your tree and the submitters'. If you stick strictly to
>    rule (c), you should ask the submitter to rediff, but this is a totally
>    counter-productive waste of time and energy. Rule (b) allows you to adjust
>    the code, but then it is very impolite to change one submitter's code and
>    make him endorse your bugs. To solve this problem, it is recommended that
>    you add a line between the last Signed-off-by header and yours, indicating
>    the nature of your changes. While there is nothing mandatory about this, it
>    seems like prepending the description with your mail and/or name, all
>    enclosed in square brackets, is noticeable enough to make it obvious that
>    you are responsible for last-minute changes.
> "
>
> "  Note that under no circumstances can you change the author's identity
>    (the From header), as it is the one which appears in the changelog.
> "
>
> "  The canonical patch message body contains the following:
>
>    - A ``from`` line specifying the patch author (only needed if the person
>      sending the patch is not the author).
> "
>
> "  From: Original Author <author@example.com>
>
>    The ``from`` line specifies who will be credited as the author of the
>    patch in the permanent changelog.  If the ``from`` line is missing,
>    then the ``From:`` line from the email header will be used to determine
>    the patch author in the changelog.
> "
>
> As far as I know, none of these rules have ever been followed for our code.
> Further, the author field has been used in the past (eg. by James Bottomley)
> as "proof" of our lack of authorship of code in the Linux kernel:
> https://lwn.net/Articles/663629/
> "
>   > as for getting code upstream, how about you check the kernel git logs
>   > (minus the stuff that was not properly credited)?
>   jejb@jarvis> git log|grep -i 'Author: pax.*team'|wc -l
>   1
>   Stellar, I must say.
> "

Okay, so I would take this to mean you would like folks doing
grsecurity upstreaming to add the body "From:" line (i.e. git
"Author:") to patches? I see a variety of problems with this, but
mainly that the Author and first Signed-off-by line are supposed to
match, and "forging" someone's S-o-b sounds like a _terrible_ idea to
me. That would indicate that the "author" had actually sent such a
patch upstream, followed DCO, etc, and that would not be true. No one
should be forging Author/S-o-b. The DCO exists specifically to allow a
Linux kernel developer to assert that they have the right to send the
code in question (i.e. copy it from a compatibly licensed project).

If you want to send code, and if I modified it before commit, then
yeah, I'd already be following all these guidelines. Just go look at
my commit history in the kernel. I do the square-brackets thing, I
obviously retain S-o-b chains and original Author fields, etc. That's
just normal kernel development practices.

So, what exactly are you asking to be changed with regard to following the DCO?

I'd like to make sure you're happy about the attribution and
copyright, but you've repeatedly sent mixed signals for years now. For
example: I list specifically all the changes made to some
implementation vs the grsecurity one, and PaX Team tells me it's too
much detail and I shouldn't do it. I give credit _without_ mentioning
the implementation changes and you tell me it is so "broken" that you
don't want grsecurity associated with the results.

As I currently understand it, the paragraph from your last email that
I've added to the KSPP Wiki is the middle ground you are okay with?

>> > 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?
>
> Did you not see:
> https://lwn.net/Articles/724396/
> https://lwn.net/Articles/724401/
>
>> this LWN article being published. And as I already said, it's not
>> misattributed. You're just willfully misreading it.
>
> Clearly based on other comments other people found it misleading as well --
> perhaps you are just in denial about how damaging this kind of stuff is?
> As was mentioned there, you properly credited it, but others misattributed
> it to you.  It'd be as if I backported an ext4 encryption patch, and then
> LWN writes an article about "my" implementation and "my" code and "my" work.
> You don't find that misleading at all?  Assuming you had seen the article,
> would you have corrected it yourself, or would you act in the same way as
> you've demonstrated with every other misattribution and misleading marketing
> that benefits you and the KSPP and ignore it, expecting it to magically
> resolve itself?  Because going forward those kinds of lies and damaging
> claims are going to be resolved with lawsuits.  This has been going on
> for almost two years now and forced us to remove the public patches
> entirely because of all this nonsense to try to put and end to it, but
> clearly no matter of complaining is stopping it, so we have no other
> option left.

I don't do marketing. I didn't write this article. I don't understand
why you conflate all these things together. I believe I'm clear in my
commit logs. Would this article have been different if I'd used your
credit paragraph wording? I don't have the time to run around
correcting every misunderstood thing written about this kind of work.
I know you view this as a moral failing on my part, but usually by the
time I even see these kinds of articles, there is already a huge
thread of people discussing the inaccuracies, etc; my voice would be
redundant. I'm not a liar, and I'm not misleading anyone. I've been
clear and concise, and I remain dedicated to giving credit to
grsecurity as much as I can.

One area that I think may confuse people is the level to which some
code needs to be refactored for upstreaming. A lot of it tends to be
moving things around and renaming stuff to be acceptable upstream
(e.g. moving heap object checking routines out of fs/exec.c into
mm/usercopy.c), so comparisons can be complicated, but I've always
tried to minimize this so it is as easy as possible to compare it
against grsecurity (and to make your own forward porting easier,
though you refuse to discuss even that with me). Feature extraction
from a monolithic patch with no public git history can be pretty
awkward, and while I have become familiar with it, not everyone
quickly understands the resulting patches, even though I try to
specify what has changed between my patches and grsecurity.

>> 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.
>
> Yes, as I mentioned above, it's due to two separate issues.  One is using
> the grsecurity reputation as a crutch for your own ability and marketing
> based off it, and the other is ensuring attribution of the original
> ideas/code.  It seems pretty simple to me.

I'm not using grsecurity's reputation, I'm using grsecurity's code.
You may have a low opinion of my abilities, but this project with many
contributors have actually had some success in bringing more defensive
technologies into the Linux kernel. Some of it is code from
grsecurity, some of it is ideas from grsecurity, some of it is new
code and new ideas.

>> grsecurity. Just ask arm64 system builders how useful grsecurity was
>> for them.
>
> Yeah just ask those same system builders how much they were willing
> to pay for any arm64 work, Google included.  ARM64 is your hobby horse,
> you like bringing it out as an example every chance you can get, because
> it's the only example you can bring up of any original work being done.
> I learned my lesson with my ARM work not to do any more free work for
> that industry.

I use that example because it's definitive. There are other examples,
but I tend to avoid mentioning them to you since I assume you will
freak out when I talk about KASLR. :) I know you think it's garbage,
but I don't, and others don't, and so people spend time on it.

>> 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.
>
> I don't just think they're bad, they are bad -- I explained what's wrong
> with them.  How many dozen CVEs for VMAP_STACK are needed to prove it in
> your mind?  Three? Four?  Also I tend not to believe people who post on
> LKML about deep details of some code they looked at, who then try to claim
> later that they never looked at it deeply:
> https://lwn.net/Articles/692208/

This has been discussed ad nauseam before. The upstream Linux kernel
has totally different engineering and development practices than
grsecurity. Without VMAP_STACK, the vulnerabilities associated with
non-vmap kernel stacks existed in upstream and how many very
general-purpose CVEs affected the kernel (and would have continued to
affect the kernel)? Too many. But Andy was able to do the
implementation (I can't speak to his lack of crediting the idea to
grsecurity, you'll have to ask him). With this implementation in
place, now those kernel stack exploit methods are dead. If the cost
was an ever diminishing number of very specific CVEs, then that's
where we are. Upstreaming is a balancing act. You can criticize it all
you want, but it's the reality of how Linux development works.

> As for the ARM PAN code, I'm glad you brought it up because it's time to
> put the facts of this one to rest.
>
> I do hope one day for the mystery to be solved of how a public mail from Google:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/365056.html
> magically got responded to within 3 days with a patch ready:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/365662.html
> mentioning prior private discussions (with Google?) and Catalin Marinas,
> whom I had told explicitly of my ARM work (the LPAE TTBR0 trick, a bug
> in marking sections read-only under LPAE, and the domain
> implementation) in 3 emails on Jan 2nd 2013, Jan 3rd 2013, and Jan 21
> 2013, and then also followed up on Feb 19 2013 with a link to the ARM
> KERNEXEC/UDEREF blog post.  Lo and behold, the patchset based on
> private discussions with the person I directly shared the
> implementation ideas with (and long after I had already presented on
> them, published the code, and the detailed blog) appears without any
> credit.  Perhaps caught the cryptomnesia bug that's been going around.

If what you're saying is true, then, yeah, it's disappointing that the
ideas weren't credited. But from that same thread, here I am, trying
to make sure grsecurity got noticed:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/366046.html

The resulting thread certainly gives some insight into the long
(usually acrimonious) relationship between grsecurity and upstream,
but I don't feel I was contributing to that; I think I've always tried
to help people find a middle ground. And for my troubles I get nothing
but personal attacks from you.

>> You appear to be trying to bully people into not contributing to the
>> upstream effort to make Linux more secure. Please stop.
>
> You appear to be justifying plagiarism and copyright/trademark infringements
> in the name of making Linux "more" secure.  Please stop.

After all the evidence to the contrary, why do you continue to feel this way?

I really do genuinely want to have you be happy with how pieces of
grsecurity get upstreamed, but you've persistently berated and mocked
the resulting code compromises, which has made that goal basically
impossible. :(

> I'm still going on "rants" because the KSPP as a whole continues to
> surround itself with misleading marketing no member ever takes initiative
> to correct, and continues to remove copyright notices and/or replace them
> with someone else's.  A rant will be the least of your worries if this
> continues, and as creator of the KSPP and effective figurehead/spokesperson
> you'd be wise to start taking it seriously.

I haven't surrounded KSPP with any marketing. That a patch set gets
"PR" attention or not has nothing to do with me or KSPP. Yes, I'm
going to talk about KSPP in public, but I don't think I've ever
misrepresented anything about the project or the work. I just want
people to be aware of it, understand its goals, purpose, and
limitations, and to be inspired to help out.

And like I've said, usually by the time some article or other thing
has been noticed by me, all the corrections are well under way. I'm
sure it'll sound like a hollow excuse from me, but I don't have
infinite time. If that'll be my failing here, so be it. Luckily there
are plenty of other people that notice these things and correct them.

But at least we have one thing we can agree on: the copyright removal
thing was especially bad. Intel screwed that up before, and it's
happened again here with what Matt sent. Those have been objective
(and rare) mistakes. I think neither were motivated by malice, more
like self-imposed legal formalities combined with there being such
little experience copying between GPL projects where one project is a
single patch file with a copyright notice in a subdirectory Makefile.
(Which is an explanation, not an excuse.)

For what it's worth, Intel's mistake never made it to Linus's tree,
and you noticed Matt's before I'd read through the patches in any
detail (which were also no where near being committed upstream). So,
while it really seems to me like this sort of thing should have been
obvious, I called it out specifically in the Wiki (linked above).

-Kees

-- 
Kees Cook
Pixel Security

[kernel-hardening] Re: Stop the plagiarism

[Jonathan Corbet]

On Sun, 4 Jun 2017 07:43:21 -0400
Brad Spengler <spender@grsecurity.net> wrote:

> > this LWN article being published. And as I already said, it's not
> > misattributed. You're just willfully misreading it.  
> 
> Clearly based on other comments other people found it misleading as well --
> perhaps you are just in denial about how damaging this kind of stuff is?
> As was mentioned there, you properly credited it, but others misattributed
> it to you.  It'd be as if I backported an ext4 encryption patch, and then
> LWN writes an article about "my" implementation and "my" code and "my" work.
> You don't find that misleading at all?  Assuming you had seen the article,
> would you have corrected it yourself, or would you act in the same way as
> you've demonstrated with every other misattribution and misleading marketing
> that benefits you and the KSPP and ignore it, expecting it to magically
> resolve itself?  Because going forward those kinds of lies and damaging
> claims are going to be resolved with lawsuits. 

Given that you're so concerned with attribution, it seems a little
strange that you're trying to blame Kees for an LWN article.  He had
nothing to do with it; I wouldn't be surprised to learn that he'd rather
it had never been written. The responsibility for that article lies with
the author and, ultimately, with me for choosing to publish it.  You know
where to find me; talk to me if you are unhappy with our work.

For the record, I believe the article does attribute the work correctly.
Could it have been done better?  Almost certainly so.  Future articles in
this area will receive the sort of extra attention we reserve for a small
list of land-mine topics that always explode when we tread near them.  We
will try to ensure that you'll have nothing to complain about in that
area, though I doubt we'll be able to improve your low opinion of us in
general.

What we will not do, though, is ignore the credit for the substantial
work of making these patches upstreamable and dealing with the process to
get them merged — the work you have explicitly chosen not to do.  It is
not an easy job to get this work upstream, and, by the time it happens,
the result is not solely your work.

jon