On Thu, 20 Dec 2018 03:11:55 +0100, Bard liao wrote: > > > > Date: Wed, 12 Dec 2018 12:23:33 +0100 > > From: Takashi Iwai <tiwai@xxxxxxx> > > To: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > > Cc: alsa-devel@xxxxxxxxxxxxxxxx, andriy.shevchenko@xxxxxxxxx, Daniel > > Baluta <daniel.baluta@xxxxxxxxx>, liam.r.girdwood@xxxxxxxxxxxxxxx, > > vkoul@xxxxxxxxxx, broonie@xxxxxxxxxx, Alan Cox <alan@xxxxxxxxxxxxxxx>, > > sound-open-firmware@xxxxxxxxxxxxxxxx > > Subject: Re: [PATCH v3 09/14] ASoC: SOF: Add firmware > > loader support > > Message-ID: <s5htvjjj8ei.wl-tiwai@xxxxxxx> > > 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
