Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 06 Jul 2015 20:08:21 +0200
From: magnum <>
Subject: Re: extend SIMD intrinsics

On 2015-07-06 10:23, Solar Designer wrote:
> On Mon, Jul 06, 2015 at 09:43:43AM +0200, magnum wrote:
>> On 2015-07-06 04:24, Lei Zhang wrote:
>>>> On Jul 5, 2015, at 2:44 PM, Solar Designer <> wrote:
>>>> Now, there might or might not be a difference as it relates to C strict
>>>> aliasing rules.  Maybe the load/store intrinsics allow us to perform
>>>> an equivalent of typecasts yet safely circumvent C strict aliasing rules.
>>> If I understand the strict aliasing rule correctly, I don't see how
>>> the current use of intrinsics in JtR could violate the rule, as we
>>> don't use different vector types to access the same memory address.
>> We currently declare the functions like this:
>> void SSESHA256body(vtype *data, ARCH_WORD_32 *out, ARCH_WORD_32
>> *reload_state, unsigned SSEi_flags);
>> I think we break strict aliasing rules right there: reload_state, when
>> used, is an alias to either data or out but they are declared as
>> different types.
> It certainly sounds so from your description.
>> I'm not sure why they are declared like this. Since all three really are
>> vectors, I think we should have it as:
>> void SSESHA256body(vtype32 *data, vtype32 *out, vtype32 *reload_state,
>> uint32_t SSEi_flags);
>> Note also that in sse-intrinsics.h the functions are *externally*
>> declared with "vtype" being a macro defined as "void". I'm not sure who
>> made it that way originally nor if it's 100% kosher, but it sure is
>> convenient.
> Sounds like another instance of undefined behavior.
> Regarding possible use of union types, here's a relevant posting by
> Alexander Cherepanov:
> Nearby postings in this thread are also relevant.

I get more depressed the more I read. Every single way to write it seem 
to be UB in someone's book. But disregarding that, how about

+ typedef union {
+ 	vtype v;
+ 	uint32_t s[SIMD_COEF_32];
+ } vtype32;

+ typedef union {
+ 	vtype v;
+ 	uint64_t s[SIMD_COEF_64];
+ } vtype64;

- void SSESHA1body(vtype* _data, ARCH_WORD_32 *out, ARCH_WORD_32 
*reload_state, unsigned SSEi_flags)
+ void SSESHA1body(vtype32 *data, vtype32 *out, vtype32 *reload_state, 
uint32_t SSEi_flags)
	vtype a[SIMD_PARA_SHA1];
	vtype b[SIMD_PARA_SHA1];
-		a[i] = vload((vtype*)&reload_state[i*16*VS32+0*VS32]);
+		a[i] = vload(reload_state->v[i*16+0]);

Would this take us forward or back?


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.