On 3/19/25 16:29, Sascha Hauer wrote:
> On Tue, Mar 18, 2025 at 12:33:05PM +0100, Sascha Hauer wrote:
>> On Mon, Mar 17, 2025 at 04:18:32PM +0100, Ahmad Fatoum wrote:
>>> Hello Sascha,
>>>
>>> On 3/12/25 13:16, Sascha Hauer wrote:
>>>> +
>>>> +int mci_rpmb_route_frames(struct mci *mci, void *req, unsigned long
>>>> reqlen,
>>>> + void *rsp, unsigned long rsplen)
>>>> +{
>>>> + /*
>>>> + * Whoever crafted the data supplied to this function knows how to
>>>> + * format the PRMB frames and which response is expected. If
>>>> + * there's some unexpected mismatch it's more helpful to report an
>>>> + * error immediately than trying to guess what was the intention
>>>> + * and possibly just delay an eventual error which will be harder
>>>> + * to track down.
>>>> + */
>>>> + void *rpmb_data = NULL;
>>>> + int ret;
>>>> +
>>>> + mci_blk_part_switch(mci->rpmb_part);
>>>> +
>>>> + if (!IS_ALIGNED((uintptr_t)req, ARCH_DMA_MINALIGN)) {
>>>
>>> Even if alignment happens to be correct, there is no guarantee that
>>> there is no other data sharing a cache line.
>>
>> reqlen is expected to be a single block of 512 bytes, so indeed when req
>> is aligned then the end is cacheline aligned as well. We could check
>> reqlen as well, but I actually never ran into this case, so we can just
>> return an error for now as you suggested.
>
> I was wrong here. the request is placed directly behind a 6 byte struct,
> so it's guaranteed to be unaligned. We always have to copy it.
>
> The response might be unaligned as well, but must be aligned to pass it
> to the mmc layer. In my tests the response was always aligned, but
> better safe than sorry, so I'll add an alignment check here as well,
> this time including a check for the length.
>
> Sascha
>
