linux-kernel - Re: [regression] Re: brk randomization breaks columns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Feb 2008 08:05:46 -0500
From:	Jakub Jelinek <jakub@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jiri Kosina <jkosina@...e.cz>, Pavel Machek <pavel@....cz>,
	Andrew Morton <akpm@...l.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	kernel list <linux-kernel@...r.kernel.org>,
	Abel Bernabeu <abel.bernabeu@...il.com>,
	Hugh Dickins <hugh@...itas.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [regression] Re: brk randomization breaks columns

On Tue, Feb 05, 2008 at 01:54:26PM +0100, Ingo Molnar wrote:
> * Jiri Kosina <jkosina@...e.cz> wrote:
> 
> > On Tue, 5 Feb 2008, Pavel Machek wrote:
> > 
> > > > Actually, this clearly shows that either prehistoric libc.so.5 or the 
> > > > program itself are broken.
> > > I believe it shows clear regression in latest 2.6.25 kernel.
> > 
> > I am still not completely sure. It might be a regression, but it also 
> > might just trigger the bug in ancient version in libc.so.5 which might 
> > be fixed in some later version [...]
> 
> which too is a regression ...
> 
> really, lets add a sysctl for this, and a .config option that either 
> disables or enables it. Then we will default to disabled. (but users can 
> enable it - and distros can build their kernels with this .config option 
> enabled)

I don't think kernel should care about programs which are buggy and make invalid
assumptions, and that's the case here.  I remember we have been through this
5 years ago when brk randomization has been added to Red Hat kernels.  There was
one or two broken programs which made assumptions on what brk(0) is supposed
to return at program startup, everything else was ok.
For the buggy apps there is always setarch i386 -R ./the_buggy_program
so I don't think we need to add another sysctl for this.

	Jakub
--
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/