linux-kernel - Re: [PATCH] arm: dma-mapping: move consistent_init to early

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Dec 2010 20:36:53 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Saravana Kannan <skannan@...eaurora.org>
Cc:	Jeff Ohlstein <johlstei@...eaurora.org>,
	linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	dwalker@...eaurora.org, Catalin Marinas <catalin.marinas@....com>,
	Nicolas Pitre <nico@...vell.com>, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] arm: dma-mapping: move consistent_init to early_initcall

On Fri, Dec 03, 2010 at 12:06:53PM -0800, Saravana Kannan wrote:
> The MSM8660 SoC uses the TrustZone technology and the Linux kernel  
> executes in normal/non-secure domain. When the second core is brought  
> out of reset, it starts executing a secure image which then jumps to  
> "secondary_startup". So, before bringing the second core out of reset,  
> we need to inform the secure domain code where secondary_startup is  
> located in memory.
>
> We do the communication with the secure code by using buffers in memory.  
>  The cache treats the NS (non secure) bit as an additional address bit  
> when tagging memory. Hence, cache accesses are not coherent between the  
> secure and non-secure domains. So, the secure side flushes it's cache  
> after writing to the buffer. To properly read the response from the  
> secure side, the kernel has to pick a buffer that isn't cacheable in the  
> first place. We have similar issues in the reverse direction.

So when ARM gets DMA-coherent caches, you of course aren't going to
complain that the DMA APIs start avoiding doing the current tricks with
non-cacheable memory?

I view what you're doing above with the DMA API as an abuse of the API.
Just like the problems we're facing with ioremap() being used on system
RAM, you're asking for problems when the ARM architecture changes because
you're using an API for it's current properties, not for its purpose.

I've been on for years about purpose-designed APIs for cache issues,
and every time someone abuses them, they eventually end up suffering
breakage.

Let's wait until the full set of patches is available before discussing
further.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/