From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH v3 09/14] ASoC: SOF: Add firmware, loader support Date: Thu, 20 Dec 2018 09:16:16 +0100 Message-ID: References: <1ce21393-048f-6c04-b899-8cbfbf93983e@linux.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1ce21393-048f-6c04-b899-8cbfbf93983e@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Bard liao Cc: daniel.baluta@gmail.com, andriy.shevchenko@intel.com, alsa-devel@alsa-project.org, Pierre-Louis Bossart , liam.r.girdwood@linux.intel.com, vkoul@kernel.org, broonie@kernel.org, sound-open-firmware@alsa-project.org, alan@linux.intel.com List-Id: alsa-devel@alsa-project.org On Thu, 20 Dec 2018 03:11:55 +0100, Bard liao wrote: > > > > Date: Wed, 12 Dec 2018 12:23:33 +0100 > > From: Takashi Iwai > > To: Pierre-Louis Bossart > > Cc: alsa-devel@alsa-project.org, andriy.shevchenko@intel.com, Daniel > > Baluta , liam.r.girdwood@linux.intel.com, > > vkoul@kernel.org, broonie@kernel.org, Alan Cox , > > sound-open-firmware@alsa-project.org > > Subject: Re: [alsa-devel] [PATCH v3 09/14] ASoC: SOF: Add firmware > > loader support > > Message-ID: > > Content-Type: text/plain; charset=US-ASCII > > > > On Tue, 11 Dec 2018 22:23:13 +0100, > > Pierre-Louis Bossart wrote: > > > >> + > >> + snd_sof_dsp_block_write(sdev, offset, > >> + (void *)block + sizeof(*block), > >> + block->size); > >> + > >> + /* next block */ > >> + block = (void *)block + sizeof(*block) + block->size; > > This may lead to an unaligned access. > > Did you mean we should double check the block->size to > prevent access to an invalid address? You need two types of checks for the given data: - The bounce check of block->size; We need to avoid out-of-bounce access. - Alignment of block->size; For some non-x86 platforms, the access to an unaligned address might be illegal. Oh, and recently another thing is sometimes needed for avoiding Spectre. This can be covered by array_index_nospec(). > > Also how is the endianess guaranteed? > > Did you mean we should guarantee the driver can work no > matter what kernel's endianess is? > ie. Use le32_to_cpu() to handle it? Depends on the implementation. IIRC, topology API refuses the data in a different endianess by checking the magic number at beginning. thanks, Takashi