[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ab95d24ec29d5fc07708829e486c06c9@smtp.hushmail.com>
Date: Mon, 06 Jul 2015 20:08:21 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
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 <solar@...nwall.com> 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:
>
> http://article.gmane.org/gmane.comp.security.phc/2753
>
> 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];
...
SHA1_PARA_DO(i)
{
- 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?
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.
