[alsa-devel] [RFC PATCH] ALSA: core: Add DMA share buffer support

[Leo Yan]

Hi all,

On Wed, Jan 23, 2019 at 12:58:51PM +0100, Takashi Iwai wrote:
> On Tue, 22 Jan 2019 21:25:35 +0100,
> Mark Brown wrote:
> > 
> > On Mon, Jan 21, 2019 at 03:15:43PM +0100, Jaroslav Kysela wrote:
> > > Dne 21.1.2019 v 13:40 Mark Brown napsal(a):
> > 
> > > > It was the bit about adding more extended permission control that I was
> > > > worried about there, not the initial O_APPEND bit.  Indeed the O_APPEND
> > > > bit sounds like it might also work from the base buffer sharing point of
> > > > view, I have to confess I'd not heard of that feature before (it didn't
> > > > come up in the discussion when Eric raised this in Prague).
> > 
> > > With permissions, I meant to make possible to restrict the file
> > > descriptor operations (ioctls) for the depending task (like access to
> > > the DMA buffer, synchronize it for the non-coherent platforms and maybe
> > > read/write the actual position, delay etc.). It should be relatively
> > > easy to implement using the snd_pcm_file structure.
> > 
> > Right, that's what I understood you to mean.  If you want to have a
> > policy saying "it's OK to export a PCM file descriptor if it's only got
> > permissions X and Y" the security module is going to need to know about
> > the mechanism for setting those permissions.  With dma_buf that's all a
> > bit easier as there's less new stuff, though I've no real idea how much
> > of a big deal that actually is.
> 
> There are many ways to implement such a thing, yeah.  If we'd need an
> implementation that is done solely in the sound driver layer, I can
> imagine to introduce either a new ioctl or an open flag (like O_EXCL)
> to specify the restricted sharing.  That is, a kind of master / slave
> model where only the master is allowed to manipulate the stream while
> the slave can mmap, read/write and get status.

I am lacking security related knowledge, especially for SELinux.
So only can give background information but not sure if it's really
helpful for discussion.

Android web page [1] give some information for this:

"The shared memory is referenced using a file descriptor that is
generated by the ALSA driver. If the file descriptor is directly
associated with a /dev/snd/ driver file, then it can be used by the
AAudio service in SHARED mode. But the descriptor cannot be passed to
the client code for EXCLUSIVE mode. The /dev/snd/ file descriptor
would provide too broad of access to the client, so it is blocked by
SELinux.

In order to support EXCLUSIVE mode, it is necessary to convert the
/dev/snd/ descriptor to an anon_inode:dmabuffer file descriptor.
SELinux allows that file descriptor to be passed to the client. It can
also be used by the AAudioService.

An anon_inode:dmabuffer file descriptor can be generated using the
Android Ion memory library."

So we work out dmabuf driver for audio buffer, the audio buffer will
be exported and attached by using dma-buf framework; then we can
return one file descriptor which is generated by dma-buf and this
file descriptor is bound with anon inode based on dma-buf core code.

If we directly use the device node /dev/snd/ as file descriptor, even
though we specify flag O_EXCL when open it, but it still is not an
anon inode file descriptor.  Thus this is not safe enough and will be
blocked by SELinux.  On the other hand, this patch wants to use
dma-buf framework to provide file descriptor for the audio buffer, and
this audio buffer can be one of mutiple audio buffers in the system
and it can be shared to any audio client program.

Again, I have no less knowledge for SELinux so sorry if I introduce any
noise at here.  And very appreciate any comments for this.

Thanks,
Leo Yan

[1] https://source.android.com/devices/audio/aaudio