Re: [openssl.org #2557] Bug in perlasm/cbc.pl with short/partial blocks?
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 openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2557] Bug in perlasm/cbc.pl with short/partial blocks?
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); 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. 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? Or does the indirect jump cause the ppro to forget the tag? [1] On the other hand, looking through earlier bugs like RT#1801, it sounds like the higher layers of OpenSSL never pass partial blocks to the CBC code anyway, so this bug would only be visible to people who are bypassing the EVP_* layer. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
