Hi Phil & all, On Wed, Jan 30, 2019 at 04:45:04PM -0800, Phil Burk wrote: > Hello Mark, > > Our security team was very concerned about the old ALSA FD. It provided too > much access to the guts of ALSA. > > I assume they will not like anything other than a plain > "anon_inode:dmabuf". If it is a new FD, then the code would have to be > reviewed. Even if it looked OK there might be some holes that we don't > find. So it would probably be rejected. > > I cannot speak for our security team so I am working on setting up a > meeting or conversation between Mark and Zach, our security expert. > > Adding the anon_inode:snd-pcm might be great for ALSA. That could be used > by the HAL for STATUS and CONTROL. But it is likely that we will need an > additional anon_inode:dmabuf FD that is only associated with the PCM > buffer. It can then be safely passed to an Android app. Thanks for the inputs. I went through discussions, I'd like to divide the work into two mainly parts: - The first part is to use dmabuf to dynamically import buffer to sound device; so the buffer is not bound to sound device at the initialization phase; - The second part is to use dmabuf to export buffer with anon_inode; thus it can meet the security requirement. I go through Jaroslav implementation (thanks a lot for the quick moving for this part!), it tries to implement the second part, but it misses the first part support for dynamically binding audio buffer; and as Mark/Phil mentioned, Jaroslav patch tries to use the same one FD for both sound device and audio buffer. I think it's good to firstly use one test case to demonstrate to dynamically import buffer to sound device, then this buffer can be exported with anon_inode for user space. Is this doable? Thanks, Leo Yan > On Wed, Jan 30, 2019 at 2:32 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > > On Wed, Jan 30, 2019 at 01:41:37PM +0100, Jaroslav Kysela wrote: > > > This patchset contains the anonymous dup implementation with permissions > > > checking for the ALSA's PCM interface in kernel to enable the restricted > > > DMA sound buffer sharing for the restricted tasks. > > > > > > The code was tested through qemu and it seems to be pretty stable. > > > > > > The initial tinyalsa implementation can be found here: > > > > > > https://github.com/perexg/tinyalsa/commits/anondup > > > > > > The filtering might be refined. It depends on the real requirements. > > > Perhaps, we may create more ioctl groups. Any comments are more than > > > welcome. > > > > My understanding based on some off-list discussion is that the Android > > security people are going to see anything that involves passing more > > than a block of memory (and in particular anything that gives access to > > the sound APIs) as a problem. That's obviously going to be an issue for > > anything O_APPEND based. My understanding is that this is fundamentally > > a risk mitigation thing - by not having any of the sound kernel > > interfaces available to the applications affected there's no possibility > > that any problems in the sound code can cause security issues. > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
