[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3ca87186cf2e6358d113c46f5dfd1128@smtp.hushmail.com>
Date: Thu, 08 May 2014 23:36:32 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Core on sparc i.e. requires alignment hmac format
(and possibly others)
On 2014-05-08 23:03, jfoug wrote:
> I ended up having to remove 17 formats due to cores, 23 formats that fail,
> and about 6 due to openssl 'assumptions', and there were
> formats.c:
> int fmt_default_binary_hash_0(void * binary)
> {
> return *(ARCH_WORD_32 *) binary & 0xF;
> }
This function is flawless, the problem is always in caller's code: If
using this default function, we either need ARCH_ALLOWS_UNALIGNED, or
BINARY_ALIGN must be >= 4 and binary() must return a buffer aligned
accordingly.
> hmacSHA224_fmt_plug.c (and probably many others)
> I thought we had tests that would fail in the format/test/benchmarking stage
> for binary not being aligned (at least not aligned on CPU's requiring it).
We've had various versions of such tests but they always ended up not
very good: The problem is we want to fail on x86 (because that's what we
all use when developing) even though this is actually only a problem on
eg. Sparc. No matter how clever tests we come up with, what if the
format actually has #ifdefs so a Sparc host *would* get proper code for
its requirements? Then it will fail on x86 for no reason!
There's an old GitHub issue for removing every single use of
DEFAULT_ALIGN and reviewing issues like these while at it. It's super
trivial to fix for any single format, but a whole lot of formats are
affected so it's not very encouraging.
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.
