LLEXT - security aspects

[ceolin]

LLEXT has emerged as a popular and powerful feature, enabling greater flexibility and
modularity in embedded systems. This functionality allows the dynamic
loading and unloading of code at runtime, without the need to
reboot the system or recompile the entire kernel.

While it offers significant advantages in flexibility and modularity, it also introduces
several security implications that must be carefully managed.

• Code authenticity and integrity
  Malicious extension could be loaded
  compromising the system. We need to verify the authenticity and
  integrity of extensions before they are loaded.

• Access control and permission
  Avoid excessive or unintended access to critical system resources. Usermode address
  this, but we need a proper way to setup kobjects and how to access them.
  Is dynamically creating kobjects needed ?

  Is there anything can be done without usermode ?

• Logging / auditing
  Logs and audits of extension activities related to loading and unloading

• Resource management
  Protection against DoS ?

• Legal considerations
  Extension licensing ?

[ceolin]

Some of these items are in the roadmap #71584

[teburd]

Relevant to this discussion are initializer functions seemingly from C++, see #76724

[marc-hb]

We asked some of these questions in the context of SOF but it wasn't the priority:

• llext: install modules appropriately for testing thesofproject/sof#9013 (review)
• llext: install modules appropriately for testing thesofproject/sof#9013 (comment)
• developer-guide: add LLEXT module documentation thesofproject/sof-docs#493