Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"
Will Deacon
maintainerPATCH 1/1 Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"
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.
--- arch/arm64/mm/dma-mapping.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
arch/arm64/mm/dma-mapping.c +16 -1
@@ -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/[email protected] +* +* 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
Signature · 7 lines
2.39.0.rc0.267.gcb52ba06e7-goog _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 19 lines · Will Deacon
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.
Quoted 9 lines
Link https://lore.kernel.org/r/CAMi1Hd3H2k1J8hJ6e-Miy5+nVDNzv6qQ3nN-9929B0GbHJkXEg@mail.gmail.com/ [2] open hereReported-by Amit Pundir <[email protected]>Reported-by Manivannan Sadhasivam <[email protected]>Cc Catalin Marinas <[email protected]>Cc Thorsten Leemhuis <[email protected]>Cc Sibi Sankar <[email protected]>Signed-off-by Will Deacon <[email protected]>
Thanks,
Mani
Quoted 35 lines
--- arch/arm64/mm/dma-mapping.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)arch/arm64/mm/dma-mapping.c +16
-1@@ -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/[email protected] +* +* 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 Signature · 1 line
2.39.0.rc0.267.gcb52ba06e7-goog
Signature · 6 lines
மணிவண்ணன் சதாசிவம் _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 8 lines · Will Deacon
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].[...]
Applied to arm64 (for-next/fixes), thanks!
[1/1] Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"
https://git.kernel.org/arm64/c/b7d9aae40484
Signature · 7 lines
Catalin _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel