This Post was deleted by the Post author.
I don't agree with the assumptions underlying that question, to me it suggests that if I were to read somewhere about some bug report, since it wasn't directly made to the particular author, there's nothing at all wrong with me claiming or implying the finding as my own
This Post was deleted by the Post author.
Well these aren't particularly important issues, we don't talk about the important ones ;) It's more of an interesting experiment to see what happens with the information once it's out in the wild. I point out the credit issue merely because it is a constant theme
1
That said, I think it's fine for people to unwittingly do Google's LLVM plugin bidding without pay (that it should be funding itself) but there's a bit of hubris involved to assume you considered all the things in a particular security implementation that the original authors did
1
I was reminded recently when trying to look for references of the pervasiveness of PaX's ASLR for instance that it seems that if you don't speak up, someone else will rewrite history for you in their or someone else's favor: security.cs.rpi.edu/courses/… security.cs.rpi.edu/courses/…
3
1
6
Well, while *ASLR* was first publicly implemented by PaX, memory layout randomization was also discussed before ASLR. Even though their not the same, one might think that was a step towards PaX ASLR.
2
1
AKA PaX both coined and implemented ASLR, so what's the gripe? Why should PaX not be discussed in the history of the very thing they created? I think the point you're missing is that there's a reason ASLR is being used and not other academic approaches discussed around the time.
1
2
9
None of this was controversial at all years ago, this seems to be a contrived argument from people either too young to know or too ignorant of history and wanting to create some alternate history for some reason. I don't know which, but it's getting old.
2
I see you mentioning ALSR but not the claim that i'm actually refering to: PaX saying he deserves credit for CFI. pax-future.txt has *some* ideas, not all. You see what I'm trying to say?
3
you should read a bit more than just that one doc. there's pax.txt for a start which defined the very exploit (and thus defense) categories that we now take for granted. e.g., out-of-intended-order execition -> code reuse/*OP, in-intended-order execution -> data only attacks.

Mar 21, 2019 · 11:06 PM UTC

1
I have read pax.txt many times and I'm aware of the generic PaX threat model. But I don't see how that relates to what I'm talking about here.