mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Corentin Labbe <clabbe.montjoie@gmail.com>,
	Christoph Hellwig <hch@lst.de>,
	m.szyprowski@samsung.com,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org
Subject: Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0
Date: Mon, 7 Mar 2022 12:35:51 +0000	[thread overview]
Message-ID: <6cf91f43-df23-3ac9-e9b5-958d99d37422@arm.com> (raw)
In-Reply-To: <CAOtvUMePFR4e2jgHZKOvs3J3Xt4NzRbzD_=vr_49Qgs5HTrvHw@mail.gmail.com>

On 2022-03-07 12:17, Gilad Ben-Yossef wrote:
> On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
> 
>> The "overlap" is in the sense of having more than one mapping within the
>> same cacheline:
>>
>> [  142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f
>> D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0
>> [  142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc
>> D=445dc010 L=10 DMA_TO_DEVICE attrs=0
>> [  142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0
>> [  142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0
>> [  142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f
>> D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0
>>
>> This actually illustrates exactly the reason why this is unsupportable.
>> ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping
>> ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range
>> ba79f200-ba79f23f to be written back over the top of data that the
>> device has already started to write to memory. Hello data corruption.
>>
>> Separate DMA mappings should be from separate memory allocations,
>> respecting ARCH_DMA_MINALIGN.
> 
> hmm... I know I'm missing something here, but how does this align with
> the following from active_cacheline_insert() in kernel/dma/debug.c ?
> 
>          /* If the device is not writing memory then we don't have any
>           * concerns about the cpu consuming stale data.  This mitigates
>           * legitimate usages of overlapping mappings.
>           */
>          if (entry->direction == DMA_TO_DEVICE)
>                  return 0;

It's OK to have multiple mappings that are *all* DMA_TO_DEVICE, which 
looks to be the case that this check was intended to allow. However I 
think you're right that it should still actually check for conflicting 
directions between the new entry and any existing ones, otherwise it 
ends up a bit too lenient.

Cheers,
Robin.

  reply	other threads:[~2022-03-07 12:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09  9:57 Corentin Labbe
2022-02-09 17:45 ` Gilad Ben-Yossef
2022-02-17 19:38   ` Gilad Ben-Yossef
2022-02-20 19:26     ` Corentin Labbe
2022-02-21 10:08       ` Gilad Ben-Yossef
2022-02-21 14:05         ` Corentin Labbe
2022-02-22  7:39           ` Gilad Ben-Yossef
2022-02-28  9:11             ` Gilad Ben-Yossef
2022-03-04 13:30               ` Corentin Labbe
2022-03-06 21:49                 ` Herbert Xu
2022-03-07  7:59                   ` Gilad Ben-Yossef
2022-03-07 10:48                     ` Corentin Labbe
2022-03-07 11:14                       ` Robin Murphy
2022-03-07 11:49                         ` Corentin Labbe
2022-03-07 11:59                           ` Gilad Ben-Yossef
2022-03-07 13:47                             ` Corentin Labbe
2022-03-07 12:17                         ` Gilad Ben-Yossef
2022-03-07 12:35                           ` Robin Murphy [this message]
2022-03-07 12:47                             ` Gilad Ben-Yossef
2022-03-07 13:03                               ` Robin Murphy
2022-03-07 13:12                                 ` Robin Murphy
2022-03-07 13:21                                   ` Gilad Ben-Yossef
2022-03-07 13:13                                 ` Gilad Ben-Yossef
2022-03-07 13:45                         ` Corentin Labbe
2022-03-07 13:53                           ` Gilad Ben-Yossef
2022-03-07 13:56                             ` Corentin Labbe
2022-03-07 14:00                               ` Gilad Ben-Yossef
2022-03-07 14:05                                 ` Corentin Labbe
2022-03-08  9:40                               ` Corentin Labbe
2022-03-09  6:49                                 ` Gilad Ben-Yossef
2022-03-07 12:24                       ` Gilad Ben-Yossef
2022-03-07 13:43                       ` Gilad Ben-Yossef

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=6cf91f43-df23-3ac9-e9b5-958d99d37422@arm.com \
    --to=robin.murphy@arm.com \
    --cc=clabbe.montjoie@gmail.com \
    --cc=gilad@benyossef.com \
    --cc=hch@lst.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®