2025-11 OPTEE based memory sharing over virtio-msg with FFA

This is early proof of concept work

The instructions below give the essentials only

Base demo:

(This info is from LEDGE-725: OP-TEE vsock/virtio-msg-ffa proof of conceptClosed by Jens Wiklander)

The base demo has a virtio-vsock device in OPTEE and uses virtio-msg-ffa to connect to it.

The n_2005 test case connects a vsock to OP-TEE listening in the secure world. Whatever is written to the socket is echoed back.

OPTEE uses a busybox based development model. Follow this outline to build and run the demo

repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml -b poc/virtio-msg-v2
repo sync -j$(nproc)
cd build
make toolchains -j$(nproc)
make all -j$(nproc)
make run-only
Press 'c' at the qemu menu to continue
# login and at the prompt with username: root (on password)
xtest n_2005

VSOCK with DMABUF memory sharing:

Viresh Kumar enhanced Jen’s work with DMABUF memory sharing as he describes below.

The figure below illustrates how the demo works. The Linux kernel runs in the normal world, while OP-TEE runs in the secure world.

A userspace application opens /dev/dma_heap/ffa, which is an FF-A–specific implementation of dma-heap. It allocates a dma-buf from this heap using DMA_HEAP_IOCTL_ALLOC, writes the string “Hello World!” into it, and then sends the dma-buf’s file descriptor over Vsock:

sendmsg(cmsg_type = SCM_VSOCK_SHMEM, subop = VSOCK_SHMEM_SUBOP_OFFER).

This message is received in the kernel’s af_vsock layer. The af_vsock code parses the message and converts the file descriptor into dma-heap–specific metadata using the new dma-heap helpers (shmem()/unshmem()). For the FF-A specific dma-heap, these helpers share the memory associated with the dma-buf over FF-A to the remote endpoint and return FF-A metadata.

The af_vsock layer sends this metadata (not the fd) to the secure endpoint over the virtio-msg FF-A bus.

On the receiver side, OP-TEE in the secure world has already mapped the memory previously shared by the Linux kernel over FF-A. It receives the metadata corresponding to this shared memory, uses it to locate the correct memory offsets, and reads the stored string — printing “Hello World!”.

After a delay of a few seconds, the userspace application in the normal world sends another message:

sendmsg(cmsg_type = SCM_VSOCK_SHMEM, subop = VSOCK_SHMEM_SUBOP_REVOKE)

This requests unsharing of the memory. The message is delivered to the secure world so that OP-TEE can unmap the memory. Once the secure world unmaps it, the normal world completes the unshare operation.

Steps to reproduce:

Reproduce Jens demo first.

Migrate to Viresh’s vsock/shmem branch (at git@github.com:vireshk) for build, optee_os, and optee_test repositories.

Migrate to Viresh’s linux repo: git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git virtio/msg

Repeat the same test from Jens's setup: "xtest n_2005"

The secure side should print: Hello World!