The "rare write" mechanism

Posted Jun 2, 2017 1:39 UTC (Fri) by jeff_marshall (subscriber, #49255)
In reply to: The "rare write" mechanism by PaXTeam
Parent article: The "rare write" mechanism

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.