Re: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out
On May 18, 2015, at 1:41 PM, Andy Polyakov via RT r...@openssl.org wrote: Found by the https://github.com/xiw/stack tool and then I checked the generated asm (gcc and clang) to confirm. In the check if (d0 tmp_ulong) tmp_ulong always evaluates to true because the compiler optimizes out the tmp_ulong value to true because (tmp_ulong = zz d1;) zz d1 has according to the compiler (LLVM) a logical right-shift overflow. What's right-shift overflow? In either case, are you sure about it being optimized away because it always evaluates to true? Thing is that if tmp_ulong is 0, then xor-ing with it won't have effect on result. I mean check for d0 alone would actually produce same outcome, wouldn't it? Right-shifting by *equal to* or more than the width of the word produces undefined results in C (just like left-shifting); one expects that it produces zero, but the language spec says it’s undefined. Presumably, clang is taking advantage of the undefined behavior to eliminate the check: it notices that if, in this case, an excessive right shift always returns a nonzero value (which is allowed), then it can produce smaller code. (From http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf section 6.5.7: If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. See also e.g.: http://blog.regehr.org/archives/213 ) I agree that the test for tmp_ulong being nonzero is redundant. And the shift overflow presumably only happens when d0 is zero anyway, so the undefined behavior can't affect the output. But it might make sense to move the right-shift into the if() as well. Given the commit message was don't write beyond buffer, though, I think there was possibly intended to be a different test there that makes more sense? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #3320] Invalid large memory access in openssl due
On 28 Apr 2014, at 4:20 PM, Kurt Roeckx wrote: To me this all sounds like an we end up in an inconsistent state. I'm expecting write(2) like behaviour of SSL_write(). You can request write(2)-like behavior from SSL_write() by setting SSL_MODE_ENABLE_PARTIAL_WRITE with SSL_CTX_set_mode(). However, this bug is one that occurs when the write(2)-like behavior is not set. I do think it would be reasonable to sanity-check 's-s3-wnum' against 'len' in ssl3_write()/ssl2_write(), perhaps duplicating ssl3_write_pending()'s error checks so that they happen before the underflow occurs. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3094] bug report: osx 10.8.4 won't build with enable-ec_nistp_64_gcc_128
I did a quick test, and found that 'make test' succeeds for -O0, -O1, -Os, and -Oz, but fails for -O2 and -O3. This is using Apple's cc which is based on clang-3.3 (it describes itself as clang-500.1.58 based on LLVM 3.3svn) and openssl-1.0.1e. It fails in the NIST test vectors stage of NIST curve P-256 (optimized implementation). I'm not sure if there's a way to ask Clang what particular transformations it enables for each optimization level, so I didn't investigate further. -Os and -Oz are documented as being like -O2, so that may be the minimal difference between a working and nonworking compile. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2782] BUG report: RSA private key serializer
On 2 Apr 2012, at 10:21 AM, Tamir Khason via RT wrote: Please see attached good and bad example + plain dump for both The attached file was corrupted at some point in the mail ... perhaps you could put it on your website? I couldn't read the PEM file you posted either because it was encrypted. I looked at your blog post and I agree with other posters that it looks as if you are misunderstanding the ASN.1 integer format. For example, the bad exponent1, which starts with 00:9a:2e:9c:. If you remove the 00 octet, the resulting number would be a negative number, because ASN.1 INTEGERs are always signed. But cryptography code does not usually use negative integers, so it is easy to forget this and wonder why there are extra 00 octets. Many people have made this mistake (perhaps most people). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2562] Adding cfi/fpo records to asm (fix backtrace when debugging)
FWIW, I worked on extending this to cover the other x86 perlasm files in libcrypto over the weekend, by causing the %esp-tracking code in x86asm to emit CFI directives when needed. Other than the SHA implementations (some of which use a sliding-stack scheme that's hard to unwind) it needs only a few lines of extra annotation per asm file, and it makes debugging an openssl-heavy application much easier. (This is the DWARF .cfi_ stuff only, I think the Win32 .FPO directive isn't flexible enough for most of the assembly routines.) I will put together a patch series in a bit. __ 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
