Date: Tue, 6 Jun 2017 00:43:01 +0700 From: Pavel Labushev <pavel.labushev@...box.no> To: kernel-hardening@...ts.openwall.com Subject: Re: Stop the plagiarism On Sun, 4 Jun 2017 00:16:43 -0700 Kees Cook <keescook@...omium.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. Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.