[xmlsec] Configuration on 64-bit Linux

[Aleksey Sanin]

See answers in line.

Aleksey

On 11/8/11 7:52 AM, Bell, Bill wrote:
> Aleksey,
>
> Thank you for your response. I still have a couple of questions.
>
> You mention that "xmlSecSize was defined as 4 bytes on 64 bit platform for backward compatibility". Is ABI the only backward compatibility issue, or is there some other API-level compatibility that is of concern?

[aleksey] Correct. Only ABI is a concern.

> What is the intent for xmlSecSize? If ABI wasn't an issue, should it be size_t on 64-bit platforms? Do you believe that if it was defined to size_t on 64-bit platforms that there would be any issues?

[aleksey] There should be no issues if it is defined to size_t

>
> As a note, on Win64, xmlSecSize is defined to size_t, since the configuration is done via configure.js, not the regular configure script. It does not seem to cause a problem.
>
> Finally, I notice in the code, that there is a comment regarding changing the definition of xmlSecSize to a typedef. Presumably that will need to happen in a "significant release" (is that 2.x.x or 1.3.x?). Do you have a potential timeframe for such a change?

[aleksey] I don't have a timeframe, sorry. There should be enough 
reasons to break backward compatibility and this issue alone is not enough.

>
> Thanks,
> Bill
>
> -----Original Message-----
> From: Aleksey Sanin [mailto:aleksey at aleksey.com]
> Sent: Friday, November 04, 2011 2:03 PM
> To: Bell, Bill
> Cc: xmlsec at aleksey.com
> Subject: Re: [xmlsec] Configuration on 64-bit Linux
>
> Hi Bill,
>
> You need to define the XMLSEC_NO_SIZE_T flag. If you are using pkg config that comes with xmlsec then it should be defined there.
>
> The xmlSecSize was defined as 4 bytes on 64 bit platform for backward compatibility. Unfortunately, I can't simply make it
> 8 bytes because it will break binary ABI.
>
> Aleksey
>
> On 11/4/11 12:56 PM, Bell, Bill wrote:
>> Aleksey,
>>
>> I have a question regarding configuration of XML Sec on 64-Bit Linux.
>>
>> I have an application that crashes on 64-bit RHEL, it does not crash on other platforms (32/64-bit Windows, 32-bit RHEL).
>>
>> Working Environment:
>> XMLSec - version 1.2.16
>> OpenSSL - 1.0.0a
>> OS: RHEL5 - 64-bit
>> Compiler: GCC 4.1.2
>>
>> In debugging the problem, I have determined that the issue is that xmlSecSize is "unsigned int" in the library, and "size_t" in my application.
>> I have identified that the source of the problem is the configure script that correctly detects that size_t is 8 bytes, but then decides to define XMLSEC_NO_SIZE_T since it isn't 4.
>>
>> The problem is that my application is defining xmlSecSize to size_t and thus the sizes of the structures (in particular xmlSecEncCtx) are computed differently in the library and in my application code, leading to memory corruption when I set structure members.
>>
>> The line that triggers the problem is line 11793:
>> if test "$ac_cv_sizeof_size_t" -ne "4" ; then
>>       XMLSEC_DEFINES="$XMLSEC_DEFINES -DXMLSEC_NO_SIZE_T"
>> fi
>>
>> I have searched the archives and I found the following email threads:
>> [xmlsec] Xmlsec Issue on Linux x86_64, XMLSEC_NO_SIZE_T -
>> http://www.aleksey.com/pipermail/xmlsec/2007/008006.html
>> [xmlsec] Crash on Ubuntu -
>> http://www.aleksey.com/pipermail/xmlsec/2009/008778.html
>> FW: [xmlsec] Bug on hpux-ia64-64 ? -
>> http://www.aleksey.com/pipermail/xmlsec/2009/008759.html
>>
>> That all seem to be related to 64-bit platforms. Unfortunately, there doesn't seem to be a clear resolution to the problem in any of these threads.
>>
>> Per the question you posed in the first thread, I have checked out the most recent sources from GIT, and have run autogen.sh. It behaves the same as 1.2.16. Also, I have looked at the configure script in 1.2.18 and it has the same test.
>>
>> So, my question is: What should be the definition of xmlSecSize on 64-bit Linux platforms? Should it be "size_t" or "unsigned int"?
>>
>> If it should be size_t, I believe that the configure script can be updated to use:
>> if test "$ac_cv_sizeof_size_t" -ne "4"&&   test "$ac_cv_sizeof_size_t" -ne "8" ; then
>>       XMLSEC_DEFINES="$XMLSEC_DEFINES -DXMLSEC_NO_SIZE_T"
>> fi
>>
>> The questions in the HPUX thread are interesting ones. It seems like the reason that the author saw problems in the digest and signature functions is because of endianness, where the wrong word was getting the result value (the high-end word that was then truncated).
>> It looks like the OpenSSL API is a bit inconsistent (perhaps for backward compatibility). EVP_DigestUpdate() passes a size_t for the size argument, but EVP_DigestFinal() still passes an "unsigned int *".
>> So, this leads to another question: Has the XML Sec code been updated to ensure that the right type is passed to the underlying OpenSSL functions, and then cast'ed to xmlSecSize when they need to be saved?
>> If the answer to this is "yes", then it seems like it might be safe to allow xmlSecSize to be size_t (8-bytes) on 64-bit platforms.
>>
>> I appreciate your guidance on how to resolve this issue.
>>
>> My preference is to allow xmlSecSize to be size_t so that my internal users do not need to change anything, but I want to ensure that it is a safe definition. I do not see any warnings in the build logs, but I would like a more definite answer.
>>
>> Thanks in advance for your help,
>> Bill
>>
>> William Bell
>> Mentor Graphics Corporation
>> 720 494-1141 (Office)
>>
>> PRIVACY AND CONFIDENTIALITY NOTICE
>>
>> This email and any attachments may contain confidential or privileged information for the sole use of the intended recipient.  Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec