you mean the one that he had to fix like 3 times?
> which *only* touch mm/memory.c
right, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... (and let's not get started how bloody crap this whole 'solution' is, just look at the hacks like this commit introduces and high-five for not using an easily changeable define for the gap size)
> and none of the arch specific files.
with due respect to Andrea's efforts, there was really no need to touch arch specific code, one can get away with patching expand_downwards, get_unmapped_area and mprotect or so these days.
> So the issue is still, if AA had the right idea, but the wrong approach back in 2004
it's still the right idea and approach (the userland managed guard page brought up in the original discussion is easy to handle).
> Once a compelling case was presented,
that happened in 2004-2005 already (not saying people weren't aware of the problem many years before that though).
> Linus seems to have put effort into implementing an elegant fix
it's a butt-ugly hack he couldn't even get right the first time (where was the lkml discussion before committing it btw? oh right, there wasn't).
> so how does that mean *his* priorities are screwed up
5 years of ignoring the problem (not that it was only him) implies 'screwed up' in my book. certain big commercial companies get grilled for spending a fraction of that time on a security fix.
> Was the security community nagging LKML about this issue that whole time?
ask your firstname.lastname@example.org and/or vendor-sec contacts for their 2005 archives and you'll see the discussion take place then.
PS: there's some irony in mm/nommu.c still having an unused heap_stack_gap variable.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds