linux-kernel - Re: [RFC PATCH 0/3] Add ioremap_exec and extend drivers/misc/sram.c

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: <20160512163033.GP5995@atomide.com>
Date:	Thu, 12 May 2016 09:30:34 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Dave Gerlach <d-gerlach@...com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, Russ Dill <russ.dill@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>, Shawn Guo <shawnguo@...nel.org>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Russell King <linux@....linux.org.uk>,
	Nishanth Menon <nm@...com>
Subject: Re: [RFC PATCH 0/3] Add ioremap_exec and extend drivers/misc/sram.c

* Dave Gerlach <d-gerlach@...com> [160509 14:44]:
> Hi,
> There are several instances when one would want to execute out of on-chip
> SRAM, such as PM code on ARM platforms, so once again revisiting this
> series to allow that. Seems that having a solution for allowing SRAM to be
> mapped as executable will help clean up PM code on several ARM platforms and
> also open the door for others like TI AM335x and AM437x. This was first sent
> here [1] but this is rebased and updated for v4.6-rc.
> 
> Many platforms have migrated to using the generic SRAM driver at
> drivers/misc/sram.c but it doesn't seem like there is a clean solution
> for the common problem of needing to map executable pages.
> 
> Currently I see several platforms (at-91, imx6, socfpga) taking the
> address allocated by the genpool given by the SRAM driver and then calling
> __arm_ioremap_exec on it again to get a new address that can be executed.
> This doesn't seem like the cleanest solution, but maybe it works for code
> that is under mach-xxx but what about code that migrates outside into the
> drivers layer? Do any other architectures have a requirement for this?
> 
> I've converted omap3 PM code to use the generic SRAM driver which I'll send
> in a series right after this one, and AM335x and AM437x can both make use of
> this series as well and even go as far as to move a chunk of the PM
> code into drivers (needs to be updated but sent long ago here [2]), but
> that will be blocked if we don't have a generic way to ioremap memory as
> exec, or at least a way to do it from drivers/.
> 
> If we don't want to go down this path, is there a better idea for how to
> call ioremap_exec from drivers/ that we can all agree on?

Looks to me that this should allow moving the current SRAM code
into drivers. So feel free to add:

Acked-by: Tony Lindgren <tony@...mide.com>