From: Mark Brown <broonie@kernel.org> To: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.de>, alsa-devel@alsa-project.org, arnd@arndb.de, keescook@chromium.org, bgoswami@codeaurora.org, sr@denx.de, gustavo@embeddedor.com, philburk@google.com, willy@infradead.org, mchehab+samsung@kernel.org, sboyd@kernel.org, vkoul@kernel.org, Baolin Wang <baolin.wang@linaro.org>, daniel.thompson@linaro.org, leo.yan@linaro.org, mathieu.poirier@linaro.org, srinivas.kandagatla@linaro.org, anna-maria@linutronix.de, corbet@lwn.net, jmiller@neverware.com, ckeepax@opensource.wolfsonmicro.com, joe@perches.com, o-takashi@sakamocchi.jp, colyli@suse.de, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] ALSA: core: Add DMA share buffer support Date: Tue, 22 Jan 2019 20:25:35 +0000 [thread overview] Message-ID: <20190122202535.GK7579@sirena.org.uk> (raw) In-Reply-To: <f278bb69-7df0-4d14-5e4f-9bcb57d7f2b6@perex.cz> [-- Attachment #1: Type: text/plain, Size: 1712 bytes --] On Mon, Jan 21, 2019 at 03:15:43PM +0100, Jaroslav Kysela wrote: > Dne 21.1.2019 v 13:40 Mark Brown napsal(a): > > 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. Right, that's what I understood you to mean. If you want to have a policy saying "it's OK to export a PCM file descriptor if it's only got permissions X and Y" the security module is going to need to know about the mechanism for setting those permissions. With dma_buf that's all a bit easier as there's less new stuff, though I've no real idea how much of a big deal that actually is. > 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. In some embedded systems the ability to play back notifications clearly can be very important to system functionality. Obviously at times the main purpose of the system is to play or record audio. I don't have a *super* strong opinion here but I'm not really a security person. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org> To: Jaroslav Kysela <perex@perex.cz> Cc: alsa-devel@alsa-project.org, bgoswami@codeaurora.org, gustavo@embeddedor.com, Takashi Iwai <tiwai@suse.de>, srinivas.kandagatla@linaro.org, mchehab+samsung@kernel.org, sr@denx.de, daniel.thompson@linaro.org, corbet@lwn.net, philburk@google.com, willy@infradead.org, jmiller@neverware.com, keescook@chromium.org, arnd@arndb.de, colyli@suse.de, ckeepax@opensource.wolfsonmicro.com, anna-maria@linutronix.de, mathieu.poirier@linaro.org, Baolin Wang <baolin.wang@linaro.org>, sboyd@kernel.org, linux-kernel@vger.kernel.org, vkoul@kernel.org, leo.yan@linaro.org, joe@perches.com Subject: Re: [RFC PATCH] ALSA: core: Add DMA share buffer support Date: Tue, 22 Jan 2019 20:25:35 +0000 [thread overview] Message-ID: <20190122202535.GK7579@sirena.org.uk> (raw) In-Reply-To: <f278bb69-7df0-4d14-5e4f-9bcb57d7f2b6@perex.cz> [-- Attachment #1.1: Type: text/plain, Size: 1712 bytes --] On Mon, Jan 21, 2019 at 03:15:43PM +0100, Jaroslav Kysela wrote: > Dne 21.1.2019 v 13:40 Mark Brown napsal(a): > > 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. Right, that's what I understood you to mean. If you want to have a policy saying "it's OK to export a PCM file descriptor if it's only got permissions X and Y" the security module is going to need to know about the mechanism for setting those permissions. With dma_buf that's all a bit easier as there's less new stuff, though I've no real idea how much of a big deal that actually is. > 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. In some embedded systems the ability to play back notifications clearly can be very important to system functionality. Obviously at times the main purpose of the system is to play or record audio. I don't have a *super* strong opinion here but I'm not really a security person. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2019-01-22 20:26 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-18 4:55 [RFC PATCH] ALSA: core: Add DMA share buffer support Baolin Wang 2019-01-18 9:35 ` Jaroslav Kysela 2019-01-18 9:35 ` Jaroslav Kysela 2019-01-18 19:08 ` Mark Brown 2019-01-18 19:08 ` Mark Brown 2019-01-18 19:39 ` Takashi Iwai 2019-01-18 19:39 ` Takashi Iwai 2019-01-21 12:40 ` Mark Brown 2019-01-21 12:40 ` Mark Brown 2019-01-21 14:15 ` Jaroslav Kysela 2019-01-21 14:15 ` Jaroslav Kysela 2019-01-22 20:25 ` Mark Brown [this message] 2019-01-22 20:25 ` Mark Brown 2019-01-23 11:58 ` Takashi Iwai 2019-01-23 12:46 ` Leo Yan 2019-01-24 13:43 ` Jaroslav Kysela 2019-01-24 13:43 ` Jaroslav Kysela 2019-01-24 17:33 ` Mark Brown 2019-01-24 17:33 ` Mark Brown 2019-01-25 9:25 ` Baolin Wang 2019-01-25 9:25 ` Baolin Wang 2019-01-25 10:10 ` Takashi Iwai 2019-01-25 10:10 ` Takashi Iwai 2019-01-25 10:20 ` Takashi Iwai 2019-01-25 10:20 ` Takashi Iwai 2019-01-25 11:24 ` Baolin Wang 2019-01-25 11:24 ` Baolin Wang 2019-01-25 13:04 ` Takashi Iwai 2019-01-25 13:04 ` Takashi Iwai 2019-01-28 5:48 ` Baolin Wang 2019-01-28 5:48 ` Baolin Wang 2019-01-25 11:11 ` Baolin Wang 2019-01-25 11:11 ` Baolin Wang 2019-01-25 13:03 ` Takashi Iwai 2019-01-25 13:03 ` Takashi Iwai 2019-01-28 5:47 ` Baolin Wang 2019-01-28 5:47 ` Baolin Wang 2019-01-25 13:19 ` [alsa-devel] " Takashi Iwai 2019-01-25 18:25 ` Mark Brown 2019-01-25 18:25 ` Mark Brown 2019-01-28 13:31 ` [alsa-devel] " Jaroslav Kysela 2019-01-28 14:14 ` Takashi Iwai
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190122202535.GK7579@sirena.org.uk \ --to=broonie@kernel.org \ --cc=alsa-devel@alsa-project.org \ --cc=anna-maria@linutronix.de \ --cc=arnd@arndb.de \ --cc=baolin.wang@linaro.org \ --cc=bgoswami@codeaurora.org \ --cc=ckeepax@opensource.wolfsonmicro.com \ --cc=colyli@suse.de \ --cc=corbet@lwn.net \ --cc=daniel.thompson@linaro.org \ --cc=gustavo@embeddedor.com \ --cc=jmiller@neverware.com \ --cc=joe@perches.com \ --cc=keescook@chromium.org \ --cc=leo.yan@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mathieu.poirier@linaro.org \ --cc=mchehab+samsung@kernel.org \ --cc=o-takashi@sakamocchi.jp \ --cc=perex@perex.cz \ --cc=philburk@google.com \ --cc=sboyd@kernel.org \ --cc=sr@denx.de \ --cc=srinivas.kandagatla@linaro.org \ --cc=tiwai@suse.de \ --cc=vkoul@kernel.org \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.