[openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

>>> C does not make such a guarantee, though recent-ish POSIX does.  (This
>>> system is a windows one, thought, right?)
>> There are DSPs that only support 32 bit, they don't have a concept
>> of 8 bit.  But I think there is various code that assumes that
>> char is 8 bit, and I doubt you can get OpenSSL working on such a
>> system.
>>
> Target in question is traditional 32 bit ARM with 32 bit
> instructions and 8 bit char.
> 
> Looks like a hard to fix compiler bug to me.

While assessment that code presented in disassembler output lacks a
number of &0xFF is absolutely correct, it's not *necessarily* proof of a
compiler bug (but read to the end, please). Trouble is that since
functions are static compiler is free to trim them as it suits local
goal in any given module. For example consider disassembler output for
constant_time_eq_8 from x86_64 test/constant_time_test.o compiled by gcc
4.8:

<constant_time_eq_8>:
	xor    %esi,%edi
	lea    -0x1(%rdi),%eax
	not    %edi
	and    %edi,%eax
	sar    $0x1f,%eax
	retq

Note no mask either! [Note that it even replaced 0-(a>>(sizeof(a)*8-1))
with arithmetic shift!] However! This does *not* mean that suggestion
about compiler bug is rejected, it only means that you can't use lack of
&0xFF in presented disassembler output as definitive proof.

constant_time_msb was pinpointed as culprit. But I can certify that
binary code generated for 0 - (a >> (sizeof(a) * 8 - 1)) *alone* is
actually correct. It should be and is

	mov         rX, rY, lsr #31
	rsb         rZ, rX, #0

[Unless compiler recognizes it as equivalent of arithmetic shift, like
gcc did above]. But as it gets inlined in *real* usage cases, compiler
will subject it to all possible kind of optimizations and in process can
loose track of things, which would be definition of compiler bug. In
other words one can't dismiss the suggestion that it is a compiler
bug... More reliable to way to tell if it's indeed a compiler bug is to
disable optimizations. So I'd suggest to do that. Not to do that and
leave it like that if it works, but to *determine* if we are looking at
compiler bug or not.