[alsa-devel] [PATCH v3 09/14] ASoC: SOF: Add firmware, loader support

[Pierre-Louis Bossart]

>>>> +		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.
s/bounce/bounds ?
>
> - Alignment of block->size;
>    For some non-x86 platforms, the access to an unaligned address might
>    be illegal.

Maybe I am missing something but I don't see any sort of explicit 
restriction on alignment in the SOF tools. it looks implicit based on 
address offsets and bases.

Liam, do you see any negative side effects if we enforce a 32-bit 
alignment for all blocks (which essentially means all block sizes are 
multiple of 4)? we can try and experiment but it's better if we have an 
agreement on the design.

>
> 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.
snd_sof_dsp_block_write() is implemented with a platform-specific 
callback, I'd expect any endianess issues to be handled in that 
platform-specific code?