linux-kernel - Re: [RFC PATCH] ALSA: core: Add DMA share buffer support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190118190805.GF6260@sirena.org.uk>
Date:   Fri, 18 Jan 2019 19:08:05 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Jaroslav Kysela <perex@...ex.cz>
Cc:     Baolin Wang <baolin.wang@...aro.org>, tiwai@...e.com,
        leo.yan@...aro.org, sboyd@...nel.org, colyli@...e.de,
        corbet@....net, mathieu.poirier@...aro.org,
        ckeepax@...nsource.wolfsonmicro.com, mchehab+samsung@...nel.org,
        gustavo@...eddedor.com, joe@...ches.com, vkoul@...nel.org,
        o-takashi@...amocchi.jp, keescook@...omium.org,
        jmiller@...erware.com, anna-maria@...utronix.de,
        willy@...radead.org, sr@...x.de, bgoswami@...eaurora.org,
        philburk@...gle.com, srinivas.kandagatla@...aro.org, arnd@...db.de,
        daniel.thompson@...aro.org, linux-kernel@...r.kernel.org,
        alsa-devel@...a-project.org
Subject: Re: [RFC PATCH] ALSA: core: Add DMA share buffer support

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)