On Mon, May 06, 2024 at 01:49:17PM +0200, Hans de Goede wrote:

Hi dma-buf maintainers, et.al.,

Various people have been working on making complex/MIPI cameras work OOTB with mainline Linux kernels and an opensource userspace stack.

The generic solution adds a software ISP (for Debayering and 3A) to libcamera. Libcamera's API guarantees that buffers handed to applications using it are dma-bufs so that these can be passed to e.g. a video encoder.

In order to meet this API guarantee the libcamera software ISP allocates dma-bufs from userspace through one of the /dev/dma_heap/* heaps. For the Fedora COPR repo for the PoC of this: https://hansdegoede.dreamwidth.org/28153.html

Is there any reason for allocating DMA buffers for libcamera through /dev/dma_heap/ rather than allocating them via corresponding media device and then giving them away to DRM / VPU / etc?

At least this should solve the permission usecase: if the app can open camera device, it can allocate a buffer.

I have added a simple udev rule to give physically present users access to the dma_heap-s:

KERNEL=="system", SUBSYSTEM=="dma_heap", TAG+="uaccess"

(and on Rasperry Pi devices any users in the video group get access)

This was just a quick fix for the PoC. Now that we are ready to move out of the PoC phase and start actually integrating this into distributions the question becomes if this is an acceptable solution; or if we need some other way to deal with this ?

Specifically the question is if this will have any negative security implications? I can certainly see this being used to do some sort of denial of service attack on the system (1). This is especially true for the cma heap which generally speaking is a limited resource.

But devices tagged for uaccess are only opened up to users who are physcially present behind the machine and those can just hit the powerbutton, so I don't believe that any *on purpose* DOS is part of the thread model. Any accidental DOS would be a userspace stack bug.

Do you foresee any other negative security implications from allowing physically present non root users to create (u)dma-bufs ?

Regards,

Hans

1. There are some limits in drivers/dma-buf/udmabuf.c and distributions

could narrow these.