• Registered: 2012-11-04
  • Posts: 10

Topic: Porting wolfSSL embedded SSL 2.4.0 in LWip TCP/IP stack

Hello,

I am assigned to port wolfSSL embedded SSL 2.4.0 on our API! Our wireless embedded system support lwip tcp/ip stack and I need to make the application as lighter as it can get! On the kernel the system runs the libraries of
chiBios( http://chibios.sourceforge.net/docs/ker … index.html ) and we do not support file system! I want to ask for your advice on which definitions I need to make on settings.h so to use wolfSSL for LWIP tcp/ip stack with no file system!

Thank you.

Share

2 Reply by andreas20488 (edited by andreas20488 2012-11-04 08:59:52)

  • Registered: 2012-11-04
  • Posts: 10

Re: Porting wolfSSL embedded SSL 2.4.0 in LWip TCP/IP stack

To be more specific our module has 768kbytes FLASH and 96kbyteds SRAM. We need to intagrade wolfSSL in our existing library.
So far in the settings.h I have this

#ifdef MY_EMBEDDED
        #define WOLFSSL_LWIP
    #define NO_FILESYSTEM
    #define NO_WRITEV
#endif

and I need help on what else I should define for a lwip and low memory use of wolfSSL

Thank you.

Share

  • From: Bozeman, MT
  • Registered: 2010-10-20
  • Posts: 650

Re: Porting wolfSSL embedded SSL 2.4.0 in LWip TCP/IP stack

Hi,

Thanks for using wolfSSL!  It looks like you are on the right track for getting wolfSSL to work with LwIP and your OS (chiBios).  Other than TCP/IP stack and file system, other things you may need to modify are:

1)  Threading - do you need multi-threaded support, or is single threaded ok?  If single threaded is ok, you can define SINGLE_THREADED to disable the mutex layer.  If you want multi threading, you'll need to add support for your OS's mutex layer.

2)  Memory - does your OS support standard memory functions (malloc, realloc, free)?  If not, you'll need to address this by defining your own custom XMALLOC, XFREE, and XREALLOC as some of the other OS ports in settings.h do.

3)  Random seed - do you have access to /dev/random?  If not, you'll need to write your own GenerateSeed function in ./ctaocrypt/src/random.c.

4)  Other things to double check include endianness (wolfSSL defaults to little endian.  If your platform is big endian, define BIG_ENDIAN_ORDER), and that you have sizeof long and sizeof long long defined correctly for your platform.

You can find a list of defines and general instructions for building wolfSSL in a non-standard environment in Chapter 2 of the wolfSSL manual (http://yassl.com/yaSSL/Docs-cyassl-manu … yassl.html).

Can you tell me more about your project?  What kind of wireless embedded system are you working on?

Best Regards,
Chris

https://www.wolfssl.com

chrisc's Website

Share

4 Reply by andreas20488 (edited by andreas20488 2012-11-07 07:00:27)

  • Registered: 2012-11-04
  • Posts: 10

Re: Porting wolfSSL embedded SSL 2.4.0 in LWip TCP/IP stack

Hello Chris,

Thank you very much for your advice, since I am new on SSL I found them really helpfull!

I follow all the of your steps. So far my definitions are as follows
#ifdef ECONAIS
    #include "libwismart.h"
       #define WOLFSSL_LWIP
    #define NO_FILESYSTEM
    #define NO_WRITEV
//    #define NO_DEV_RANDOM
    #define XMALLOC(s, h, type) ((void *)chHeapAlloc(NULL,(s)))
        #define XFREE(p, h, type) do{if(p){chHeapFree(p);}}while(0);
//     #define XREALLOC(p, n, h, t) //Since ChiBios do not has realloc I create my own realloc "XREALLOC" and it is as post it here(if you can take a quick view to tell me if it seems right to you I would be pleased).
#endif

void *XREALLOC (void *ptr, size_t size) {
    void *newptr;

    // Allocate new block, returning NULL if not possible.
    newptr = XMALLOC (size,0,DYNAMIC_TYPE_BIGINT);
    if (newptr == NULL) return NULL;

    // Don't copy/free original block if it was NULL.
    if (ptr != NULL) {

        // Copy the memory, free the old block and return the new block.

        XMEMCPY (newptr, ptr, size);
        XFREE (ptr,0,DYNAMIC_TYPE_BIGINT);
    }

    return newptr;
}

Moreover I added in internal.h our definition for mutexes
#ifdef SINGLE_THREADED
    typedef int wolfSSL_Mutex;
#else /* MULTI_THREADED */
    #ifdef ECONAIS
        typedef Mutex wolfSSL_Mutex;

Finally I write my own GenerateSeed and is as shown below

int GenerateSeed(OS_Seed* os, byte* output, word32 sz)
{
    int i;
    for (i = 0; i < sz; i++ ) {
        output[ i ] = chTimeNow() % 256;
    }


    return 0;
}

chTimeNow returns the msec since the program started.

I also used chTimeNow instead of gettimeofday(we do not support gettimeofday) and I do not know if I will have any problem with it!?

To your question my project as I said is to create SSL over our existing TCP/IP Stack and I am trying to do so by porting wolfSSL. The wireless embedded system that I am working on is EC32S13 ( http://www.econais.com/wp/?page_id=114 )!
On the website you can find a lot of information on who we are and what we do! If have any queries about us please feel free to ask and we will be glad to answer your question.

Yours sincerely,
Andreas

Share

  • From: Bozeman, MT
  • Registered: 2010-10-20
  • Posts: 650

Re: Porting wolfSSL embedded SSL 2.4.0 in LWip TCP/IP stack

Hi Andreas,

Since ChiBios do not has realloc I create my own realloc "XREALLOC"

Another option (if you choose) instead of writing your own realloc() implementation would be to use the fastmath library instead of the normal big integer library.  By default wolfSSL/wolfCrypt uses the normal big integer math library, which uses quite a bit of dynamic memory.  When building wolfSSL, you are able to enable the fastmath library, which is both faster and uses no dynamic memory (all on the stack).  By using fastmath, wolfSSL won't need a realloc implementation at all - just malloc() and free().

When building wolfSSL with ./configure, you can enable the fastmath library with --enable-fastmath.  If you're not using ./configure, you can define USE_FAST_MATH and build in tfm.c instead of integer.c.  Since the stack memory can be large, we recommend defining TFM_TIMING_RESISTANT when using fastmath.

void *XREALLOC (void *ptr, size_t size) {
    void *newptr;
    // Allocate new block, returning NULL if not possible.
    newptr = XMALLOC (size,0,DYNAMIC_TYPE_BIGINT);
    if (newptr == NULL) return NULL;
    // Don't copy/free original block if it was NULL.
    if (ptr != NULL) {
        // Copy the memory, free the old block and return the new block.
        XMEMCPY (newptr, ptr, size);
        XFREE (ptr,0,DYNAMIC_TYPE_BIGINT);
    }
    return newptr;
}

It looks like there's a bug in your realloc() implementation.  If the size of the original pointer is smaller than the size being passed to realloc(), you will end up accessing memory that doesn't belong to you.  If the old pointer is smaller and at the end of a page, trying to read into the next page will result in a segmentation fault if the next page hasn't been committed, has the wrong permissions, etc.

int GenerateSeed(OS_Seed* os, byte* output, word32 sz)
{
    int i;
    for (i = 0; i < sz; i++ ) {
        output[ i ] = chTimeNow() % 256;
    }

    return 0;
}

Your GenerateSeed() function has very little randomness - for a couple of reasons.  The first being that chTimeNow() could return the same value on multiple runs of the application (since chTimeNow() returns the number of milliseconds since the program started).  Another problem is that, even on a slow processor (100MHz), given that there are 100,000 instructions available per millisecond it's highly likely that all 32 bytes will have the same value, turning the "random" seed from 2^256 possible values into 256 different values.

Although we don't recommend a specific way to get randomness on an embedded device, the ideal method would be to get it from a good hardware source somewhere.

The wireless embedded system that I am working on is EC32S13

Neat!  That sounds interesting.  When you're finished with the port, we'd be willing to try to roll your port back into wolfSSL if possible.

Best Regards,
Chris

https://www.wolfssl.com

chrisc's Website

Share