linux-kernel - Re: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM

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]

Message-ID: <1287076707.8749.12.camel@e102109-lin.cambridge.arm.com>
Date:	Thu, 14 Oct 2010 18:18:27 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Nicolas Pitre <nico@...xnic.net>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Arnd Hannemann <arnd@...dnet.de>,
	Hemant Pedanekar <hemantp@...com>, Greg KH <greg@...ah.com>,
	linux-main <linux-kernel@...r.kernel.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Han Jonghun <jonghun79.han@...il.com>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM

On Thu, 2010-10-14 at 16:02 +0100, Felipe Contreras wrote:
> On Mon, Oct 11, 2010 at 3:30 PM, Catalin Marinas
> <catalin.marinas@....com> wrote:
> > Well, even if you allow Device memory via ioremap in Linux and the
> > hardware behaviour is not "unpredictable", it is not guaranteed to act
> > as a Device memory. You get speculative accesses via the Normal alias
> > and you may also get dirty cache lines evicted at random from the Normal
> > mapping (unless you invalidated the cache before). The dirty eviction is
> > valid even for pre-ARMv6 processors.
> 
> I'm not familiar with device memory, but anyway, IIUC you are saying
> the normal mapping (original) might not work as expected... That's ok,
> because the only alias that uses after the ioremap() is the second
> one.

No, I say that the Device memory that you are using may not work as
expected (i.e. Device memory). The other Normal mapping may be fine but
you don't care about it anyway.

> > It may be just theoretical but architecture licensees implement the
> > hardware according to the ARM ARM. If it says "unpredictable", they
> > don't need to care much about this scenario as it is not allowed in
> > software and the hardware can be further optimised (well, I think
> > "unpredictable" doesn't allow hardware deadlocking or security
> > implications, so the memory corruption cannot be that random, possibly
> > just restricted to that memory range). It is probably ok on current
> > hardware but I cannot guarantee, you would have to check on a
> > case-by-case basis (CPU implementation).
> 
> Exactly, so it's not the end of the world if this is still allowed one
> more release.

Would there be any incentive for driver maintainers to fix the drivers
after one more release? AFAICT, this is a violation of the ioremap API
already.

But I don't have a strong opinion, only that if we allow ioremap for one
more cycle it would at least be better to use the ioremap_wc() hack I
posted to avoid memory type aliasing (cacheability attributes aliasing
would still be present but that's not that bad).

-- 
Catalin

--
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/