On Fri, 18 Jan 2019 20:08:05 +0100, Mark Brown wrote: > > On Fri, Jan 18, 2019 at 10:35:44AM +0100, Jaroslav Kysela wrote: > > > the tinyalsa implementation does not show much - it's equal to the > > standard mmap access for the PCM devices. Even considering the Mark's > > text, there must be an arbiter (sound server) which communicates with > > the producer or consumer to control the data flow. I really would like > > to see a real usage for this. > > Right, the driving force behind implementing this is Android which had > been using an out of tree version of this approach based on ION but > that's run into trouble due to other outside changes. > > > It seems to me that the only point to implement this is the > > permissions. We already have O_APPEND mode for the PCM file descriptor > > which can reuse the PCM device multiple times (mmap the buffer to > > multiple tasks). I would probably go in this way and add more extended > > permission control for the PCM device, so permissions can be restricted > > for the passed descriptor to the producer or the consumer task. In this > > way, the restricted task might reuse other control mechanism offered buy > > the PCM file descriptor without requesting the arbiter to do so (like > > read the actual position in the DMA buffer, get the audio delay or so - > > reduce context switches). > > One concern I have with doing some ALSA-specific custom permissions > thing is integration with frameworks like SELinux (they'd presumably > need to learn about the ALSA specific stuff to manage it). It also > seems like it's adding a lot more security sensitive interfaces and > code which which will require audit and review, one of the things I > really like about this approach is that it's incredibly simple from > the security point of view. Well, I wonder what makes it more difficult by the approach Jaroslav suggested. With O_APPEND, you can just call mmap() normally, and that's all. What's the merit of dma-buf approach wrt the security? BTW, the suggested patch seems to have a problem when the attached PCM performs hw_free. Then the mapped target will be gone while another process still mapping it. And the code looks pretty racy. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
