llext: introduce 'enum llext_storage_type'

This patch introduces an 'enum llext_storage_type' that defines the
storage type of the ELF data that will be loaded:

- LLEXT_STORAGE_TEMPORARY: ELF data is only available during
  llext_load(); even when the loader supports directly accessing the
  memory via llext_peek(), the buffer contents will be discarded
  afterwards.
  LLEXT will allocate copies of all required data into its heap.

- LLEXT_STORAGE_PERSISTENT: ELF data is stored in a *read-only* buffer
  that is guaranteed to be always accessible for as long as the
  extension is loaded.
  LLEXT may directly reuse constant data from the buffer, but may still
  allocate copies if relocations need to be applied.

- LLEXT_STORAGE_WRITABLE: ELF data is stored in a *writable* memory
  buffer that is guaranteed to be always accessible for as long as the
  extension is loaded.
  LLEXT may freely modify and reuse data in the buffer; so, after the
  extension is unloaded, the contents should be re-initialized before a
  subsequent llext_load() call.

To keep full compatibility with existing code, the storage type of
LLEXT_BUF_LOADER is determined by the CONFIG_LLEXT_STORAGE_WRITABLE Kconfig
option between LLEXT_STORAGE_PERSISTENT and LLEXT_STORAGE_WRITABLE.

Signed-off-by: Luca Burelli <[email protected]>

Author: pillo79

include/zephyr/llext/buf_loader.h

@@ -56,6 +56,9 @@ void *llext_buf_peek(struct llext_loader *ldr, size_t pos);
 				.seek = llext_buf_seek,                                            \
 				.peek = llext_buf_peek,                                            \
 				.finalize = NULL,                                                  \
+				.storage = IS_ENABLED(CONFIG_LLEXT_STORAGE_WRITABLE) ?             \
+			                        LLEXT_STORAGE_WRITABLE :                           \
+				                LLEXT_STORAGE_PERSISTENT,                          \
 			},                                                                         \
 		.buf = (_buf),                                                                     \
 		.len = (_buf_len),                                                                 \

include/zephyr/llext/fs_loader.h

@@ -57,6 +57,7 @@ void llext_fs_finalize(struct llext_loader *ldr);
 				.seek = llext_fs_seek,                                             \
 				.peek = NULL,                                                      \
 				.finalize = llext_fs_finalize,                                     \
+				.storage = LLEXT_STORAGE_TEMPORARY,                                \
 			},                                                                         \
 		.is_open = false,                                                                  \
 		.name = (_filename),                                                               \

include/zephyr/llext/loader.h

@@ -32,6 +32,44 @@ extern "C" {
 struct llext_elf_sect_map; /* defined in llext_priv.h */
 /** @endcond */
 
+/**
+ * @brief Storage type for the ELF data to be loaded.
+ *
+ * This enum defines the storage type of the ELF data that will be loaded. The
+ * storage type determines which memory optimizations can be tried by the LLEXT
+ * subsystem during the load process.
+ *
+ * @note Even with the most permissive option, LLEXT might still have to copy
+ * ELF data into a separate memory region to comply with other restrictions,
+ * such as hardware memory protection and/or alignment rules.
+ * Sections such as BSS that have no space in the file will also be allocated
+ * in the LLEXT heap.
+ */
+enum llext_storage_type {
+	/**
+	 * ELF data is only available during llext_load(); even if the loader
+	 * supports directly accessing the memory via llext_peek(), the buffer
+	 * contents will be discarded afterwards.
+	 * LLEXT will allocate copies of all required data into its heap.
+	 */
+	LLEXT_STORAGE_TEMPORARY,
+	/**
+	 * ELF data is stored in a *read-only* buffer that is guaranteed to be
+	 * always accessible for as long as the extension is loaded. LLEXT may
+	 * directly reuse constant data from the buffer, but may still allocate
+	 * copies if relocations need to be applied.
+	 */
+	LLEXT_STORAGE_PERSISTENT,
+	/**
+	 * ELF data is stored in a *writable* memory buffer that is guaranteed
+	 * to be always accessible for as long as the extension is loaded.
+	 * LLEXT may freely modify and reuse data in the buffer; so, after the
+	 * extension is unloaded, the contents should be re-initialized before
+	 * a subsequent llext_load() call.
+	 */
+	LLEXT_STORAGE_WRITABLE,
+};
+
 /**
  * @brief Linkable loadable extension loader context
  *
@@ -95,6 +133,11 @@ struct llext_loader {
 	 */
 	void (*finalize)(struct llext_loader *ldr);
 
+	/**
+	 * @brief Storage type of the underlying data accessed by this loader.
+	 */
+	enum llext_storage_type storage;
+
 	/** @cond ignore */
 	elf_ehdr_t hdr;
 	elf_shdr_t sects[LLEXT_MEM_COUNT];

subsys/llext/llext_link.c

@@ -299,9 +299,14 @@ static void llext_link_plt(struct llext_loader *ldr, struct llext *ext, elf_shdr
 		 * beginning of the .text section in the ELF file can be
 		 * applied to the memory location of mem[LLEXT_MEM_TEXT].
 		 *
-		 * This is valid only when CONFIG_LLEXT_STORAGE_WRITABLE=y
-		 * and peek() is usable on the source ELF file.
+		 * This is valid only for LLEXT_STORAGE_WRITABLE loaders
+		 * since the buffer will be directly modified.
 		 */
+		if (ldr->storage != LLEXT_STORAGE_WRITABLE) {
+			LOG_ERR("PLT: cannot link read-only ELF file");
+			continue;
+		}
+
 		uint8_t *rel_addr = (uint8_t *)ext->mem[LLEXT_MEM_TEXT] -
 			ldr->sects[LLEXT_MEM_TEXT].sh_offset;
 

subsys/llext/llext_mem.c

@@ -71,7 +71,7 @@ static int llext_copy_region(struct llext_loader *ldr, struct llext *ext,
 	}
 	ext->mem_size[mem_idx] = region_alloc;
 
-	if (IS_ENABLED(CONFIG_LLEXT_STORAGE_WRITABLE)) {
+	if (ldr->storage == LLEXT_STORAGE_WRITABLE) {
 		/*
 		 * Try to reuse data areas from the ELF buffer, if possible.
 		 * If any of the following tests fail, a normal allocation