On 2/6/26 11:43 AM, Shah, Tanmay via Openamp-system-reference wrote:
Hi all,
I am working on remoteproc auto-boot feature. While working on this, I realized it should be possible to achieve RPMsg communication without root access given to the user. Existing demos doesn't support it, but I want to open discussion on how that can be achieved.
One way discussed was, to use IOCTLS to create RPMSg devices, and I had open issue here: https://github.com/OpenAMP/openamp-system-reference/issues/50
I tried to modify echo_test[1] demo and use IOCTLS instead of accessing devices from sysfs directly, but that still need root access.
My goal is to design following workflow for the RPMsg communication with the remote processor:
- Linux device-tree has auto-boot property enabled.
- During boot, driver parses auto-boot related properties, loads fw and
boots rproc automatically (without user's involvement) 3. After boot, rproc firmware does name service announcement of RPMsg channels. 4. Linux creates RPMsg devices and ept based on above announcement. 5. Userspace apps uses RPMsg ioctls to create ept and rpmsg devices. 6. Userspace apps uses created devices for RPMsg communication with the remote processor.
As per my testing, as of now step-5 and step-6 needs root access. Ideally userspace apps should be able to create/read/write/close rpmsg devices without root access (for security purposes).
Is there any other way this problem is solved? I appreciate your input.
This is a 'capabilities' issue. If a user needs to be able to do something (like run an app that communicates to another app), but it's too dangerous to give them full system root access, you'd define appropriate capabilities and then grant the user JUST the capabilities they need.
i.e. you should be able to grand the ability to read/write/close to a user. The create could require something else. So your app startup becomes:
User/app gets root (this setuid root on the app) App runs, which creates the remote connection and makes it available User/app drops root, and moved to user permissions with an appropriate capability to use those interfaces in a 'safe' way.
As long as the app startup through dropping the perms is well audited, it is of minimal security concerns. Then the remaining app activities are 'safe' in that they are constrained.
I have no idea offhand what capabilities that IOCTL should use, but there should be a lot of information about this. This is what I would exlore.
--Mark
Thank You, Tanmay
References:
[1] https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/linux...