[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150102222936.GA29018@amd>
Date: Fri, 2 Jan 2015 23:29:36 +0100
From: Pavel Machek <pavel@....cz>
To: Richard Weinberger <richard@....at>
Cc: Kees Cook <keescook@...omium.org>,
LKML <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
David Rientjes <rientjes@...gle.com>,
Aaron Tomlin <atomlin@...hat.com>,
DaeSeok Youn <daeseok.youn@...il.com>,
Thomas Gleixner <tglx@...utronix.de>, vdavydov@...allels.com,
Rik van Riel <riel@...hat.com>,
Oleg Nesterov <oleg@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>,
Andy Lutomirski <luto@...capital.net>,
Brad Spengler <spender@...ecurity.net>
Subject: Re: [PATCH] [RFC] Deter exploit bruteforcing
On Fri 2015-01-02 22:40:14, Richard Weinberger wrote:
> Am 02.01.2015 um 20:46 schrieb Pavel Machek:
> >>> Does this break trinity, crashme, and similar programs?
> >>
> >> If they fork() without execve() and a child dies very fast the next fork()
> >> will be throttled.
> >> This is why I'd like to make this feature disabled by default.
> >>
> >>> Can you detect it died due to the stack canary? Then, the patch might
> >>> be actually acceptable.
> >>
> >> I don't think so as this is glibc specific.
> >
> > Can the slowdown be impelmented in glibc, then?
>
> glibc has a lot of asserts where it can detect stack smashing and kills the
> current process using abort(). Here it could of course also call
> sleep().
Please do it in glibc, then.
> > If not, can glibc provide enough information to the kernel to allow us
> > to do the right thing?
>
> IMHO we should not strictly focus on the stack canary.
IMO we should. We want it enabled by default.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists