From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752208AbdF1O6Y (ORCPT ); Wed, 28 Jun 2017 10:58:24 -0400 Received: from foss.arm.com ([217.140.101.70]:42666 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751758AbdF1O6H (ORCPT ); Wed, 28 Jun 2017 10:58:07 -0400 Date: Wed, 28 Jun 2017 15:57:08 +0100 From: Mark Rutland To: Florian Fainelli Cc: lorenzo.pieralisi@arm.com, linux-arm-kernel@lists.infradead.org, Rob Herring , Brian Norris , Gregory Fong , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , Hauke Mehrtens , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , Ralf Baechle , Markus Mayer , Arnd Bergmann , Eric Anholt , Justin Chen , Doug Berger , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list , "open list:BROADCOM BCM47XX MIPS ARCHITECTURE" , linux-pm@vger.kernerl.org, "Rafael J. Wysocki" , will.deacon@arm.com, catalin.marinas@arm.com Subject: Re: [PATCH 1/4] misc: sram: Allow ARM64 to select SRAM_EXEC Message-ID: <20170628145707.GB8252@leverpostej> References: <20170626223248.14199-1-f.fainelli@gmail.com> <20170626223248.14199-3-f.fainelli@gmail.com> <20170627173859.GA5189@leverpostej> <171ae8ff-2af2-65e3-9796-308b21976876@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <171ae8ff-2af2-65e3-9796-308b21976876@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2017 at 11:21:17AM -0700, Florian Fainelli wrote: > On 06/27/2017 10:38 AM, Mark Rutland wrote: > > On Mon, Jun 26, 2017 at 03:32:42PM -0700, Florian Fainelli wrote: > >> Now that ARM64 also has a fncpy() implementation, allow selection > >> SRAM_EXEC for ARM64 as well. > >> > >> Signed-off-by: Florian Fainelli > > > > Sorr,y but I must NAK this patch. > > > > As mentioned on prior threads regarding fncpy, I do not think it makes > > sense to enable this for arm64. The only use-cases that have been > > described so far for this are power-management stuff that should live in > > PSCI or other secure FW, and have no place in the kernel on arm64 > > This is a valid reason, but this is only one use case presented, the > only thing is that we need to make sure, as patch reviewers and you guys > as architecture maintainers, that this is not used as a means to bypass > PSCI for suspend/resume operation, which I now agree with. > > Still, the general use case remains: you have a piece of addressable > memory which can be used to allocate space from and relocate code to be > it for security, performance, predictability, isolation, or anything, > and that should be possible given standard kernel facilities offered by > the SRAM driver. While I agree that these are *theoretically* possible use cases, they aren't *real* cases today. If someone comes by with code that needs this (which doesn't fall into one of those NAK'd cases above), then I'm happy for this to be enabled for that feature. Until such time, I see no reason to enable this. Given it comes with strong the potential for abuse, I'd rather it remained disabled. > > > There are no other users of this functionality, and until there are, I > > see no reason to enable this, and risk a proliferation of unnecessary > > platform-specific code. > > > > It should be possible to #ifdef-ise the relevant callers of this such > > that they can be built on arm64 without using fncpy or sram_exec > > functionality. AFAICT, there are no users on arm64 introduced by this > > series. > > I sent this patch accidentally as part of this patch series anyway, so > if you want to keep the discussion alive, reply here: > > https://patchwork.kernel.org/patch/9793745/ That appears to be v2 of the series, and there's a v3 afterwards, so I've replied on v3. Thanks, Mark.