Open Source Embedded SSL - (License and Memory)

J Harper jsec at
Thu Nov 27 03:52:08 EST 2003

> 1) Not GPL or LPGL, please.  I'm a fan of the GPL for most things, but

> for embedded software, especially in the security domain, it's a 
> killer.  I'm supposed to allow users to modify the software that runs 
> on their secure token?  And on a small platform where there won't be 
> such things as loadable modules, or even process separation, the 
> (L)GPL really does become viral.  This is, I think, why Red Hat 
> releases eCos under a non-GPL (but still open source) license.

We're aware of these issues.  How do other people on the group feel?

> 2) Make it functional on systems without memory allocation.  Did I 
> mention that I work on (very) small embedded systems?  Having fixed 
> spaces for variables is useful when you want something to run 
> deterministically for a long time with no resets, and I have yet to 
> find a free bignum library that didn't want to use malloc all the 
> time.

We have implemented a block allocation scheme for our device Web
services product that would probably solve this issue.  Queues of
various structure sizes are held within a single chunk of memory.  This
has the nice side effect of cleaning up any leaked memory when freed.
If the demand is there we'll consider releasing the source for this as
well.  Doing an apache style per-session memory pool for SSL sessions
would be a nice way to make sure all memory was freed after each SSL
session closes.  For now we use the classic #define sslMalloc malloc,
and let you swap in your own implementation if desired.

J Harper
PeerSec Networks

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list