On Tue, 5 Feb 2008 23:35:27 +0100 (CET) Jiri Kosina wrote:
> On Tue, 5 Feb 2008, Arjan van de Ven wrote:
>
> > the combo of a config option + sysctl sounds the right way forward then
> > ;(
>
> OK, so I propose the one below (unested yet, but should be trivial). Does
> anyone have any objectio
On Tue, 5 Feb 2008, Arjan van de Ven wrote:
> the combo of a config option + sysctl sounds the right way forward then
> ;(
OK, so I propose the one below (unested yet, but should be trivial). Does
anyone have any objections?
From: Jiri Kosina <[EMAIL PROTECTED]>
ASLR: add possibility for mo
On Tue 2008-02-05 17:09:13, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > From: Jiri Kosina <[EMAIL PROTECTED]>
> > >
> > > brk: check the lower bound properly
> > >
> > > There is a check in sys_brk(), that tries to make sure that we do not
> > > underflow the area
Hi!
> > . Yes, setarch i386 -R /usr/local/bin/uemacs (etc) fixes them, too.
> >
> > What about this?
> >
> > Heap randomization breaks /lib/libc.so.5.4.33, make it possible to
> > randomize normal stuff but leave the heap alone.
>
> certainly looks fine to me, but please also add a .config
On Tue, 5 Feb 2008, Pavel Machek wrote:
> Sorry, I now tested the patch. It looked good to my untrained eyes, but
> upon testing it on columns:
> ...
> personality(PER_LINUX) = 4194304
> geteuid() = 1000
> getuid()= 10
Hi!
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 8295577..1c3b48f 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -241,7 +241,7 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
>
> down_write(&mm->mmap_sem);
>
> - if (brk < mm->end_code)
> + if (brk < mm->start_brk)
>
On Tue 2008-02-05 08:58:41, Arjan van de Ven wrote:
> On Tue, 5 Feb 2008 16:46:48 +0100
> Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > Hi!
> >
> > > > In my usual dither, I'm rather hoping Arjan will have a clear
> > > > answer.
> > >
> > >
> > > setarch works. If the apps come in source form
On Tue, 5 Feb 2008 16:46:48 +0100
Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > In my usual dither, I'm rather hoping Arjan will have a clear
> > > answer.
> >
> >
> > setarch works. If the apps come in source form they need fixing
> > anyway (since I'd not be surprised of current gcc r
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > > 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 ...
> > >
>
On Tue 2008-02-05 08:05:46, Jakub Jelinek wrote:
> On Tue, Feb 05, 2008 at 01:54:26PM +0100, Ingo Molnar wrote:
> > * Jiri Kosina <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 5 Feb 2008, Pavel Machek wrote:
> > >
> > > > > Actually, this clearly shows that either prehistoric libc.so.5 or the
> >
On Tue 2008-02-05 13:50:51, Jiri Kosina 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 s
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > From: Jiri Kosina <[EMAIL PROTECTED]>
> >
> > brk: check the lower bound properly
> >
> > There is a check in sys_brk(), that tries to make sure that we do not
> > underflow the area that is dedicated to brk heap.
> >
> > The check is however wron
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> . Yes, setarch i386 -R /usr/local/bin/uemacs (etc) fixes them, too.
>
> What about this?
>
> Heap randomization breaks /lib/libc.so.5.4.33, make it possible to
> randomize normal stuff but leave the heap alone.
certainly looks fine to me, but
Hi!
> Still, it will probably not fix your particular program crashes, just
> because it will always assume that brk starts immediately after the end of
> the bss, which is plain wrong and has never been assured. Could you please
> check whether there is any compat-* package available for you
On Tue 2008-02-05 16:49:53, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > Hi!
> >
> > > > In my usual dither, I'm rather hoping Arjan will have a clear answer.
> > >
> > >
> > > setarch works. If the apps come in source form they need fixing anyway
> > > (since I'd no
On Tue 2008-02-05 16:49:04, Jiri Kosina wrote:
> On Tue, 5 Feb 2008, Pavel Machek wrote:
>
> > uemacs ... broken with randomization
> > colums, sss ... local programs, broken with randomization
> > procinfo ... broken, randomization makes it die sooner.
> > mikmod ... broken with randomization
> >
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > In my usual dither, I'm rather hoping Arjan will have a clear answer.
> >
> >
> > setarch works. If the apps come in source form they need fixing anyway
> > (since I'd not be
> > surprised of current gcc reorders variables), if not.. we
On Tue, 5 Feb 2008, Pavel Machek wrote:
> uemacs ... broken with randomization
> colums, sss ... local programs, broken with randomization
> procinfo ... broken, randomization makes it die sooner.
> mikmod ... broken with randomization
> bsdsed ... broken with randomization
> ...
> Should I test f
Hi!
> > In my usual dither, I'm rather hoping Arjan will have a clear answer.
>
>
> setarch works. If the apps come in source form they need fixing anyway (since
> I'd not be
> surprised of current gcc reorders variables), if not.. we only have 2 cases,
> the other case was the build process of
>
> But I was myself surprised by your randomize_brk patch: like the
> buggy program, I'd imagined that data immediately followed by bss
> immediately followed by brk was an invariant (whereas I never
> supposed the position of the code had anything to do with it).
> Just my ignorance, but not sur
On Tue, 5 Feb 2008, Jiri Kosina wrote:
> Now, you are right that the return value from brk() is bogus in these
> cases. The patch below should make it behave, as you can easily check with
> strace, right? Does anyone have any comments regarding this patch please?
Your patch below looks good to m
On Tue, Feb 05, 2008 at 01:54:26PM +0100, Ingo Molnar wrote:
> * Jiri Kosina <[EMAIL PROTECTED]> 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 clea
* Jiri Kosina <[EMAIL PROTECTED]> 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.
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 trigge
[some more CCs added]
> > Feb 4 12:29:32 amd kernel: columns-bin[4535]: segfault at 8052000 ip
> > b7f08a9a sp bfb79628 error 6 in
> > libc.so.5.4.33[b7e99000+87000]
> > Just before death,
> > [EMAIL PROTECTED]:~# cat /proc/4537/maps
> > 08048000-0805 r-xp 08:04 246209 /usr/local/
[ some CCs added ]
On Mon, 4 Feb 2008, Pavel Machek wrote:
> [EMAIL PROTECTED]:~$ strace columns-bin
> execve("/usr/local/bin/columns-bin", ["columns-bin"], [/* 31 vars */])
> = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0xb7f78000
> mprotect(0xb7f79000,
On Mon 2008-02-04 17:12:43, Jiri Kosina wrote:
> On Mon, 4 Feb 2008, Jiri Kosina wrote:
>
> > I still don't seem to fully understand what is happening here --
> > aparently this is triggerable only with old programs linked against
> > libc.so.5, and I am not able to trigger it with my trivial pr
Hi!
> > Not sure this helps... If I only randomize _end_ of heap, it still
> > works. If I try to randomize beggining of heap, too, it will not even
> > start recent binaries :-(.
>
> I don't uderstand this, sorry. Ehen the mapping for the new process is
> being established during loading of t
On Mon, 4 Feb 2008, Jiri Kosina wrote:
> I still don't seem to fully understand what is happening here --
> aparently this is triggerable only with old programs linked against
> libc.so.5, and I am not able to trigger it with my trivial program when
> I link it against old libc.so.5, which just
On Mon, 4 Feb 2008, Pavel Machek wrote:
> Not sure this helps... If I only randomize _end_ of heap, it still
> works. If I try to randomize beggining of heap, too, it will not even
> start recent binaries :-(.
I don't uderstand this, sorry. Ehen the mapping for the new process is
being establi
On Mon, 4 Feb 2008, Ingo Molnar wrote:
> hm, so it seems that it isnt even the randomization that causes the
> problem - but somehow the randomization code itself is broken, right?
> Would you be interested in figuring out how to unbreak this? [if not,
> could you send me the binary?]
I still
Hi!
> > Hmm, code in binfmt_elf is really strange.
> >
> > elf_bss += load_bias;
> > elf_brk += load_bias;
> > start_code += load_bias;
> > end_code += load_bias;
> > start_data += load_bias;
> > end_data += load_bias;
> >
> > /* Calling se
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hmm, code in binfmt_elf is really strange.
>
> elf_bss += load_bias;
> elf_brk += load_bias;
> start_code += load_bias;
> end_code += load_bias;
> start_data += load_bias;
> end_data += load_bias;
>
>
33 matches
Mail list logo
