Messages in this thread | | | From | pageexec@freemail ... | Date | Mon, 06 Jun 2011 20:59:39 +0200 | Subject | Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule |
| |
On 6 Jun 2011 at 16:44, Ingo Molnar wrote: > * pageexec@freemail.hu <pageexec@freemail.hu> wrote: > > > > > Seriously. The whole patch series just seems annoying. > > > > what is annoying is your covering up of security fixes on grounds > > that you don't want to help script kiddies (a bullshit argument as > > it were) but at the same time question proactive security measures > > (one can debate the implementation, see my other mail) that would > > *actually* prevent the same kiddies from writing textbook exploits. > > You are mixing up several issues here, and rather unfairly so.
but it's very simple logic Ingo. it goes like 'I am not willing to do A because it would help script kiddies but I'd rather do B that would help script kiddies'. with A = 'disclose security bugs' and B = 'keep the last roadblock that prevents full ASLR'.
if someone's that worried about script kiddies as Linus claims to be (which i always called a BS argument, but let's accept here), he can't possibly argue for keeping the vsyscall page at a fixed address around, simple as that.
and it is for security, no other reason, else you'd have to accept a patch that maps the vdso at a fixed address again or come up with some very convincing arguments why the vdso must stay randomized but the vsyscall page is fine at a fixed address (i guess neither is forthcoming but you guys can act in surprising ways, so i'm not placing any bets ;).
> Firstly, see my other mail, there's an imperfect balance to be > found between statistical 'proactive' measures and the incentives > that remove the *real* bugs.
i hope i replied to this already now to your satisfaction else feel free to elaboarte.
> Secondly, *once* a real security bug has been found the correct > action is different from the considerations of proactive measures.
as i said already, you're mixing up fixing bugs and fighting exploit techniques. apples vs. oranges.
> How can you possibly draw equivalence between disclosure policies > and the handling of statistical security measures?
see the simple logic above.
| |