PaXTeam
2. sure but then this means that RETGUARD is not an improvement over Stackguard/SSP which is not how it's marketed...
3. shared means that entities of a class (threads in a process in userland, every single process/thread in the kernel) see the exact same cookies so leaking a cookie from one entity can allow exploitation by another. this is especially detrimental to the kernel side protection. frequent enough cookie rerandomization can help narrow this channel (RAP has a per-thread cookie in the kernel that is updated on each syscall, and there's some more to reduce infoleaks across kernel stacks, it's all in the presentation).
4. any normal path leading up to the ret is a gadget and int3 stuffing does nothing to prevent that (the underlying logic here is that if one can retarget a return to arbitary addresses then he has already leaked enough information so bypassing the cookie check is a no-brainer too). not only that but in the bsd.mp kernel i just checked, of the 32199 ret (0xc3) bytes only 20236 are actual retn insns, the rest are inside insns. so this int3 stuffing leaves many other instances available. Red Hat tried similar gadget elimination a while ago but noone's using the gcc feature as far as i can tell.
1. if they can't find a register to load the cookie into, they'll silently skip instrumentation (i'm not sure how that would happen in practice but the silent treatment when omitting a security feature is a non-starter).
2. if they can find such a register then it'll be spilled to the stack and restored in the epilogue, so a normal buffer overflow can control both the xor'd retaddr and the retaddr itself and the only thing standing in the way of exploitation is the secret cookie value - not unlike with Stackguard/SSP.
3. one would think that a per-function cookie is an improvement but... they're shared among threads (in userland) or everything (in the kernel) so infoleaks are just as catastrophic as before (it'd certainly help if someone described a proper threat model for this defense). at least the kernel side should use a per-syscall cookie to make it somewhat resemble an actual defense mechanism (and there's some more described in my presentation).
4. the int3 stuffing before retn must be someone's joke 'cos it sure as hell won't prevent abusing the retn as a gadget. it does introduce a mispredicted branch for every single function return however.
vs.
>>and the source of those numbers is...? >GregKH, who you linked in a cousin comment.
the article i linked to has neither number.
> An employer pays you to solve technical problems that rise from their business
not at all. an employer pays for stuff it can't get done for free. it's basic economics at least but i'm sure some shareholders would also have trouble understanding why the company would waste money that way. you just admitted that you'd gladly do the same work for free yet you somehow failed to tell that to your employer who are thus paying you for something that they could get for free and spend that money on other important things instead. that's doubly damaging to your employer.
> Let me ask you a question. [...]
it doesn't have to be a security bug and it doesn't have to come from a customer, we look at them with the same attention and priority regardless. money has nothing to do with it, we do it (and we have done so since the beginning) whether we're paid or not. i think you just have a hard time imagining that what customers pay for isn't R&D (though we're open to such contract work too).
> That statement doesn't say "developed for free" it says "provided for free".
yes and it's disingenous as to be able to provide linux 'for free' someone has had to pay for it which is very different from our situation.
> I don't agree that there isn't a significant proportion of development that is not paid[...]
you're arguing semantics ('significant' vs 'majority') with Greg at this point, i'll let you two work it out.
> I don't lend credence to hypothetical predictions about how Linux would be developed without anyone being paid.
fortunately you don't need to predict anything, just compare the code of linux 1.0 and 4.11.
> Despite what you say, Linux was developed for free for the first year or so and was mostly > developed for free for several more years.
i never said anything like that unless of course you can quote me back on it.
anyway, you're clearly more interested in insults and ad hominem than a rational discussion, so you can have the last word.
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 goalposts and point at a different article that i can't have guessed before you posted it.
> Maybe that's not the case in Hungary, but that is the case in America (and Australia where I am).
it's not necessarily the case there either. i had worked in both countries and always negotiated contracts that wouldn't have such overreaching clauses.
> I mean, Linux kernel development worked in this way for the first several years when it started.
exactly and you can see how much (or little, in this case) that achieved vs. what money did when it started to pour in. it's not at all hypothetical that if currently paid developers were stopped getting paid then the current pace of development would stop to a crawl (related example: look at gcc vs. clang/llvm after google/etc moved their developers from one to the other). easy test: would you continue to work on linux with the same pace/effort if your company stopped paying you for it? yes/no? if you answer yes then i also expect you to pay them back any past salaries you cheated out of them ;).
> Both Linux and grsecurity were developed for some time without direct income sources from most contributors.
in our case, it's not 'some time' but 'all the time'. that's the big difference which puts the original statement into a very different light:
> Meanwhile the kernel upon which their work is built has been provided for free for much longer
that 'for free' isn't at all free (money makes it happen) unlike our volunteer project (money doesn't make it happen).
> The majority of developers are paid for their work[...].
that's not at all true for our case, that's all i pointed out.
> I'm a maintainer of container runtimes at my current job but I have > contributed code to Linux as part of my job.
if it's on company time (and thus dime) then yes, it's a paid job.
> 14% of changesets and 13% of lines changed are by people not associated with a company.
not really, more than half of each is 'unknown', so you can't tell one way or another. anyway, not sure what these are supposed to prove/disprove given what Greg himself said in the above quote.
> It's like you're not willing to acknowledge that the only reason someone would pay a two-person > team for support on a kernel technology like grsecurity+PaX is that the same team is developing it.
indeed it's not the only reason but since it's not your business (no offense meant just stating a fact), i can't comment on this further. what i did mean however is something different than the direction you veered off: our work isn't developed because it's paid for, it's a completely volunteer free time project (spender has a day job unrelated to this work, and until about a year ago i didn't have any at all in fact). that is, if you took the money out of the picture, our work would still continue to live on as it has for the previous 16 years. that is absolutely not true for upstream linux development (if it were then all these companies have been cheated out of their money they spent on developer salaries).
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 commits vs patches, all commits are patches + description, but we use those terms interchangebly in the linux world with this understanding. in any case, i stand by what i said, we develop our code the same way upstream linux (or really any sane project) does. we're just not developing it for the purpose of inclusion, maybe that's the source of your confusion.
> 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 our free time. what the company is for is customer support, not R&D. shocked you are? :)
as for your satire, it's just got one thing wrong, but that kinda kills the rest of it: we never said "take it if you want it" and thus we never embarked on the rest of that journey.
> The problem is that getting things into small individually testable components > is literally anathema to the Pax/grsecurity model.
nowhere does this talk about what the patch looks like. it talks about "getting things into small individually testable components" being "literally anathema to the Pax/grsecurity model". i.e., that decomposing the monolithic patch into composable pieces is somehow against our development model whereas said monolithic patch was developed exactly this way (which means the reverse process would reproduce these 'testable components'). that argument (my statement) directly contradicts Jeff's so only one of them can be true and as the author of the code in question i know which one is what ;).
as for invasiveness, you're only stating the obvious that there're more and less complex pieces of code yet both kinds (well, all kinds in the complexity spectrum really) can make it into the kernel. that is, this argument cannot be used against incorporating grsec on its own.
you're wrong, see item 6 in https://opensource.com/article/16/12/yearbook-9-lessons-25-y... though you might want to demand that Greg prove his identity first ;).
> And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam?
sure, come visit me in hungary and i'll take you to the local tax authorities and grant you access to my files. of course you'll have to prove your own identity first ;).
no, you're wrong. how do you think we developed our code? did all the 8+ MB worth of it pop out of our head all at once? or more realistically, did we develop the features piece by piece, not unlike how upstream linux is developed?
> They have very specific "chunks" of functionality which are quite invasive, by design.
define invasive. linux itself has 'quite invasive' features too yet that didn't prevent them from being developed and upstreamed, so not sure what you were trying to imply here.
> This goes against the model the Linux kernel is developed, so the two development > communities are simply mutually exclusive.
this narrative only exists in your head, not in reality. our work is as much upstreamable as any other kernel code that went in over the years (how else do you think some of it could get in already?), it's just that it can't be done in one's free time.