From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 714AEC07EBF for ; Fri, 18 Jan 2019 19:39:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 30FE22087E for ; Fri, 18 Jan 2019 19:39:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729335AbfARTjj (ORCPT ); Fri, 18 Jan 2019 14:39:39 -0500 Received: from mx2.suse.de ([195.135.220.15]:54194 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728989AbfARTjj (ORCPT ); Fri, 18 Jan 2019 14:39:39 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 79F4CAF97; Fri, 18 Jan 2019 19:39:37 +0000 (UTC) Date: Fri, 18 Jan 2019 20:39:32 +0100 Message-ID: From: Takashi Iwai To: "Mark Brown" Cc: "Jaroslav Kysela" , , , , , , , , , , , , "Baolin Wang" , , , , , , , , , , , , Subject: Re: [RFC PATCH] ALSA: core: Add DMA share buffer support In-Reply-To: <20190118190805.GF6260@sirena.org.uk> References: <290f6d3a5fe288b87480cc5fa12c5139728daeca.1547787189.git.baolin.wang@linaro.org> <81e894ba-acad-2fd4-996d-8d35edd8825a@perex.cz> <20190118190805.GF6260@sirena.org.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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