Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

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