Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Wim Lewis]

On 24. jan. 2018, at 6:11 f.h., Benjamin Kaduk via openssl-dev 
 wrote:
> On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote:
>> Well, the most likely fix is to make the “safely” wording be more vague, 
>> which I doubt you’ll like.  But I doubt anyone on the team has much interest 
>> in fixing 1.0.2 locking issues.
> 
> Who said they were 1.0.2-specific?  Master's obj_dat.c still has a completely 
> unlocked OBJ_new_nid() that is a public API function; AFAICT the issue is 
> still present.

As you say, this really doesn't seem to be a 1.0.x-specific problem. The 
current development tip on github has the same issue (and the same language in 
doc/man3/CRYPTO_THREAD_run_once.pod).

The current patch ( PR 5164 ) just changes "can be safely used" to "can 
generally be used safely". Without enough information for a user of the library 
to know whether a given usage is safe, this isn't useful documentation. When it 
comes to threading, "generally safe" is the same as "unsafe". There needs to be 
at least a little bit of guidance.

A quick check of my system's openssl 1.1 libraries shows 280 mutable global 
variables in libcrypto and 36 in libssl. Most of those are presumably protected 
by locks or are only set during init; for the remaining actual thread-unsafe 
variables, it should be possible to document the small number of APIs which 
affect them.


-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Wim Lewis]

On 9. jan. 2018, at 7:40 f.h., Randall S. Becker  wrote:
> On January 9, 2018 10:05 AM, Rich Salz wrote:
>> It would be interesting to see how many changes you need to support your
>> platform.
> 
> Surprisingly not many at all. The platform has been significantly modernized 
> since early ports. Most of the differences are the addition of a FLOSS layer 
> (though #includes) and one byte swap issue on bn_mul_add_words that I'm not 
> sure is relevant anymore. Some of the tracked files that generated 
> (tests/Makefile) have spacing difference due to tooling differences. The 
> code, however, is very close to vanilla as of 1.0.2n.

In this case, I think Dmitry Belyavsky's suggestion makes the most sense. SPECK 
can be built as an ENGINE, the same way that GOST, CAPI, etc. are. (see [1].) 
This may require small changes to OpenSSL proper (to add OIDs, say), but they 
should be small enough not to add any complexity or maintenance burden to 
OpenSSL. If/when SPECK gains more use, or is considered for standardization in 
TLS, etc., then this codebase can be moved into OpenSSL's. In the meantime, 
people can build the SPECK engine to use it in an OpenSSL-based program.

[1] https://github.com/gost-engine/engine

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] where is PEM_read_bio_X509_AUX()

[Wim Lewis]

On Apr 18, 2016, at 6:11 PM, CHOW Anthony  
wrote:
> I am trying to do “openssl verify –CAfile server.pem” and the command hang.  
> When I debug, I see that after calling the function PEM_read_bio_X509_AUX in 
> load_cert() it hangs.  
>  
> But I don’t seems to find this function in the OpenSSL tree. 
>  
> Any insight on this?  Thanks so much.

The macros DECLARE_PEM_rw and IMPLEMENT_PEM_rw, which are defined in 
crypto/pem/pem.h, produce a bunch of functions for reading and writing 
structures in various ways (with a BIO, from a FILE *, from a string buffer, 
etc). In this case, I think the function you're looking at is produced by the 
macro invocation "IMPLEMENT_PEM_rw(X509_AUX, X509, PEM_STRING_X509_TRUSTED, 
X509_AUX)" in crypto/pem/pem_xaux.c.

Possibly it's hanging waiting to read something from stdin.



-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out

[Wim Lewis]

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-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out

[Wim Lewis via RT]

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-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing

[Wim Lewis]

On Mar 25, 2015, at 11:56 AM, Matt Cross matt.cr...@gmail.com wrote:
 I am working with something that does a lot of SHA1's.  I am trying to 
 profile my application and generate flame graphs (see 
 http://www.brendangregg.com/flamegraphs.html ), but profiling tools cannot 
 successfully backtrace when the processor is running the optimized SHA1 code 
 on x86_64.  This patch adds CFI directives when compiled with a GNU assembler 
 to enable tools that understand DWARF debugging information to backtrace in 
 this circumstance.


FYI, I submitted a patch a few years ago to do this for many of the x86-32 
assembly files. The perlasm preprocessor already tries to track the stack 
offset, which means that a lot of those .cfi directives can be generated 
automatically, without requiring the programmer to keep track of them.

The patches are here:
   http://rt.openssl.org/Ticket/Display.html?id=2562

As you point out, this is pretty useful to allow profiling and/or debugging 
code that spends a lot of its time in OpenSSL.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing

[Wim Lewis]

On Mar 25, 2015, at 2:42 PM, Matt Cross matt.cr...@gmail.com wrote:
 This is done to align %rsp to a 64 byte boundary, and the original %rsp is 
 stored on the stack; so the only way to get the actual frame pointer is to 
 read 64(%rsp) and add an offset to that.  I managed to do that by inserting a 
 raw DWARF expression.  It's not clear to me that the perlasm preprocessor 
 could (or should) do this; but perhaps it makes sense to add some directives 
 for the perlasm preprocessor and let it generate the raw DWARF expression.

I think the cfi_cfa_indirect pseudo-directive handles that case (it’s defined 
in x86gas.pl and used in, e.g., aesni-x86, which does a similar stack 
alignment). It uses a minuscule “assembler” for DWARF location opcode 
expressions included in the 3-cfi patch, which makes it easier to handle cases 
where the assembly is doing something clever.

The SHA256 and SHA512 implementations on x86_32 did something trickier: each 
round adjusted the stack frame forwards by some number of bytes, so that it 
could read the previous round and write the new data from fixed offsets from 
$esp (presumably this saves a register). I didn’t try writing DWARF info to 
unwind that. I don’t think the x86_64 code does that, though, since registers 
aren’t as scarce.


 If I understand correctly, your patch was not folded in.  Do you recall why?

IIRC, the maintainer said it would be too much trouble to integrate.



___
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

[Wim Lewis via RT]

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: On the concurrent use of SSL_write and SSL_read

[Wim Lewis]

On 11 Aug 2013, at 2:19 PM, Ahmed Charfeddine wrote:
 It has been understood that the concurrent use of SSL_write and SSL_read is 
 dangerous. 
 However, is it correct to assume that the only crossing between these two 
 APIs happen at the handshake stage only ? 
 In other terms, once the SSL handshake stage has been completed, is it safe 
 to use these two APIs concurrently ? 


No, this is not a safe assumption. Renegotiations can happen at any time during 
the middle of the connection.

(I assume you are talking about a program which has several threads, one of 
which calls SSL_read() and one of which calls SSL_write() ?)


__
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

[Wim Lewis via RT]

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: What are the procedures to authenticate certificate?

[Wim Lewis]

On 10 Apr 2013, at 5:25 PM, igenyar wrote:
 After receiving a certificate, the client needs to send challenge to server
 to verify that the server does have the private key associated with the
 certificate. (Besides other checkings such as DNS, etc.)

This happens as part of the SSL handshake --- you can google that phrase and 
find a variety of descriptions of the process, including the formal description 
of it in RFC 6101. 

 I wonder what OpenSSL API's would accomplish that. Links to knowledge or
 sample source code are highly appreciated!!! Thank you for the help.

The code is scattered around inside OpenSSL, depending on the protocol version, 
whether it's the client or the server side of the connection, etc. You could 
start with the ssl3_connect() function in s3_clnt.c (I think this is also used 
for TLSv1).


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: BIO_do_connect() fails with IPv6 address

[Wim Lewis]

On 7 Jan 2013, at 10:21 PM, shyamala wrote:
 Hi, I have some queries regarding BIO_* calls. Our application uses BIO_* 
 calls (BIO_do_connect, BIO_new_connect etc) to establish connection with 
 Onboard Administrator. This works fine with IPv4 IP address, but 
 BIO_do_connect fails when IPv6 address is used. Looks like BIO_* calls don't 
 support IPv6. Could you please confirm whether BIO_* calls support IPv6? If 
 not, is there any alternate solution for this? Regards, Shyamala 

The BIO_s_connect() BIO method (which is used by BIO_new_connect()) only 
supports IPv4. (See also this thread on the subject from a couple years ago: 
[1]).

You can make IPv6 connections (or, presumably, other stream socket protocols) 
by doing the underlying socket() and connect() calls yourself, then wrapping 
the connected fd in a BIO using BIO_socket_nbio(), BIO_new_socket(), 
BIO_set_conn_hostname().

[1] http://www.mail-archive.com/openssl-users@openssl.org/msg65674.html


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why simple OCSP server listen only TCPv6 connections on Windows?

[Wim Lewis]

On 10 Oct 2012, at 4:58 AM, Vladimir Belov wrote:
 After I got the message “Waiting for OCSP client connections...” I see that 
 process openssl.exe listen only TCPv6 port , no TCPv4.
 
 How to set up OCSP responder to handle IPv4-connections? Or the only way is 
 to use only IPv6-connection to the OpenSSL OCSP responder?

Are you sure that it is not responding to IPv4 connections on its ipv6 socket 
using ipv4-mapped-ipv6 addresses?


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Digital certificate with more than 1 year validity

[Wim Lewis]

On 17 Sep 2012, at 9:13 PM, Santhosh AP wrote:
 Kindly help us to create digital certificate having more than 365 day’s 
 validity. At present we are using OpenSSL 0.9.7a Feb 19 2003 version. Kindly 
 confirm is it possible to cross the certificate validity more than 1 year, if 
 it’s possible how to do it.

I don't think there is anything preventing you from specifying a longer 
validity period, either on the command line to the 'ca' command or in the 
relevant ca section of the config file. (Some documentation says to specify it 
when creating the CSR, but this is wrong: the CSR does not carry that 
information as far as I know. The validity period is chosen by the CA when it 
creates the certificate.)

This is more of a openssl-users question than a openssl-dev question, so I've 
cc:'d that list; it's probably best if replies go there.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to know which curve to use for which cipher

[Wim Lewis]

(I think this is more appropriate for openssl-users than -dev, so I'm 
responding to that list.)

On 10 Jul 2012, at 8:59 AM, Sirshendu Rakshit wrote:
 My questions are:
 1) Is this a good way to know the EC_KEY using the curve-name Or there is
 some better way to know it?

If you're hardcoding a specific curve, you could presumably use the 
NID_secp224r1 (or SN_secp224r1, or OBJ_secp224r1) constants defined in the 
openssl headers.


 2) When I tried prime256v1 curve-name with the same RSA cipher it didn't
 work and I got handshake failure. Is there any relationship between ECDH*
 cipher used and the curve?

I don't think so, but it's possible that the client simply didn't support that 
curve? As I understand it, the client sends a list of curves it can accept in 
an optional ClientHello extension (rfc4492), and the server chooses a curve 
from among those and tells the client which one it chose. (Or, perhaps, it only 
negotiates the use of the ECDHE cipher suite if its chosen ephemeral key is 
based on a curve supported by the client.) The server can choose any curve that 
is acceptable to both it and the client; presumably the curve also needs to be 
large enough for DH exchange to generate a good session key. 



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Incorporating ticket #2562 / debug info?

[Wim Lewis]

About a year ago, building on some work by Yoni Londner, I posted some patches 
to add more accurate debug information, mostly describing stack unwinding, to 
the hand-optimized x86 assembly code. This is especially helpful when profiling 
or debugging, since otherwise the debugger does not know how to interpret the 
machine state. I'd really like to see this integrated into OpenSSL instead of 
languishing in RT. Is there anything I can do to help this happen?


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

[Wim Lewis]

On 3 Apr 2012, at 2:34 AM, Tamir Khason via RT wrote:
 It seemed that we are speaking about different things.
 In certificate i pasted, integers used for exponent1, exponent2 and
 coefficient encoded with different lengths.

Yes. This is OK. In fact, it is required by DER (ISO 8825, etc).

 In chapter 8.3 of ISO 8825
 there is clear statement of how integer values should be encoded. All
 need is to take those numbers from bad certificate i pasted and
 encode it by using different 8825 implementations to see leading zeros
 appear. When openssl encode those number leading zeros are missing.
 This is what i claim as a bug.

If two implementations DER-encode the same integer into different byte 
sequences, then there is definitely a bug, since the purpose of DER is to be 
unique (there should be only one possible DER encoding of a value). However, I 
do not see an example of this.

The good/bad example you posted is confusing because they are different keys, 
with different coefficients, so I am not sure what you think is wrong with the 
bad example. Could you please post a bad example generated by OpenSSL, and 
explain what you think the correct encoding of it is?

Here is how the shorter exponent is encoded in the private key you put on 
pastebin:

 02 # universal, primitive, INTEGER
 40 # Length = 0x40 bytes
 00 80 5b 5f bb  0a c1 c7 a9# value of integer

This is the only valid way to DER-encode this integer. If the 00 at the 
beginning of value were removed, it would change the meaning (the integer would 
be negative). If another 00 were added, it would be valid BER (I think?), but 
not valid DER. Paragraph 8.3.2 in the text posted by Peter Sylvester is the 
rule. A simpler way to think about it is it is invalid to use any unnecessary 
00 bytes.



__
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

[Wim Lewis via RT]

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: How encrypt long string RSA

[Wim Lewis]

On 27 Mar 2012, at 3:01 AM, Frater wrote:
 Where is any working example to encrypt file or long string using RSA Public 
 or private key.
 in demos/maurice is example 1 but using certificate not privkey.

The code in demos/maurice reads a certificate and extracts an EVP_PKEY from it, 
which is used by the rest of the example. Presumably any other method of 
getting an EVP_PKEY would work equally well.

(This is more of an openssl-users question than an openssl-dev question, I 
think.)


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: openssl md5 output

[Wim Lewis]

On 18 Jul 2011, at 1:25 PM, Patrick Donnelly wrote:
 Are you seriously suggesting that parsing the md5sums of multiple
 files from the output of openssl md5 *.txt is a sensible use case?

It's not just sensible, it's fairly common. The DIGEST(filename)=hexhexhex... 
output style is in imitation of other tools, like md5sum.

I agree that this change is an unnecessary annoyance. IMHO it would be better 
for openssl to emit the bare digest unless multiple files are specified or an 
option is used on the command line.


 On Mon, Jul 18, 2011 at 4:05 PM, Coda Highland chighl...@gmail.com wrote:
 My question is why you're depending on the output format of openssl
 md5 in the first place. md5sum is almost as commonly available and is
 much more amenable to shell scripting,

Almost indeed. I often use openssl in shell scripts because it's more 
reliably available across operating systems. 


__
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)

[Wim Lewis]

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

Re: [openssl.org #2562] Adding cfi/fpo records to asm (fix backtrace when debugging)

[Wim Lewis via RT]

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?

[Wim Lewis via RT]

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

Re: [PATCH] cfi/fpo directives in md5 assembly code

[Wim Lewis]

Well, I did some testing with the slightly-modified patch (debian squeeze and 
openbsd 4.9), and confirmed that this produces an .eh_frame which allows gdb to 
walk the stack successfully if the program is stopped in or singlestepped 
through md5_block_asm_data_order(). Some notes, though:

- Not all versions of gas have the .cfi_foo directives. In fact, .cfi_sections 
only showed up in 2.21, and the other directives used here were added in 2.15.  
Debian's reasonably up-to-date, but OBSD4.9 has 2.15, and Apple's dev tools 
ship with a decade-old 1.x version of gas. So the config script will presumably 
need to be able to partially or completely disable CFI generation. On the 
bright side, the .cfi_sections directive isn't actually needed; the default 
behavior (generating eh_frame but not debug_frame) is appropriate.

- x86nasm.pl needed stubs for these directives as well. I have no idea what 
NASM supports in this area so I made both the CFI and FPO directives no-ops.

- OpenSSL compiles with -fomit-frame-pointer on both of these machines, which 
means even the gcc-generated code is not backtraceable unless you add 
-funwind-tables. IMHO, the config script should add -funwind-tables unless disk 
space is at a premium (it doesn't affect the generated code) --- unwindability 
is handy to have. And by the same token, if the C code is compiled with 
-fomit-frame-pointer but no unwind tables, then it would make sense to leave 
the unwind information out of the asm code as well.

- The perlasm scripts already keep track of the stack depth (to find args and 
such), which should make it possible to generate a lot of the CFI directives 
automatically. If this patch is accepted I think it's worth trying to make the 
perlasm code handle more CFI generation and then fix up the other 
frame-pointer-less asm routines as well.


Here's the slightly-amended patch:




cfi-fpo-3.patch
Description: Binary data

Re: [PATCH] cfi/fpo directives in md5 assembly code

[Wim Lewis]

On 28 Jun 2011, at 5:56 PM, Wim Lewis wrote:
 Several of the other assembly files could use the same treatment as well: 
 md5-x86_64.pl uses %rbp to point to one of its arguments, sha1-586.pl uses 
 %ebp as a scratch register, etc.

It occurs to me that a lot of the CFI management could be done automatically in 
push(), etc., if the script keeps a little bit of state.

On 29 Jun 2011, at 12:01 AM, yoni londner wrote:
 I currently do not have the time to continue working on it.
 Since I tested my patch carefully, and since it makes the code better, maybe 
 we can merge it to trunk, and continue to work on your suggestions later on. 
 Sound good? 


I wasn't proposing that the other changes had to be done now --- just noting 
that the lack of unwind information seems to be a problem that most of the 
assembly files have. I think the extra registers' unwind info for the md5 asm 
is worth including now, though, since it's a tiny enhancement.

But it's kind of moot since no one with commit access has weighed in.


I'll be away for a while, but I'll see if I can test the md5 patches and 
possibly look at some other asm files when I get back.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] cfi/fpo directives in md5 assembly code

[Wim Lewis]

On 28 Jun 2011, at 12:21 AM, yoni londner wrote:
 1. I looked at a generated assembler from gcc. So I am not 100% sure what is 
 the 'most correct', but this is what gcc emits.

I was concerned that since this routine isn't compiler-generated it might be 
doing something different from what .cfi_startproc was designed for. However, I 
checked gas's behavior and the non-simple seems to be the right one after 
all: it sets up the CFA in the normal place, located through the stack pointer, 
and defines the return address's location relative to that. (Simple emits no 
opcodes at all.) 

 2. This is possible, but the frame is the most important.

I agree entirely, but why not fix the other registers while we're at it? I've 
attached a version of your diff with the extra registers' unwind info added--- 
untested, unfortunately--- it'll also need a 

  sub ::cfi_restore { ::emit(.cfi_restore,@_); }

in x86gas.pl and the corresponding stub for MASM.


Several of the other assembly files could use the same treatment as well: 
md5-x86_64.pl uses %rbp to point to one of its arguments, sha1-586.pl uses %ebp 
as a scratch register, etc.




cfi_fpo_2.diff
Description: Binary data

Re: [PATCH] cfi/fpo directives in md5 assembly code

[Wim Lewis]

On 27 Jun 2011, at 9:27 AM, yoni londner wrote:
 As you know, on 32bit systems, when using EBP for anything other than holding 
 the stack base, it is very difficult to get reasonable backtrace.
 this can be fixed if directing the compiler to add a debug record which tells 
 (at runtime) where we keep EBP value.
 So, I added this record (FPO in ml.exe and cfi in gcc), and now we can 
 debug/get backtrace at runtime.
 I also fixed source file name, so gdb find's it.
 Patch is attached (against openssl-1.0.0d.tar.gz), and I hope you will merge 
 it to trunk.

This seems like a good thing to fix.

I have some questions/comments:

1. Would it be better to use .cfi_startproc simple? The GAS documentation 
doesn't actually say what opcodes are emitted by cfi_startproc vs. simple (and 
I haven't taken the time to check), but I'd expect a frameless leaf procedure 
like this one not to want the default opcodes emitted for a normal procedure. I 
could be wrong.

2. We could add .cfi_offset directives for the other callee-saved registers as 
well (EBX, ESI, EDI).




__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2332] Issue while generating SSL certificate using Apache 2.216 + openssl 0.9.8o

[Wim Lewis]

On Sep 8, 2010, at 8:51 AM, shibu nair via RT wrote:
 We found that the error is due to the –days  option. And when we
 change the value 9996 this works fine. and  was working fine three
 date before (03-sept-2010. it seems to be issue related to the date
 range.

Well, January 1st, 2038 is approximately  days from now, and that's when 
the Unix time_t overflows 31 bits. IIRC, both of the actual certificate 
representations (UTCTIME and GENERALIZEDTIME) can handle timestamps outside 
that range, but openssl's ASN1_TIME_set() takes a time_t.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org