1. both insertReturnProtectorPrologue and insertReturnProtectorEpilogue check hasReturnProtectorTempRegister before proceeding with the instrumentation. so either the changes to calculateSaveRestoreBlocks are not enough…
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…
> 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…
> 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 the…
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…
> 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?…
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…
careful there, the author line doesn't imply authorship (if it does, the upstream kernel is already violating our copyrights).
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…
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…
> 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... though you might want to demand…
> 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…
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…
i think you're 'quite obviously' wrong ;).
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?
1. both insertReturnProtectorPrologue and insertReturnProtectorEpilogue check hasReturnProtectorTempRegister before proceeding with the instrumentation. so either the changes to calculateSaveRestoreBlocks are not enough…
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…
> 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…
> 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 the…
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…
> 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?…
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…
careful there, the author line doesn't imply authorship (if it does, the upstream kernel is already violating our copyrights).
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…
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…
> 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... though you might want to demand…
> 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…
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…
i think you're 'quite obviously' wrong ;).
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?