[userspace LL] vregion related syscalls

[lyakh]

vregion system calls, needed when integrating userspace LL and DP
part of #10945

[Copilot]

Pull request overview

Adds Zephyr userspace support for SOF “vregion” allocations to enable userspace LL + DP integration (part of #10945), including syscall plumbing and module-adapter wiring to map vregion memory into the LL userspace memory domain.

Changes:

• Introduces Zephyr syscall handlers/marshalling for vregion alloc/free/get/put/set_interim.
• Refactors Zephyr vregion implementation entrypoints to z_impl_* to back the new syscalls.
• Extends module-adapter allocation flow to create/map/unmap vregions for DP modules and plumbs vregion start/size through mod_alloc_ctx.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
zephyr/syscall/vregion.c	New syscall verification + marshalling includes for vregion APIs.
zephyr/lib/vregion.c	Switches vregion APIs to z_impl_* entrypoints and adjusts symbol exports accordingly.
zephyr/Kconfig	Adds SOF_USERSPACE_INTERFACE_VREGION and selects it from SOF_USERSPACE_LL.
zephyr/include/rtos/alloc.h	Extends mod_alloc_ctx with vregion start/size metadata for domain mapping.
zephyr/CMakeLists.txt	Adds syscall header generation and builds the new vregion syscall source.
src/include/sof/lib/vregion.h	Marks vregion APIs as __syscall and includes generated syscall header.
src/include/sof/audio/module_adapter/module/generic.h	Exposes module-adapter vregion map/unmap as syscalls for full Zephyr app.
src/audio/module_adapter/module_adapter.c	Implements vregion creation + mem-domain partition mapping and adds syscall verifiers.
src/audio/buffers/comp_buffer.c	Routes vregion-backed buffer free through the new shared vregion-free helper.

Suppressed comments (2)

src/audio/module_adapter/module_adapter.c:134

• module_adapter_vreg_free() decrements the vregion refcount (and may free the vregion pages) before removing the user mem-domain partitions. If vregion_put() frees the pages, the user partition remains until module_adapter_vreg_unmap() runs, creating a window where freed (and potentially reallocated) pages stay user-accessible. Consider unmapping first and freeing the vregion atomically in kernel code when the refcount reaches 0.

void module_adapter_vreg_free(struct mod_alloc_ctx *alloc)
{
	if (vregion_put(alloc->vreg))
		return;

	module_adapter_vreg_unmap(alloc);

	sof_heap_free(alloc->heap, alloc);

src/audio/module_adapter/module_adapter.c:255

• The syscall verifier for module_adapter_vreg_unmap() only checks that the alloc struct is readable. In userspace-LL configurations alloc lives in user-writable memory, so a caller can forge vreg_start/vreg_size and attempt to remove arbitrary partitions from zephyr_ll_mem_domain(). Add validation that alloc refers to an expected allocation and that (vreg_start,vreg_size) match the vregion’s actual mem_info (or avoid taking alloc from user-space entirely).

void z_vrfy_module_adapter_vreg_unmap(const struct mod_alloc_ctx *alloc)
{
	K_OOPS(K_SYSCALL_MEMORY_READ(alloc, sizeof(*alloc)));
	z_impl_module_adapter_vreg_unmap(alloc);
}

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[kv2019i]

Please check inline, concern with the syscall verify function.

[kv2019i]

Hmm, this is not safe, user-space can pass arbitrary alloc->vreg and this is passed unchecked to kernel code.

[lyakh]

@kv2019i added an owner, please re-check

[kv2019i]

This is better, but as "alloc" is untrusted memory, "alloc->vreg" can point to a made-up vreg object (with owner set to point to alloc by the user-space thread). I think another layer is needed to look up "vreg" is an actual kernel vreg object, and not a pointer to some random user created object.

[kv2019i]

The new check in vregion_verify() could be enough, please see comments inline. At least I'd add a comment how this protects against invalid/fabricated "vr" objects.

[kv2019i]

This is better, but as "alloc" is untrusted memory, "alloc->vreg" can point to a made-up vreg object (with owner set to point to alloc by the user-space thread). I think another layer is needed to look up "vreg" is an actual kernel vreg object, and not a pointer to some random user created object.

[kv2019i]

I think here too we'd need to verify "vr" is a valid kernel vr object.

[kv2019i]

Commit description says you put common code into vregion_verify(), but it actually does more checks than before, so this is not just about putting it in common function.

[kv2019i]

Ok this could be potentially enough. I still wonder if this is secure enough. but this is definitely a fast check to make, versus looking up a list/array of all kernel vr objects.