llext: add support for init arrays #76724
Conversation
This patch refactors the section table handling in the ELF loader to make it generic and prepare it for optional special sections. Signed-off-by: Luca Burelli <[email protected]>
Add support for the .preinit_array and .init_array sections in ELF files. These sections are arrays of function pointers that are filled by the compiler with the addresses of functions that need to be called at startup by the loader, such as C++ constructors. Supporting the .fini_array section requires more changes and is not currently implemented. Signed-off-by: Luca Burelli <[email protected]>
| @@ -630,6 +692,13 @@ int do_llext_load(struct llext_loader *ldr, struct llext *ext, | |||
| goto out; | |||
| } | |||
|
|
|||
| LOG_DBG("Calling init functions..."); | |||
| ret = llext_call_inits(ldr, ext); | |||
There was a problem hiding this comment.
This is changing the loading behavior from simple parse and copy of elf data to actually calling functions (executable code) in the elf file. Done outside of user mode even if a user wishes to sandbox an extension in a user mode thread.
We could do more validation/verification of symbolic linking. There's no way of validating these init functions aren't malicious.
I'm concerned this leaves a pretty large gap for untrusted code to inject malicious behavior and a user of llext may never know it.
Maybe its worth reviewing this behavior @ceolin
There was a problem hiding this comment.
Yep, the elf is assumed to be untrusted by now (since there is no authenticity / integrity check). Execute these functions in the kernel context is definitely a problem. Can you defer this initialization for after the elf is loaded, and the user be responsible to call it assuming it is untrusted ?
There was a problem hiding this comment.
Sure, this is a valid point. I will make the llext_call_inits function part of the API so the user will need to explicitly call it if it's needed.
In the future however I would like to find a way to make this process automatic, like it is done for Linux modules. Definitely needs at least some kind of validation and an "llext header" describing Zephyr related features (such as should the initi function be user or kernel space), though.
There was a problem hiding this comment.
FWIW SOF currently does sign its LLEXT objects and verifies signature correctness. If Zephyr decides to implement an API for this, SOF will probably also use it
There was a problem hiding this comment.
@lyakh I think Zephyr should provide infrastructure to that, there are too many caveats and pretty much everyone using LLEXT in products will need it.
There was a problem hiding this comment.
@pillo79 The Linux model is not exactly the same as here. Linux won't be blindly executing an userspace application in kernel context. If the module is trusted we may do how is proposed here, but we have to cover the untrusted case.
Maybe for untrusted modules we can sandbox the module before initializing it ?
There was a problem hiding this comment.
Besides the already discussed issue , LGTM.
As for the 'executing arbitrary code in kernel mode as part of loading' issue, one way forward I can see is to have the application perform the calls manually (using llext_find_section - however, new API might be needed, c.f. #74568 (comment)).
A reference implementation could be provided in LLEXT headers so that a single e.g. llext_execute_init_functions call is done from user application (would have to be in-header static inline - can't be a syscall since AFAIK, they always run in kernel mode, which we don't want here).
A second solution I see is adding a perform_init or w/e flag in struct llext_load_param, which defaults to false. One issue with this is how to distinguish between kernel and user extensions; it would also require the syscall to drop privileges and execute a tiny snippet of user code as part of its execution, which I'm not sure is possible in Zephyr.
|
Thanks for the feedback! Closing this in favor of #77641. |
Add support for the
.preinit_arrayand.init_arraysections in ELF files. These sections are arrays of function pointers that are filled by the compiler with the addresses of functions, such as C++ constructors, that need to be called at startup by the loader.Supporting the
.fini_array sectionrequires more changes and is not currently implemented.A test for this feature and several other C++-related changes will be forthcoming.