From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
Amit Pundir <amit.pundir@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Thorsten Leemhuis <regressions@leemhuis.info>,
Sibi Sankar <quic_sibis@quicinc.com>
Subject: Re: [PATCH] Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"
Date: Tue, 6 Dec 2022 16:54:31 +0530 [thread overview]
Message-ID: <20221206112431.GA108905@thinkpad> (raw)
In-Reply-To: <20221206103403.646-1-will@kernel.org>
On Tue, Dec 06, 2022 at 10:34:03AM +0000, Will Deacon wrote:
> 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>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Thanks,
Mani
> ---
> 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
next prev parent reply other threads:[~2022-12-06 11:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 10:34 [PATCH] Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()" Will Deacon
2022-12-06 11:24 ` Manivannan Sadhasivam [this message]
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=20221206112431.GA108905@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=amit.pundir@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=quic_sibis@quicinc.com \
--cc=regressions@leemhuis.info \
--cc=will@kernel.org \
/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).