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: <f278bb69-7df0-4d14-5e4f-9bcb57d7f2b6@perex.cz>
Date:   Mon, 21 Jan 2019 15:15:43 +0100
From:   Jaroslav Kysela <perex@...ex.cz>
To:     Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.de>
Cc:     alsa-devel@...a-project.org, arnd@...db.de, keescook@...omium.org,
        bgoswami@...eaurora.org, sr@...x.de, gustavo@...eddedor.com,
        philburk@...gle.com, willy@...radead.org,
        mchehab+samsung@...nel.org, sboyd@...nel.org, vkoul@...nel.org,
        Baolin Wang <baolin.wang@...aro.org>,
        daniel.thompson@...aro.org, leo.yan@...aro.org,
        mathieu.poirier@...aro.org, srinivas.kandagatla@...aro.org,
        anna-maria@...utronix.de, corbet@....net, jmiller@...erware.com,
        ckeepax@...nsource.wolfsonmicro.com, joe@...ches.com,
        o-takashi@...amocchi.jp, colyli@...e.de,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] ALSA: core: Add DMA share buffer support

Dne 21.1.2019 v 13:40 Mark Brown napsal(a):
> On Fri, Jan 18, 2019 at 08:39:32PM +0100, Takashi Iwai wrote:
>> Mark Brown wrote:
> 
>>>> 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
> 
>>> 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
> 
>> 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?
> 
> 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.

Even with the full operation mode, it's difficult imagine what the
depending task can break with the sound interface except probably annoy
users with some cracks for the playback or start/stop the streaming rapidly.

					Jaroslav

-- 
Jaroslav Kysela <perex@...ex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.