Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 Jul 2012 20:52:04 +0200
From: magnum <>
Subject: Re: New core (?) LM fails alignment

On 2012-07-15 14:55, Solar Designer wrote:
> On Sun, Jul 15, 2012 at 01:49:33PM +0200, magnum wrote:
>> On 2012-07-15 12:57, Solar Designer wrote:
>>> I decided not to do that yet.  Instead, I made the alignment of binary
>>> and salt configurable per format, which is desirable anyway.  While at
>>> it, I also revised the memory.c code not to assume that pointers fit in
>>> "unsigned long", although that assumption caused no trouble so far.
>> I have no objections to that patch other than I will not likely have
>> time to merge it within 8-9 days or so, as I'll have to "investigate"
>> each format while adding this.
> I thought that you could start by putting safe placeholder values in
> there - e.g., ARCH_SIZE for all alignments unless it is obvious that
> smaller would do.  Better yet, we can put in an include file:
> and use that.  Then it'd be easy for us to grep for DEFAULT_ALIGN and
> review/replace all those with whatever the format actually requires -
> when we have time for that.

Merged and committed now. I do not think there were any new merge "hazards".

I'm using this in formats.h:

 * Default alignment (used unless known)

Many formats will probably benefit from using 4 bytes alignment instead
of MEM_ALIGN_NONE, should we consider using that instead?

I set Tavis' binary alignment to MEM_ALIGN_SIMD, for everything else I
used DEFAULT_ALIGN for now.


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.