Hi,
Hope this is going to help you on your way to Embedded OpenSSL.
----- Original Message -----
From: "wangqing2000" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 22, 2001 9:01 AM
Subject: how to cut out openSSL?
> Hi,
> I want to port openSSL to embeded system.And we use our OS without File
systems. So I must cut out openSSL .
> please give me some advice , such as dropping some algorithms,and so
forth.
> what and how to do?
I've done this for another embedded environment (portable embedded TCP/IP
stack) and the way I chose to resolve this was (the reasons *why* are at the
bottom of this email):
1) reroute all RTL calls (i.e. fopen/fwrite/fprintf/etc.) to my own wrapper
routines, which would 'fake' their operation. (you might for instance
convert any 'files', such as CA certificates, etc. to 'char []' arrays,
which are addressed through a lookup-table used by your wrapper functions,
which replace fopen/fread/fclose/fgets/etc.)
I can only say: "Praise the Lord for the C preprocessor" ;-)
Sample lines from your 'wrapper/rerouter headerfile' to get the idea:
---
#define fopen my_wrapper_for_fopen
#define fread my_wrapper_for_fread
/* and so on... */
MY_FAKE_FILE *my_wrapper_for_fopen(const char *filename, const char *mode);
---
2) write an awk (or perl, or ...) script which seeks out all those #include
<standard RTL headerfile.h> include-lines in the OpenSSL sources and rewrite
each so it looks something like this:
#if defined(MY_EMBEDDED_PORT)
#include "my_rerouter_headerfile.h"
#else
#include <standard RTL headerfile as we've found it.h>
#endif
3) Of course the devil is in the details with the method used above in
1)+2), so there's one requirement for the man/woman doing the porting: they
should be fluent with the C preprocessor.
4) Once you're done with 1)+2), *check* your port by trying to build
(compile+link, *don't run*) the OpenSSL test tool (apps/openssl.c) while
forcing your linker to *IGNORE* any RTL library you might use in a regular
build.
This 'weird' step (you're not supposed to end up with a built binary file!)
shows you which RTL functions you didn't port, as all linkers I know are so
friendly to report which object files use those 'undefined symbol xxxx' RTL
symbols. If you did a 'good job', your Embedded OpenSSL should only use
those RTL functions that you really have (e.g. strcmp et al) and NOT list
any other RTL functions as 'undefined' in the OpenSSL objects. If not,
you'll need to 'wrap' those too. (You may have forgotten to 'wrap' gmtime(),
localtime() and time() for instance.)
5) Once this is done, you're very close to a ported OpenSSL library+tools.
Depending on your embedded system, you might wish to throw away several
ciphers, by putting the relevant
#define NO_<cipher>
(e.g.
#define NO_IDEA
#define NO_RC2
#define NO_RC4
#define NO_RC5
)
defines in your porting headerfile(s) or as predefined symbols in your
makefiles.
Most of these define's already exist in OpenSSL 0.9.6 yet you might wish to
add a few. (I know I did).
Next, there are some savings to be gained by specifying
#define NO_SSL2
, thus removing the SSLv2 protocol materials. There's also a NO_SSL3 and
NO_TLS1 btw.
OK, so your binary is still huge. Now is probably the time to consider what
you *really* need as from here on, you'll have to 'seek & destroy' any code
you do not want.
A hint: some embedded-systems compilers come with 'stupid'
linkers/relocators: throw ALL openssl code in a library to enable the linker
to 'strip' any routines you don't use.
In a Microsoft-compiler based environment (for embedded boards with an Intel
80x86 CPU) you can add the /Gy switch to your compiler settings to instruct
the compiler to create object files that are split up: one linkable piece
per function. Some other compilers support this type of option too. This
allows the linker to strip a few more routines that are not in your active
call-tree.
And last but not least: check your MAP files to see if you find anything
that can be stripped. (NO_ERR for instance throws away all those helpful
error messages.)
-----
Why did I do this this way?
A) Because my embedded environment assumes you've only a VERY minimal RTL
subset available (remember: tiny embedded systems don't profer richly
flavored things such as fopen() et al.) So basically I offer almost all the
RTL functionality OpenSSL needs in my 'wrapper/rerouter code'. For me, this
was very important, as my 'embedded environment' is a TCP/IP stack which is
portable across multiple platforms & CPUs. So I can only assume the worst:
no RTL at all.
B) 'Adding' the wrapper/rerouter seems contra-productive as it ADDS code
instead of reducing it. Nevertheless I am now capable of migrating along
with major OpenSSL updates (just updated to 0.9.6 last week within a day,
including some basic tests).
The wrapper introduces 'minimal changes' within the OpenSSL source tree, so
my 'upgrades' can be largely automated (a big plus IMHO).
C) Using this mechanism I can 'rebuild' the OpenSSL code on UNIX and Win32
systems using only minimal effort.
That is: I want to use the *exact* same OpenSSL source tree to build in my
embedded environment AND on Win32 (and Linux).
So I provide 'faked' wrappers for Win32 and Linux (rerouting FILE I/O back
to fopen() et al :-) ). I can now test my own, 'personalized' OpenSSL tree
on systems with *GOOD* debuggers and see what happens under those well-known
'weird conditions' ;-) and see if I screwed up significantly during
'porting'. 80% of the errors I run into are reproducable on my Win32/Linux
builds, so my debugging/analysis turn-around time is significantly reduced.
(Ever tried debugging a 'big' (ahem) embedded system using a 9600 baud link?
You get the point ;-) )
Sorry if this is a lot all at once, but this should at least give you enough
info to see how & why I did it (and succeeded). If you have any bright ideas
or feedback on this, you're most welcome :-)
My meager attempt at giving back to OpenSource :-)
Best wishes,
Ger
Gerrit E.G. 'Insh_Allah' Hobbelt
Senior Software Engineer
PAC L&I
Netherlands
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
