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]

Date:	Sat, 9 Oct 2010 13:11:26 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Felipe Contreras <felipe.contreras@...il.com>,
	"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>
Subject: Re: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM

On Saturday 09 October 2010 12:28:19 Felipe Contreras wrote:
> Also, what do you think is the right attitude? Do you think all
> driver writers should follow each and every patch on the mailing list
> or always try release candidates? Even if they all did (some do),
> there's no generic solution, so they all are scratching their heads
> about how to solve this. It might be crystal clear for you how such
> generic solution could be implemented, or perhaps how some of these
> drivers can be fixed individually, if so, why don't you come with a
> proposal to mitigate the pain of fixing such drivers.

Please put this into perspective, it's not like this was ever a
normal thing to do, and drivers doing an ioremap on kernel memory
would typically not make it through a review. I've looked through
the ARM specific drivers that do ioremap and practically all of
them just map their MMIO registers as they should.

The few drivers that may be hit by this are typically in drivers/staging
exactly because issues like this have not been fixed yet.

We should probably just fix the non-staging drivers that are hit by
this now and declare the issue done.

When you say that "many drivers broken", can you list the ones you know
about? It would probably help resolve this the right way.

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