What happens if you just take the idea of a pluginnable security library (like #openssl’s provider interface), but decide to start fresh, with a blank page?

A few years ago, ideas started to simmer in my mind, and about two and a half years ago, I was ready to start typing things down.

The ideas revolved around a small core, that:

1. define a common structure to keep track of plugin implementations, and that works as a handle to call upon them
2. define a set of common generic plugin calls
3. define a way for implementations to specify parameters for which the calling application may add values
4. provide an environment structure to keep it all together
5. provide the basic structures within an environment to keep track of plugins and the diverse things they implement

1. A common structure to keep track of implementations

The idea was that any implementation could be represented by two pointers:

• a pointer to the implementation itself
• a pointer to implementation specific data (completely opaque to the caller)

The idea was also that these two pointers should be as generic as possible. For the implementation specific data, a void * is all it takes.

A pointer to the implementation itself needed some thought, and I ended up looking at syscall(2) and thinking that could be a suitable pattern, so ended up with something like this:

int (*impl)(T *o, int number, ...);

where T is the type for the structure having those two pointers, which would then look like this:

type struct T_st T;
struct T_st {
    int (*impl)(T *o, int number, ...);
    void *data;
};

This is the core idea from which almost everything else grew.

2. A set of common generic plugin calls

All calls to an implementation functions have names that are made from fairly generic patterns, to express their functionality in as general a way as possible, and hopefully with names that aren’t very hard to understand.

More on that in actual documenation.

3. A way for implementations to specify parameters

Implementations may specify any number of arbitrary parameters, together with a structured specification for each of them, so callers may know how parameter values are formed in memory, leaving the responsibility to form or understand the form of values correctly entirely on the caller.

4. An environment structure

All interactions with plugins require the caller to first set up a well known environment structure, where anyone can store data to be re-used at any time through the life time of the environment instance.

This is used to store anything that can be considered “global”, and must be allocated, and cleaned up, by the caller.

5. A basic structures to keep track of plugins and implementations

One of the “global” things that are supported with storage in the environment are plugins and their implementations. The implementations are registered into the environment by the plugin start function, and deregistered by the plugin stop function.

The plugins themselves are simply represented by two function pointers, one to start using what it offers, and one to stop.

Where to go look

If you’re curious and want to have a look, get over to Le’Sec’s web site.