The "rare write" mechanism

Posted Jun 2, 2017 0:22 UTC (Fri) by PaXTeam (guest, #24616)
Parent article: The "rare write" mechanism

Dear LWN editors,

can we please stop with these bullshit plagiarism based articles? most if not all of the code attributed to Kees in the article is basically mine (he said so himself in the very post you linked to), pointless renaming and introduced bugs aside.

The "rare write" mechanism

Posted Jun 2, 2017 0:25 UTC (Fri) by corbet (editor, #1) [Link] (3 responses)

Dear PaX Team: The provenance of the code in question is clearly described in the article itself. It is, meanwhile, development work that is relevant to the kernel development community and worthy of coverage. No bullshit, no plagiarism. No stopping.

The "rare write" mechanism

Posted Jun 2, 2017 1:08 UTC (Fri) by PaXTeam (guest, #24616) [Link] (2 responses)

Dear Jon,

you can't say you weren't warned. some specific examples of apparently wilfully misattributed authorship claims:

> Cook's implementation contains architecture-specific code that relies on CPU features on x86 and ARM that selectively
> enable and disable write access to areas of memory.

the x86 specific code is mine, not his.

> Cook noted that his code is inlined [...]

again, it's my code which he copied.

> Cook's newly introduced __wr_rare annotation[...]

it's my __read_only attribute.

> Cook gave a simple example of the usage of the single rare_write() call by converting a function in net/core/sock_diag.c from:

it's my code too.

> Cook's implementation of the rare write functions on x86 became the following:

it's all my code.

The "rare write" mechanism

Posted Jun 2, 2017 7:02 UTC (Fri) by itvirta (guest, #49997) [Link] (1 responses)

> the code is mine, not his.

I think there might be more appropriate forums for copyright infringement claims than comments on a news site.

The "rare write" mechanism

Posted Jun 2, 2017 13:02 UTC (Fri) by madscientist (subscriber, #16861) [Link]

No one is talking about copyright infringement (which is good, since that's not a valid claim). What's being discussed is attribution, and in particular attribution in the article (not attribution in the patches). I think the comments section of the article is a valid place to discuss that. I have no opinion on the merits.

The "rare write" mechanism

Posted Jun 2, 2017 1:39 UTC (Fri) by jeff_marshall (subscriber, #49255) [Link] (11 responses)

PaXTeam,

The article seems to point this out in a straightforward (to me) manner:

> Kees Cook proposed such a mechanism based on similar functionality that exists in the PaX/grsecurity patch set

What would you propose that the LWN editors do differently?

The "rare write" mechanism

Posted Jun 2, 2017 10:09 UTC (Fri) by ballombe (subscriber, #9523) [Link] (10 responses)

Just write 'The implementation' instead of 'Cook implementation' etc.

The "rare write" mechanism - attribution

Posted Jun 4, 2017 0:44 UTC (Sun) by giraffedata (guest, #1954) [Link] (9 responses)

If the code is largely copied from the PaX/grsecurity patch set, saying that Cook proposed a mechanism based on functionality (or function) in that patch set is inadequate. That says to me original code that does something similar to what the PaX/grsecurity code does.

If it's basically code copied with some renaming, and Cook said so in the talk as PaXTeam says, then "based on code in the PaX/grsecurity patch set" or "derived from code ..." would be less misleading, if not, "largely copied from ..."

The "rare write" mechanism - attribution

Posted Jun 5, 2017 7:00 UTC (Mon) by jospoortvliet (guest, #33164) [Link] (8 responses)

I can't judge the merits either but when I read the article my impression is that most of the code is written by Cook, merely inspired by the work pax did. If, in reality, 80-90% is copied from PAX and the patch is essentially a port and perhaps clean-up of PAX code to the current kernel I suggest the wording is indeed flawed.

The "rare write" mechanism - attribution

Posted Jun 6, 2017 3:17 UTC (Tue) by flussence (guest, #85566) [Link] (7 responses)

I can understand how something like that might be overlooked. If grsecurity wasn't de-facto proprietary anyone could do a diff instead of having to assume paxteam is once again acting in bad faith.

The "rare write" mechanism - attribution

Posted Jun 6, 2017 10:56 UTC (Tue) by PaXTeam (guest, #24616) [Link] (1 responses)

yeah man, makes one wonder where Kees could have possibly copied my code from if it was 'proprietary'. if you are unable to tell then Kees/LWN failed at properly attributing the origin of my code so complain to them instead of spewing ad hominem. of course, a smart cookie such as yourself could have also just looked at the test patch collection linked from, wait for it, the PaX homepage but then assuming that you failed to do that so that you can justify going on an irrelevant diatribe would be bad faith, wouldn't it? ;)

The "rare write" mechanism - attribution

Posted Jun 6, 2017 17:32 UTC (Tue) by likryol (guest, #115542) [Link]

Why can't you (validly) point out that your code is easily available without attacking people? Your stance here is right, but the tone and delivery (on both sides of the argument to be fair) is why there is friction.

The "rare write" mechanism - attribution

Posted Jun 6, 2017 11:05 UTC (Tue) by minipli (guest, #69735) [Link] (4 responses)

The relevant code from the PaX Patch for v4.9.24 looks astonishingly similar to Kees' proposal, no?
So, now, please tell me this is not just a poor rip-off with minor bikeshedding applied!?

The "rare write" mechanism - attribution

Posted Jun 6, 2017 11:21 UTC (Tue) by tao (subscriber, #17563) [Link] (1 responses)

"Based on PaX's x86 pax_{open,close}_kernel() implementation, this
allows HAVE_ARCH_RARE_WRITE to work on x86."

I find it hard to say that it lacks proper attribution though.

The "rare write" mechanism - attribution

Posted Jun 26, 2017 9:33 UTC (Mon) by jospoortvliet (guest, #33164) [Link]

I believe that that wasn't disputed, Kees properly credited. The article, however, seems to suggest he wrote the code, merely inspired by the PAX feature, which is clearly not the case.

The "rare write" mechanism - attribution

Posted Jun 6, 2017 11:24 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

You say "a poor rip-off with minor bikeshedding": anyone else would say "changes of the sort routinely needed for upstreaming which PaXTeam is unwilling to do". If that makes a "poor rip-off", then the *entire kernel* is a "poor rip-off", which makes it odd that grsecurity is based on it. (This is a general problem with the grsecurity position: if the kernel is so all-around terrible and run by thieves, scoundrels, liars, incompetents and scum as they constantly claim, why on earth are they using it as a basis for their work? Perhaps because it's not anywhere near as bad as all that after all. Further, if it's thievery to take the grsecurity work and modify and upstream it, why on earth is it not thievery for grsecurity to take the kernel and modify it, particularly if they then accompany the result with contracts that try to restrict its further distribution? I mean, yes, both are legally permissible, but if I look for scurrilous behaviour here I do not see it in the kernel maintainers. Oh noes, they're giving people's work a wide audience and all you have to do in exchange for this is act like a decent human being!)

The "rare write" mechanism - attribution

Posted Jun 6, 2017 18:53 UTC (Tue) by minipli (guest, #69735) [Link]

It's a "poor rip-off" simply because Kees' code is broken. It introduces a Dirty COW alike bug and, ironically enough, this time brought to you by the team making Linux "more secure" -- well, not quite, in this case. ;)

This is just a prime example that they don't understand what they're copying. How would such an approach gain Linux security in any sensible way? It's always the bloody details that count -- that little corner case that also needs to be taken care of to make a security feature complete. But so far KSPP has just copy-pasted PaX/grsec code without fully understanding the interconnections with other features and code changes. I'd say, they need to slow down and start reading the whole thing, trying to understand what they just read and repeat -- until no new "Ahhh!" moments appear any more. What happens now isn't much more than a grep 'n sed over the patch without understanding what those hunks really do -- what other changes they need the grep didn't catch.