Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Apr 2013 03:25:32 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Segfaults probably caused by DEBUG code in memory.c (was: Segfault for linux-x86-native with -DDEBUG added)

On 16 Apr, 2013, at 20:06 , magnum <john.magnum@...hmail.com> wrote:
> I also fixed the bug below. This one actually exist in core too, although I'm not sure any core format uses mem_alloc_tiny() for SSE2 buffers.
> 
> #if ARCH_ALLOWS_UNALIGNED
> -       if (mem_saving_level > 2)
> +       if (mem_saving_level > 2 && align != MEM_ALIGN_SIMD)
>                align = MEM_ALIGN_NONE;
> #endif

Since we sometimes align to something larger, like MEM_ALIGN_CACHE or MEM_ALIGN_PAGE, the above is not enough: I could still segfault an sse2 build of unstable using --save-memory=3. I'll need to do this (ignoring the slight "impact" on VAX and x86-any):


#if ARCH_ALLOWS_UNALIGNED
	if (mem_saving_level > 2 && align < MEM_ALIGN_SIMD)
		align = MEM_ALIGN_NONE;
#endif

MEM_ALIGN_SIMD is a Jumbo-only definition, it falls back to 16 on non-MMX/SSE.


I haven't managed to segfault an SSE2-build of core John using --save-memory=3 but after briefly looking at the code I suspect it could happen.

On another note we should mute the self-test warnings (in bleeding) for unaligned salts/binaries when this is used. This too also applies to core iirc.

magnum

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.