[openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error
This should be fixed in 0.9.8 . As we don't want to backport the necessary changes to 0.9.7 I close this ticket. Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
Hi Jim, The C abstract machine definition doesn't take into account multi-processing and therefore ignores memory operation reordering as seen by external observers. Volatile means little more than "don't keep this variable in a register, it must be accessed directly from memory". It however doesn't specify anything about whether tha variable can exist in cache, or whether accesses to it can be reordered around other memory accesses. As long as volatile variables aren't kept in a register and are accessed directly from [cached] memory then cache coherency will take care of keeping the cache in sync with external memory (note that for memory-mapped devices, the device driver must have disabled caching for that region of memory). The problem of reordering being dicussed here doesn't result in incorrect values being read (cache coherency, for example, takes care of that), it's to do with assumptions being made about the order of memory operations mapping to the order of operations specified in code. DCLP is based on the assumption that the order of memory operations occurs in the same sequence as specified in the source code, and in modern MP systems that is rarely the case. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Schneider Sent: Friday, 8 April 2005 7:35 AM To: openssl-dev@openssl.org Subject: Re: OpenSSL use of DCLP may not be thread-safe on multiple processors On Thursday 07 April 2005 16:39, David Schwartz wrote: A bit off-topic, but... > If you mean 'volatile', no, that doesn't do anything. Specifically, > 'volatile' has no special semantics for multi-processors. There may be > specific compilers where it has such semantics, but the standard > doesn't provide them. According to ISO 9899-1990, section 6.5.3: An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, EXCEPT AS MODIFIED BY THE UNKNOWN FACTORS MENTIONED PREVIOUSLY [emphasis added]. Translation: The compiler can't make assumptions about the state of a variable marked "volatile", and MUST generate code that writes every result stored there as well as code that reads the variable EVERY SINGLE TIME it appears in an expression. It has nothing to do with multi-processor coherency. Any compiler that generates code that deviates from this (even a little bit) isn't compliant with the standard. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
> On Thursday 07 April 2005 16:39, David Schwartz wrote: > A bit off-topic, but... > > If you mean 'volatile', no, that doesn't do anything. Specifically, > > 'volatile' has no special semantics for multi-processors. There may be > > specific compilers where it has such semantics, but the standard doesn't > > provide them. > According to ISO 9899-1990, section 6.5.3: > An object that has volatile-qualified type may be modified in > ways unknown to > the implementation or have other unknown side effects. Therefore any > expression referring to such an object shall be evaluated > strictly according > to the rules of the abstract machine, as described in 5.1.2.3. > Furthermore, > at every sequence point the value last stored in the object shall > agree with > that prescribed by the abstract machine, EXCEPT AS MODIFIED BY > THE UNKNOWN > FACTORS MENTIONED PREVIOUSLY [emphasis added]. > Translation: The compiler can't make assumptions about the state of a > variable marked "volatile", and MUST generate code that writes > every result > stored there as well as code that reads the variable EVERY SINGLE TIME it > appears in an expression. It has nothing to do with multi-processor > coherency. Any compiler that generates code that deviates from > this (even a > little bit) isn't compliant with the standard. If this were true, every compiler I know of would fail to comply with the standard if it didn't bypass any write-back caches on writes to volatile variables. After all, those "unknown factors" could modify the memory directly, couldn't they? However, your translation is incorrect. The standard is not talking about the compiler, but the system as a whole. It is not saying what the compiler must do but what the compiler must emit code to make the system as a whole do. The reason this doesn't require write-back caches to be disabled is because the abstract machine doesn't make it clear where the object is. Is the object the physical memory chips? The memory as seen through the cache? Or what? DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL use of DCLP may not be thread-safe on multiple processors
On Thursday 07 April 2005 16:39, David Schwartz wrote: A bit off-topic, but... > If you mean 'volatile', no, that doesn't do anything. Specifically, > 'volatile' has no special semantics for multi-processors. There may be > specific compilers where it has such semantics, but the standard doesn't > provide them. According to ISO 9899-1990, section 6.5.3: An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, EXCEPT AS MODIFIED BY THE UNKNOWN FACTORS MENTIONED PREVIOUSLY [emphasis added]. Translation: The compiler can't make assumptions about the state of a variable marked "volatile", and MUST generate code that writes every result stored there as well as code that reads the variable EVERY SINGLE TIME it appears in an expression. It has nothing to do with multi-processor coherency. Any compiler that generates code that deviates from this (even a little bit) isn't compliant with the standard. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
> It strikes me that the H/W designers have played a bit "fast and > loose" with > the cache consistency issue here For the vast majority of cases, this is a pure speed boost. For the tiny number of cases where it causes a problem, you use mutexes. > - I believe I understand the C/C++ > optimisation issues, and these CAN be worked around (IMHO) within > the rules > of the standard by using bool in some cases. If you mean 'volatile', no, that doesn't do anything. Specifically, 'volatile' has no special semantics for multi-processors. There may be specific compilers where it has such semantics, but the standard doesn't provide them. This is a frequently-spread bit of misinformation, largely due to specific cases wher 'volatile' has been made to have such semantics by magic that's not clearly visible in the cases. If the C standard really prohibited a compiler from re-ordering writes to volatile variables, it would likewise prohibit the cache from doing so. Do you know of any C implementations that make writes to volatile variables bypass write-back caches? > However I've notified our dev folks to remove the few cases where > we've used > this technique as it is certainly dangerous. Thanks. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: intrested in participate on openssl development
> Are there small parts in openssl where I can help? (review, > documentation, programming) > I don't found much about things to do while reading the Mailinglist. > > If you are interested in my help, please send answer. > > greetings > wof I'm just someone who ports OpenSSL to a platform for others to use, and not an openssl team member, so this is my personal opinion, not that of my employer or any group. I encourage you to work on the documentation. In my experience, there are vast areas of OpenSSL that would benefit from accurate, up-to-date documentation. Maybe I missed a doc page somewhere, but I found that even answering fairly basic questions like "which encryption protocols are supported" are surprisingly hard to answer without reading source code. If you want to write code, how about ensuring that the test suite that ships with the package executes 100% of the source statements (or as close to that as possible)? Not that C0 code coverage is sufficient, but it is a good place to start. I'm guessing that we can always use more and better tests. The test suite is a lifesaver when porting OpenSSL to a new platform, or when making bug fixes. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Voice: +1 978-461-7557; FAX: +1 978-461-3610; AIM: PaulGreen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
It's all in the interest of increased processing speed. Tighter models, such as strict ordering, are inherently slower than reordering models. The more reordering that can be done the better performance can be. Write combining buffers are an extreme example where overwriting the same address in memory can result in only the final value actually being written to the memory bus (ie. the initial and intermediate writes to the same address never make it to the bus), however these are usually only used for specific memory-mapped devices such as video frame buffers. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David C. Partridge Sent: Thursday, 7 April 2005 6:17 PM To: openssl-dev@openssl.org Subject: RE: OpenSSL use of DCLP may not be thread-safe on multiple processors Thanks all. It strikes me that the H/W designers have played a bit "fast and loose" with the cache consistency issue here - I believe I understand the C/C++ optimisation issues, and these CAN be worked around (IMHO) within the rules of the standard by using bool in some cases. However I've notified our dev folks to remove the few cases where we've used this technique as it is certainly dangerous. Dave __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL use of DCLP may not be thread-safe on multiple processors
Thanks all. It strikes me that the H/W designers have played a bit "fast and loose" with the cache consistency issue here - I believe I understand the C/C++ optimisation issues, and these CAN be worked around (IMHO) within the rules of the standard by using bool in some cases. However I've notified our dev folks to remove the few cases where we've used this technique as it is certainly dangerous. Dave __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
