Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 02 Apr 2015 18:36:16 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New SIMD generations, code layout

On 2015-04-02 18:05, magnum wrote:
> On 2015-04-02 17:47, Lei Zhang wrote:
>> BTW, I have a question on how the lookup table is constructed. In
>> kUsedBytesTable, from my observation, each subarray corresponds to a
>> SIMD vector and those vectors are consecutively shifted left by one
>> byte in order. But in the lower middle of the table, I find a "jump"
>> that breaks my observation:
>>
>> // for SSE
>> static const __aligned_simd uint32_t kUsedBytesTable[][4] = {
>> 	...
>>         { 0x00000000, 0x00000000, 0xFF000000, 0xFFFFFFFF },
>>         { 0x00000000, 0x00000000, 0x00000000, 0xFFFFFF00 },
>> 	...
>>     };
>>
>> The lower subarray is supposed to be shifted left by one bytes from
>> the upper subarray, but actually it's shifted left by two bytes. I
>> don't know if this is a mistyping or something intentionally done.
>> Could you give me some explanation?
> 
> I agree it looks like a bug and I can't see any reason it would be
> intended. OTOH it's strange that the Test Suite hasn't catched it (it
> should test all lengths - I guess it does not). I will investigate.

I did some tests but se no difference (and no problem) with this bug
fixed or not. I'm yet to prove this, but I guess what happens is we're
not masking the byte right after the data but this byte is overwritten
with 0x80 anyway. So the bug never surfaces.

magnum


Powered by blists - more mailing lists

Your e-mail address:

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