Windows BIO operation glitch

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Windows BIO operation glitch

Katie Lucas


Hello. We've been looking at using OpenSSL for various comms things;
we've prototyped the code on UNIX and I've started moving it over to
Windows.

We're using the binary distributions from Shining Light for Windows
compiling with Borland C++ Builder 6.0 , the source version from
OpenSSL.org for Linux. Linux works peachy.

PEM_read_X509 crashes. Now, I know this is a fairly well known thing,
and people said to go do the locking (which I did) and faff about with
the applink bit (which is a pain) but eventually that all seems sorted.

PEM_read_X509 still crashes.

I've been pulling code out of the source tree and installing it in the
project so I can debug it, and I've eventually narrowed it down to the
calls in bss_file... the part where it calls "bgets" through the BIO
method pointer.

I can call BIO_read() without any problem, but BIO_gets() takes ages
and then protection faults.

I can see nothing wrong with the method that ought to be being called
through that pointer so I pull that in to the project, set the
pointers up for it... and everything works.

So I have my own copy of "int file_gets(BIO *bp, char *buf, int size)"
and before I call PEM_read_X509 I say;

        BIO_s_file()->bgets = file_gets;

and now instead of crashing, the certificate loads fine.

The only alteration is that now "file_gets" lives in the app instead
of the statically linked library.

My question is, is this part of some known issue that I've missed
finding the documentation for? Or is this some sort of bizarre effect
of the Borland link/calling conventions?

Cheers for any help!


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Windows BIO operation glitch

Dr. Stephen Henson
On Mon, Sep 26, 2005, Katie Lucas wrote:

>
>
> Hello. We've been looking at using OpenSSL for various comms things;
> we've prototyped the code on UNIX and I've started moving it over to
> Windows.
>
> We're using the binary distributions from Shining Light for Windows
> compiling with Borland C++ Builder 6.0 , the source version from
> OpenSSL.org for Linux. Linux works peachy.
>
> PEM_read_X509 crashes. Now, I know this is a fairly well known thing,
> and people said to go do the locking (which I did) and faff about with
> the applink bit (which is a pain) but eventually that all seems sorted.
>
>

Well the FAQ doesn't mention locking...

The usual cause of this is a runtime library conflict. Some compilers (VC++ in
particular) have different runtime libraries for debugging and
multi-threading.

If the OpenSSL shared library is linked with one runtime library version and
the application uses another this can cause a conflict.

One particular area which can cause problems is stdio usage which you've hit
there with fgets().

The usual solution is make sure you use the same runtime library version with
OpenSSL DLLs and your application.

The applink code is another alternative, though I haven't tried that myself.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Windows BIO operation glitch

Andy Polyakov
In reply to this post by Katie Lucas
> We're using the binary distributions from Shining Light for Windows
> compiling with Borland C++ Builder 6.0 , the source version from
> OpenSSL.org for Linux. Linux works peachy.
>
> ... the applink bit (which is a pain) but eventually that all seems sorted.
>
> PEM_read_X509 still crashes.
>
> ...
>
> So I have my own copy of "int file_gets(BIO *bp, char *buf, int size)"
> and before I call PEM_read_X509 I say;
>
> BIO_s_file()->bgets = file_gets;
>
> and now instead of crashing, the certificate loads fine.
>
> The only alteration is that now "file_gets" lives in the app instead
> of the statically linked library.
>
> My question is, is this part of some known issue that I've missed
> finding the documentation for?

No, it's a bug: applink was not enganged for that particular call. See
http://cvs.openssl.org/chngview?cn=14467 for fix.

> Or is this some sort of bizarre effect
> of the Borland link/calling conventions?

But there is no guarantee that there no bizarre effects left. As far as
I understand above mentioned binary distribution is built with Visual C
and then Borland libs are obtained by format converting utility,
presumably coff2omf. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Windows BIO operation glitch

Thomas J. Hruska
Andy Polyakov wrote:

>> We're using the binary distributions from Shining Light for Windows
>> compiling with Borland C++ Builder 6.0 , the source version from
>> OpenSSL.org for Linux. Linux works peachy.
>>
>> ... the applink bit (which is a pain) but eventually that all seems
>> sorted.
>>
>> PEM_read_X509 still crashes.
>>
>> ...
>>
>> So I have my own copy of "int file_gets(BIO *bp, char *buf, int size)"
>> and before I call PEM_read_X509 I say;
>>
>>     BIO_s_file()->bgets = file_gets;
>>
>> and now instead of crashing, the certificate loads fine.
>>
>> The only alteration is that now "file_gets" lives in the app instead
>> of the statically linked library.
>>
>> My question is, is this part of some known issue that I've missed
>> finding the documentation for?
>
>
> No, it's a bug: applink was not enganged for that particular call. See
> http://cvs.openssl.org/chngview?cn=14467 for fix.
>
>> Or is this some sort of bizarre effect
>> of the Borland link/calling conventions?
>
>
> But there is no guarantee that there no bizarre effects left. As far as
> I understand above mentioned binary distribution is built with Visual C
> and then Borland libs are obtained by format converting utility,
> presumably coff2omf. A.

The Win32 OpenSSL Installation Project is built as follows:

Visual C++ 6 SP6 w/ MASM is used to build the core DLLs and the Visual
C++ libraries.

Borland's IMPLIB tool is used to create libraries from the DLLs for
Builder 4/5/6.

A combination of MinGW's dlltool and Borland's IMPDEF is used to create
the libraries for MinGW.

Several custom-built applications are used to tweak the headers
(#include files) a little so MinGW apps compile properly and the
included Perl binaries work as expected.

Then everything is packaged into a nice, neat installation using InnoSetup.

Most of this process is now automated, but it still takes a good couple
hours to build, package, test, and upload.


As to your specific problem, I haven't been following it up to this
point, but using FILE * from Builder inside OpenSSL is a great way to
crash the application.  Since Visual C++ has its own definition of FILE
and Builder has its own definition, attempting to pass in a Builder FILE
to a VC++ FILE will cause a crash.  OpenSSL provides a workaround by
using BIO's exclusively.  Since I can't tell if you are using FILE *
anywhere in relation to OpenSSL, I figure the information can't hurt any.

Also, directly modifying a BIO is, IMO, a bad idea because the
underlying structure could change between versions of OpenSSL and the
Win32 OpenSSL Installation Project is designed to be easily swapped with
future versions by the user.

Just a couple pennies.

--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL.
http://www.slproweb.com/

Ask me about discounts on any Shining Light Productions product!

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Windows BIO operation glitch

Andy Polyakov
> The Win32 OpenSSL Installation Project is built as follows:
>
> Visual C++ 6 SP6 w/ MASM is used to build the core DLLs and the Visual
> C++ libraries.
>
> Borland's IMPLIB tool is used to create libraries from the DLLs for
> Builder 4/5/6.
>
> As to your specific problem, I haven't been following it up to this
> point, but using FILE * from Builder inside OpenSSL is a great way to
> crash the application.  Since Visual C++ has its own definition of FILE
> and Builder has its own definition, attempting to pass in a Builder FILE
> to a VC++ FILE will cause a crash.

Applink is designed to address this very problem. It makes it possible
to pass e.g. Borland FILE* to OpenSSL 0.9>=8 DLL compiled with e.g. VC,
given that end-developer provides glue by compiling ms/applink.c with
her/his application. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Windows BIO operation glitch

Thomas J. Hruska
Andy Polyakov wrote:

>> The Win32 OpenSSL Installation Project is built as follows:
>>
>> Visual C++ 6 SP6 w/ MASM is used to build the core DLLs and the Visual
>> C++ libraries.
>>
>> Borland's IMPLIB tool is used to create libraries from the DLLs for
>> Builder 4/5/6.
>>
>> As to your specific problem, I haven't been following it up to this
>> point, but using FILE * from Builder inside OpenSSL is a great way to
>> crash the application.  Since Visual C++ has its own definition of
>> FILE and Builder has its own definition, attempting to pass in a
>> Builder FILE to a VC++ FILE will cause a crash.
>
>
> Applink is designed to address this very problem. It makes it possible
> to pass e.g. Borland FILE* to OpenSSL 0.9>=8 DLL compiled with e.g. VC,
> given that end-developer provides glue by compiling ms/applink.c with
> her/his application. A.

BIOs are a more appropriate solution, IMO.  They are generic and have
better success rates when writing cross-platform code.  I have not
encountered any Borland Builder users who have had problems after
switching their code to use BIOs and BIO calls exclusively when
interfacing with OpenSSL.

--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL.
http://www.slproweb.com/

Ask me about discounts on any Shining Light Productions product!

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Windows BIO operation glitch

Katie Lucas
In reply to this post by Thomas J. Hruska
On Thu, Sep 29, 2005 at 02:05:42PM -0400, Thomas J. Hruska wrote:

> Andy Polyakov wrote:
> >>We're using the binary distributions from Shining Light for Windows
> >>compiling with Borland C++ Builder 6.0 , the source version from
> >>OpenSSL.org for Linux. Linux works peachy.
> >>
> >>... the applink bit (which is a pain) but eventually that all seems
> >>sorted.
> >>
> >>PEM_read_X509 still crashes.
> >>
> >>...
> >>
> >>So I have my own copy of "int file_gets(BIO *bp, char *buf, int size)"
> >>and before I call PEM_read_X509 I say;
> >>
> >>    BIO_s_file()->bgets = file_gets;
> >>
> >>and now instead of crashing, the certificate loads fine.
> >>
> >>The only alteration is that now "file_gets" lives in the app instead
> >>of the statically linked library.
> >>
> >>My question is, is this part of some known issue that I've missed
> >>finding the documentation for?
> >
> >
> >No, it's a bug: applink was not enganged for that particular call. See
> >http://cvs.openssl.org/chngview?cn=14467 for fix.
> >
> >>Or is this some sort of bizarre effect
> >>of the Borland link/calling conventions?
> >
> >
> >But there is no guarantee that there no bizarre effects left. As far as
> >I understand above mentioned binary distribution is built with Visual C
> >and then Borland libs are obtained by format converting utility,
> >presumably coff2omf. A.
>
> The Win32 OpenSSL Installation Project is built as follows:
>
> Visual C++ 6 SP6 w/ MASM is used to build the core DLLs and the Visual
> C++ libraries.
>
> Borland's IMPLIB tool is used to create libraries from the DLLs for
> Builder 4/5/6.
>
> A combination of MinGW's dlltool and Borland's IMPDEF is used to create
> the libraries for MinGW.
>
> Several custom-built applications are used to tweak the headers
> (#include files) a little so MinGW apps compile properly and the
> included Perl binaries work as expected.
>
> Then everything is packaged into a nice, neat installation using InnoSetup.
>
> Most of this process is now automated, but it still takes a good couple
> hours to build, package, test, and upload.
>
>
> As to your specific problem, I haven't been following it up to this
> point, but using FILE * from Builder inside OpenSSL is a great way to
> crash the application.  Since Visual C++ has its own definition of FILE
> and Builder has its own definition, attempting to pass in a Builder FILE
> to a VC++ FILE will cause a crash.  OpenSSL provides a workaround by
> using BIO's exclusively.  Since I can't tell if you are using FILE *
> anywhere in relation to OpenSSL, I figure the information can't hurt any.
>
> Also, directly modifying a BIO is, IMO, a bad idea because the
> underlying structure could change between versions of OpenSSL and the
> Win32 OpenSSL Installation Project is designed to be easily swapped with
> future versions by the user.

The greif appears to be that the FILE*s are being created by some of
the X509 operations -- instead of using BIO_new_file(), they call
fopen() and then BIO_set_fd().

I wasn't aware the FILE structures are different, but this certainly
explains the end results.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Windows BIO operation glitch

Thomas J. Hruska
Katie Lucas wrote:

> On Thu, Sep 29, 2005 at 02:05:42PM -0400, Thomas J. Hruska wrote:
>
>>Andy Polyakov wrote:
>>
>>>>We're using the binary distributions from Shining Light for Windows
>>>>compiling with Borland C++ Builder 6.0 , the source version from
>>>>OpenSSL.org for Linux. Linux works peachy.
>>>>
>>>>... the applink bit (which is a pain) but eventually that all seems
>>>>sorted.
>>>>
>>>>PEM_read_X509 still crashes.
>>>>
>>>>...
>>>>
>>>>So I have my own copy of "int file_gets(BIO *bp, char *buf, int size)"
>>>>and before I call PEM_read_X509 I say;
>>>>
>>>>   BIO_s_file()->bgets = file_gets;
>>>>
>>>>and now instead of crashing, the certificate loads fine.
>>>>
>>>>The only alteration is that now "file_gets" lives in the app instead
>>>>of the statically linked library.
>>>>
>>>>My question is, is this part of some known issue that I've missed
>>>>finding the documentation for?
>>As to your specific problem, I haven't been following it up to this
>>point, but using FILE * from Builder inside OpenSSL is a great way to
>>crash the application.  Since Visual C++ has its own definition of FILE
>>and Builder has its own definition, attempting to pass in a Builder FILE
>>to a VC++ FILE will cause a crash.  OpenSSL provides a workaround by
>>using BIO's exclusively.  Since I can't tell if you are using FILE *
>>anywhere in relation to OpenSSL, I figure the information can't hurt any.
>>
>>Also, directly modifying a BIO is, IMO, a bad idea because the
>>underlying structure could change between versions of OpenSSL and the
>>Win32 OpenSSL Installation Project is designed to be easily swapped with
>>future versions by the user.
>
>
> The greif appears to be that the FILE*s are being created by some of
> the X509 operations -- instead of using BIO_new_file(), they call
> fopen() and then BIO_set_fd().
>
> I wasn't aware the FILE structures are different, but this certainly
> explains the end results.

That's the first thing to look for when dealing with DLLs.  You have to
be _VERY_ careful to segment the application from the DLL or there will
be problems.  In this case, calling fopen() and then BIO_set_fd()
creates a bogus BIO because the FILE is owned by the application while
the BIO is owned by the DLL.  Both the FILE _and_ the BIO should be
owned by the DLL in order to keep the application segmented from the
DLL...BIO_new_file() solves that problem and creates cross-platform,
cross-compiler safe code at the same time.

--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL.
http://www.slproweb.com/

Ask me about discounts on any Shining Light Productions product!

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]