> I noticed this odd sequence of instructions in cbc.pl, near line 171.
> It seems like a bug, but the code hasn't been modified since 1998,
> and it seems unlikely this bug would have gone unnoticed for that
> long[1]:
>> &set_label("ej3");
>> &movb(&HB("ecx"), &BP(2,$in,"",0));
>> &xor("ecx", "ecx") if $ppro; # ppro friendly
>> &shl("ecx",8);
As already noted problematic instruction is conditional on $ppro
variable. This variable is set only in cast-586.pl. And cast-586.pl is
disengaged in shared build. And since majority is using shared libs and
nobody is using CAST... I mean these are contributing factors to why the
bug remained unnoticed.
> I'm guessing the xor should be before the movb (as it is a few lines
> earlier in a parallel piece of code), not after. As it is, this bug
> would occur if you compile with $ppro=1 and feed the CBC encrypt
> function with a buffer whose length%8==3. The last byte of input
> would always be read as 0.
Correct.
> I'm not sure the xor is even needed, to be honest (but I don't know
> much about ppro optimization). ECX and EDX are zeroed right before
> the indirect jump to ej3, so wouldn't that already prevent a partial
> register stall?
Correct, xor is redundant. http://cvs.openssl.org/chngview?cn=21154.
> Or does the indirect jump cause the ppro to forget the tag?
Unlikely.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
