Guidance on Tools for Implementing Dynamic Plugin System in Firmware

Guidance on Tools for Implementing Dynamic Plugin System in Firmware

[Massimiliano Cialdi]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

Hello,

I am engaged in a firmware project with Cortex-M microcontrollers, focusing
on implementing dynamic plugin functionality. My setup includes FreeRTOS,
LittleFS, and gcc-arm-none-eabi.

I'm exploring creating a dynamic linker/loader for plugins. My queries are:

   1. *File Format and Loading:* Recommendations for file formats and
   loading strategies in a dynamic linker/loader system?
   2. *Function Entry Points:* Best practices for managing function entry
   points in non-PIC firmware for plugins?
   3. *Memory Management:* Managing different memory types (DTCM and SRAM)
   for plugin code and data.
   4. *Compilation and Linking:* Specific parameters or considerations for
   compiling and linking, including post-linking steps.
   5. *Security and Stability:* Ensuring safety and reliability when
   loading plugins dynamically.
   6. *Toolchain Adequacy:* Are the standard tools in the gcc-arm-none-eabi
   toolchain sufficient for this task, or is there a need for third-party
   tools or custom solutions?

Any advice, experiences, or references to similar projects would be
immensely helpful. Thank you!
best regards

-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi

Re: Guidance on Tools for Implementing Dynamic Plugin System in Firmware

[David Brown]

On 25/11/2023 17:41, Massimiliano Cialdi via Gcc-help wrote:
> Hello,
> 
> I am engaged in a firmware project with Cortex-M microcontrollers, focusing
> on implementing dynamic plugin functionality. My setup includes FreeRTOS,
> LittleFS, and gcc-arm-none-eabi.
> 
> I'm exploring creating a dynamic linker/loader for plugins. My queries are:
> 
>     1. *File Format and Loading:* Recommendations for file formats and
>     loading strategies in a dynamic linker/loader system?
>     2. *Function Entry Points:* Best practices for managing function entry
>     points in non-PIC firmware for plugins?
>     3. *Memory Management:* Managing different memory types (DTCM and SRAM)
>     for plugin code and data.
>     4. *Compilation and Linking:* Specific parameters or considerations for
>     compiling and linking, including post-linking steps.
>     5. *Security and Stability:* Ensuring safety and reliability when
>     loading plugins dynamically.
>     6. *Toolchain Adequacy:* Are the standard tools in the gcc-arm-none-eabi
>     toolchain sufficient for this task, or is there a need for third-party
>     tools or custom solutions?
> 
> Any advice, experiences, or references to similar projects would be
> immensely helpful. Thank you!
> best regards
> 

You are going to find a number of limitations here, but it is all 
workable.  Traditionally link/loading involves changes to at least some 
parts of the program image will loading, and that won't work since your 
code will be fixed in flash, and not loaded into ram.  So your key tool 
is indirection tables.  Your main code will provide a table of function 
pointers at a fixed address in flash, for each of the services it 
supports.  Your plugin has a struct type declared that matches the 
table, and accesses it through a cast pointer from this fixed address 
(in the same way as it accesses hardware peripherals).  You can have 
small wrappers to make these indirect functions callable as normal 
functions in your plugin code.

The service table here can also helpfully include other things like 
version numbers, pointers to structs of data, etc.  And it's also fine 
to have another level of indirection with the fixed address holding a 
pointer to this table rather than the table itself.

Similarly, the plugin will have a table of information and function 
pointers at a fixed address (or indirectly via a pointer at a fixed 
address).

This lets the main program and the plug access each other's services as 
needed.

You don't need anything beyond the normal tools to make all this work. 
It is not as scalable as a general dynamic library approach, but you 
wouldn't want that anyway in a microcontroller setting.  You want to 
have fixed sizes for things as much as possible - such as saying the 
main program gets the first 128 KB of DTCM and the plugin gets the other 
128 KB (assuming that's the available sizes, as an example).  I'd advise 
against trying to be /too/ flexible - even if you are using something 
like an NXP RT10xx device with run-time configurable choices of data and 
instruction tightly coupled memory, pick one setting and stick to it.

Security is not an easy question to answer because it it is far too 
dependent on circumstances and requirements.  It should be perfectly 
possible to have digital signatures included in the plugin's table and 
let the main program check it.  It is also possible to have the main 
program run in privileged mode and the plugin in unprivileged mode, and 
use the MPU to block the plugin from accessing some parts of memory and 
peripherals.  That does make things more complicated, however, since you 
need to use software interrupts to jump to privileged mode, which is 
less efficient than a simple indirect function call.  And it can 
complicate matters when using an RTOS that uses SWI to trigger the 
scheduler.

It is all possible, and can be done mainly using standard development 
tools.  You might, however, find it helpful to have a bit of 
post-processing of images - I personally use Python scripts to add 
things like checksums to binary images, and maybe you'll need a bit of 
that kind of thing.  The details will depend a great deal on exactly 
what you are trying to do, and as you are using FreeRTOS then you might 
find it useful to look for information specifically from that direction.

I don't think this mailing list is the right place for such discussions, 
however, since it is not a gcc-related issue.  But I hope I've given you 
a few helpful thoughts.

David