PaXTeam

4 ms·

1.
by PaXTeam 8y ago
1. both insertReturnProtectorPrologue and insertReturnProtectorEpilogue check hasReturnProtectorTempRegister before proceeding with the instrumentation. so either the changes to calculateSaveRestoreBlocks are not enough to prevent that cond
2.
by PaXTeam 8y ago
this is basically the xor canary approach originally pioneered by the Stackguard guys (i'm pretty sure you were already around at the time though probably forgot such old history as did the rest of the world apparently ;). the OpenBSD
3.
by PaXTeam 9y ago
> Sorry, I assumed that 80% and 86% were close enough that a reasonable reader would be able > to see that I had mis-remembered the second significant figure for statistics I heard a while ago. vs. >>and the source of those numb
4.
by PaXTeam 9y ago
> Sorry, it's 86% and 14% in Linux 4.11. It's literally in the link I posted. you first quoted 80% and chided me for not reading the article linked to because it supposedly implied/had it in there. now you're moving t
5.
by PaXTeam 9y ago
can you quote Greg back on your "At most 80% of Linux contributors have jobs at software companies" because i don't see it in there? and you can add the source for your 20% while at it. on the other hand what Greg did say is
6.
by PaXTeam 9y ago
> 1000 small commits can add up to 100 small+simple components vs. > Commits might be patches, but they're sure not components. make up your mind, are components (whatever that means for you) composed of commits or not? :) as for
7.
by PaXTeam 9y ago
and the source of those numbers is...? > As for grsecurity, 100% of the core grsecurity team (that work at "Open Source Security") are paid for their work. that's 100% false. both spender and me are developing our code in
8.
by PaXTeam 9y ago
careful there, the author line doesn't imply authorship (if it does, the upstream kernel is already violating our copyrights).
9.
by PaXTeam 9y ago
i don't quite get what you're arguing now... are you stating that when there're functional dependencies between components, we should somehow ignore them when incorporating them into a larger piece? say, the kernel should get
10.
by PaXTeam 9y ago
i don't think you read carefully what i replied to so here's it again: > The problem is that getting things into small individually testable components > is literally anathema to the Pax/grsecurity model. nowhere does t
11.
by PaXTeam 9y ago
> What do you mean, the Linux kernel isn't developed for free? Many contributors aren't paid. you're wrong, see item 6 in https://opensource.com/article/16/12/yearbook-9-lessons-25-y... thou
12.
by PaXTeam 9y ago
> The problem is that getting things into small individually testable components > is literally anathema to the Pax/grsecurity model. no, you're wrong. how do you think we developed our code? did all the 8+ MB worth of it po
13.
by PaXTeam 9y ago
what, do you have 'real evidence' that we're the same person? if so i'd like to see it and also know how we pulled off our appearance at H2HC a few years ago. let me guess, we must have hired actors and bought them fake
14.
by PaXTeam 9y ago
i think you're 'quite obviously' wrong ;).
15.
by PaXTeam 9y ago
you conveniently forgot to mention the fundamental difference: the upstream kernel isn't developed for free whereas our code has always been. changes the equation quite a bit, doesn't it?