Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Jul 2015 09:35:18 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: extend SIMD intrinsics


> On Jul 7, 2015, at 5:24 AM, Solar Designer <solar@...nwall.com> wrote:
> 
> On Mon, Jul 06, 2015 at 08:08:21PM +0200, magnum wrote:
>> On 2015-07-06 10:23, Solar Designer wrote:
>>> 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.
> 
> Indeed.
> 
>> + typedef union {
>> + 	vtype v;
>> + 	uint32_t s[SIMD_COEF_32];
>> + } vtype32;
>> 
>> + typedef union {
>> + 	vtype v;
>> + 	uint64_t s[SIMD_COEF_64];
>> + } vtype64;
> 
> 
> Why two separate union types, though?  We could use a shared type, with
> two arrays in place of s.  Would have to call those e.g. s32 and s64.

Do you mean a single type like this?

typedef union {
	vtype v;
	uint32_t s32[SIMD_COEF_32];
	uint64_t s64[SIMD_COEF_64];
} vtype;


> Using those union types inside SSESHA1body(), etc. would be even safer,
> so e.g.:
> 
> 	vtype32 a[SIMD_PARA_SHA1];
> 	vtype32 b[SIMD_PARA_SHA1];
> [...]
> 	a[i].v = reload_state->v[i*16+0];

Then why use vtype32 here?

And why not:

	a[i] = reload_state[i*16+0];

> but it increases our reliance on the optimizer for producing fast code.

I don't understand this well. Do you mean the compiler might not generate a load for a[i]?


Lei

Powered by blists - more mailing lists

Your e-mail address:

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