linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Will Deacon <will@kernel.org>,
	Amit Pundir <amit.pundir@linaro.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Thorsten Leemhuis <regressions@leemhuis.info>,
	Sibi Sankar <quic_sibis@quicinc.com>
Subject: [PATCH] Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"
Date: Tue,  6 Dec 2022 10:34:03 +0000	[thread overview]
Message-ID: <20221206103403.646-1-will@kernel.org> (raw)

This reverts commit c44094eee32f32f175aadc0efcac449d99b1bbf7.

Although the semantics of the DMA API require only a clean operation
here, it turns out that the Qualcomm 'qcom_q6v5_mss' remoteproc driver
(ab)uses the DMA API for transferring the modem firmware to the secure
world via calls to Trustzone [1].

Once the firmware buffer has changed hands, _any_ access from the
non-secure side (i.e. Linux) will be detected on the bus and result in a
full system reset [2]. Although this is possible even with this revert
in place (due to speculative reads via the cacheable linear alias of
memory), anecdotally the problem occurs considerably more frequently
when the lines have not been invalidated, assumedly due to some
micro-architectural interactions with the cache hierarchy.

Revert the offending change for now, along with a comment, so that the
Qualcomm developers have time to fix the driver [3] to use a firmware
buffer which does not have a cacheable alias in the linear map.

Link: https://lore.kernel.org/r/20221114110329.68413-1-manivannan.sadhasivam@linaro.org [1]
Link: https://lore.kernel.org/r/CAMi1Hd3H2k1J8hJ6e-Miy5+nVDNzv6qQ3nN-9929B0GbHJkXEg@mail.gmail.com/ [2]
Link: https://lore.kernel.org/r/20221206092152.GD15486@thinkpad [2]
Reported-by: Amit Pundir <amit.pundir@linaro.org>
Reported-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Sibi Sankar <quic_sibis@quicinc.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/mm/dma-mapping.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3cb101e8cb29..5240f6acad64 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -36,7 +36,22 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
 {
 	unsigned long start = (unsigned long)page_address(page);
 
-	dcache_clean_poc(start, start + size);
+	/*
+	 * The architecture only requires a clean to the PoC here in order to
+	 * meet the requirements of the DMA API. However, some vendors (i.e.
+	 * Qualcomm) abuse the DMA API for transferring buffers from the
+	 * non-secure to the secure world, resetting the system if a non-secure
+	 * access shows up after the buffer has been transferred:
+	 *
+	 * https://lore.kernel.org/r/20221114110329.68413-1-manivannan.sadhasivam@linaro.org
+	 *
+	 * Using clean+invalidate appears to make this issue less likely, but
+	 * the drivers themselves still need fixing as the CPU could issue a
+	 * speculative read from the buffer via the linear mapping irrespective
+	 * of the cache maintenance we use. Once the drivers are fixed, we can
+	 * relax this to a clean operation.
+	 */
+	dcache_clean_inval_poc(start, start + size);
 }
 
 #ifdef CONFIG_IOMMU_DMA
-- 
2.39.0.rc0.267.gcb52ba06e7-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2022-12-06 10:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-06 10:34 Will Deacon [this message]
2022-12-06 11:24 ` [PATCH] Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()" Manivannan Sadhasivam
2022-12-06 17:50 ` Catalin Marinas
  -- strict thread matches above, loose matches on Subject: below --
2022-11-14 11:03 Manivannan Sadhasivam
2022-11-14 11:29 ` Manivannan Sadhasivam
2022-11-14 14:11 ` Will Deacon
2022-11-14 15:14   ` Robin Murphy
2022-11-14 17:38     ` Catalin Marinas
2022-11-18 10:54       ` Manivannan Sadhasivam
2022-11-18 12:33         ` Will Deacon
2022-11-21  6:42           ` Manivannan Sadhasivam
2022-11-21 10:12             ` Sibi Sankar
2022-11-24 11:55               ` Catalin Marinas
2022-12-01  9:29                 ` Thorsten Leemhuis
2022-12-01 17:45                   ` Catalin Marinas
2022-12-02  8:26                     ` Amit Pundir
2022-12-02  8:54                       ` Thorsten Leemhuis
2022-12-02 10:03                         ` Will Deacon
2022-12-02 10:34                           ` Thorsten Leemhuis
2022-12-02 16:10                             ` Greg KH
2022-12-02 16:27                               ` Thorsten Leemhuis
2022-12-02 16:32                                 ` Greg KH
2022-12-02 17:14                                   ` Manivannan Sadhasivam
2022-12-05 14:24                                     ` Will Deacon
2022-12-06  9:21                                       ` Manivannan Sadhasivam
2022-12-06  9:58                                         ` Will Deacon
2022-12-02 10:54                           ` Manivannan Sadhasivam
2022-11-28  5:44 ` Thorsten Leemhuis
2022-11-28  8:15   ` Manivannan Sadhasivam
2022-12-08  4:59 ` Leonard Lausen

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=20221206103403.646-1-will@kernel.org \
    --to=will@kernel.org \
    --cc=amit.pundir@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=quic_sibis@quicinc.com \
    --cc=regressions@leemhuis.info \
    /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;
as well as URLs for NNTP newsgroup(s).