OpenSSL is designed to work in large, fully featured operating systems. It expects to find a filesystem, a networking stack and a full C library. All of these things are available in eCos. However, a full configuration of this sort can be very large, both in terms of the link library generated and the size of executables. This may not be appropriate for an embedded system with limited memory availability. To mitigate these effects, the eCos port for OpenSSL has been adapted to work in three basic configurations. Users can then adapt these further to their own needs.

Full Configuration

Accessing the complete functionality of OpenSSL requires a fully configured version of eCos. This should be based on the net template together with a number of additional packages and configurations. These additions are contained in the openssl_full.ecm file in the package misc directory. This configuration may be built using the following sequence of shell commands.

    $ mkdir openssl_full
    $ cd openssl_full
    $ ecosconfig new TARGET net
    $ ecosconfig import $ECOS_REPOSITORY/services/openssl/VERSION/misc/openssl_full.ecm
    $ ecosconfig resolve
    $ ecosconfig tree
    $ make

The same effect can be achieved from the graphical configtool by selecting the net template and then importing the ECM file.

Default Configuration

If no networking is available, openssl may still be built, but only the cryptographic and filesystem based functions may be used. This configuration is based on the default template which included file I/O functions and the C library, but no networking, plus the addition of an ECM file. This configuration may be built with the following sequence of commands, or the equivalent in the configtool:

    $ mkdir openssl_default
    $ cd openssl_default
    $ ecosconfig new TARGET default
    $ ecosconfig import $ECOS_REPOSITORY/services/openssl/VERSION/misc/openssl_default.ecm
    $ ecosconfig resolve
    $ ecosconfig tree
    $ make

Kernel Configuration

OpenSSL will also build in a minimal kernel only configuration. This will be based on the kernel template plus an ECM file. This may be built with the following commands, or the equivalent in the configtool:

    $ mkdir openssl_kernel
    $ cd openssl_kernel
    $ ecosconfig new TARGET kernel
    $ ecosconfig import $ECOS_REPOSITORY/services/openssl/VERSION/misc/openssl_kernel.ecm
    $ ecosconfig resolve
    $ ecosconfig tree
    $ make

This configuration is very basic, with no networking or file I/O, only the basic cryptographic functions will be available. The ECM file adds only STDLIB and Internationalization, mainly so that qsort() can be include; without this ASN1 support, and therefore most cryptographic components, cannot be built.

Serial Line Support

Some parts of the OpenSSL library read data from standard input; in particular some functions read passwords with echoing disabled. They achieve this by using TERMIOS functions on the device. For this to work correctly it is necessary to configure the standard I/O to use a serial driver, and to enable TERMIOS support on it. If you intend to use serial line 0 for this, then the following ECM fragment will set up the serial device correctly:

    cdl_configuration eCos {
        package CYGPKG_IO_SERIAL current ;

    # Enable serial device support
    cdl_component CYGPKG_IO_SERIAL_DEVICES {
	user_value 1 ;

    # Enable general TERMIOS support
    cdl_component CYGPKG_IO_SERIAL_TERMIOS {
        user_value 1;

    # Enable TERMIOS on serial 0
        user_value 1;

    # Switch standard I/O to TERMIOS device 0
        user_value "\"/dev/termios0\"";

Substitute a different serial device number for 0 in the above where necessary.

File System Dependencies

Much of OpenSSL can function without access to a filesystem. However, there are parts that expect to load or store data to or from files. If your application already uses a filesystem for other purposes (for example JFFS2 or YAFFS), then is should be easy to store OpenSSL's files there.

Where no external file store is available, the RAM filesystem can be used for temporary storage. The RAM filesystem can be mounted on system startup, and can be populated with files from data stored in memory. The following code shows how this might be done:

#define SERVER_CERT "/ram/server.pem"
static const char server_pem[] {

void init_ramfs( void )
    int fd;
    int err;
    size_t done;

    // Mount the RAM filesystem
    err = mount( "", "/ram", "ramfs" );
    if( err != 0 )
        diag_printf("RAMFS mount failed\n");

    // Write server.pem to RAM filesystem
    fd = open( SERVER_CERT, O_WRONLY|O_CREAT );
    done = write( fd, server_pem, sizeof(server_pem) );
    if( done != sizeof(server_pem) )
        diag_printf("server_pem write failed\n");

Constant files can also be stored in the ROM filesystem, using mkromfs to create a file tree that can then be mounted and read.

Configuring OpenSSL

In addition to configuring eCos for OpenSSL, OpenSSL also contains a number of configuration points. The OpenSSL sources have been separated into a number of components, mainly corresponding to specific cryptographic algorithms and other components. Each of these is controlled by its own CDL option. By default only a subset of components are enabled. Other components may be enabled individually and alternatively all components may be enabled by setting CYGPKG_OPENSSL_ALL.

Various components of OpenSSL depend on different sets of operating system functionality, such as networking or file I/O. OpenSSL has internal configuration options to control the inclusion of different functional elements. In general we try to use those to control the build process. We have also encoded some dependencies in the CDL, both internal and external, to control the inclusion of entire components. However, the OpenSSL code is not normally compiled in systems with missing functionality, so even if the CDL and OpenSSL dependencies are correct, it is still possible for builds to fail with compile or link errors.

Documentation license for this page: eCosPro License