Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Mar 2015 04:11:57 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: malloc not returning SIMD-aligned (was: Re: [GSoC] building JtR for MIC)

magnum, all -

On Tue, Mar 17, 2015 at 12:40:40AM +0100, magnum wrote:
> It turns out that some versions of (at least 32-bit) malloc() may return
> a buffer aligned to 8 even on a SIMD-capable machine (apparently "any
> object" in reality means "any object not larger than a double"). This
> even on Linux. I did not see that coming :-(  Right now bleeding is
> broken for 32-bit x86. I may revert the changes but I'm trying not to
> move too fast here.
> 
> So we are now considering the alternatives. One is to simply use
> posix_memalign(). That one is "IEEE Std 1003.1-2001 (``POSIX.1'')"
> whatever that means in practice. That would be the easiest fix.

Since jumbo is autoconf'ed anyway, I think using posix_memalign() is
fine.  We're probably not going to find a relevant system supporting
SIMD vectors wider than a double that doesn't also have posix_memalign().

For Makefile.legacy to work, it's probably fine to enable
posix_memalign() from x86-{see,64}.h, ppc*alt.h, and arm*.h (maybe from
within an #ifdef __ARM_NEON__ block).

> Another option is to use a new function in misc.h that does almost the
> same but that has the drawback we need to keep track of a second pointer
> for each buffer - that obviously is the one to use for free(). This is
> totally doable but code get a little less nice.

This requires use of two-pointer structs instead of pointers in the
callers.  I use this in the current yescrypt code (and the structs
record sizes as well), but for jumbo it's arguably "too portable".

I also use posix_memalign() in yescrypt whenever available, but it's
wrapped in the interface I described above.  See alloc_region() in
yescrypt-platform.c if you're curious.

> Third option, which has several unrelated benefits, is to finally
> implement the "malloc_tiny with domains" we have discussed over the years.

Right, but that's too much for fixing the current breakage.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ