linux-kernel - Re: [PATCH v3 0/4] Generalize fncpy availability

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: <20170620091025.GA26846@red-moon>
Date:   Tue, 20 Jun 2017 10:10:25 +0100
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Florian Fainelli <florian.fainelli@...adcom.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        linux-arm-kernel@...ts.infradead.org,
        "open list:GENERIC INCLUDE/ASM HEADER FILES" 
        <linux-arch@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
        Dave Gerlach <d-gerlach@...com>,
        Tony Lindgren <tony@...mide.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Russell King <linux@...linux.org.uk>,
        open list <linux-kernel@...r.kernel.org>,
        bcm-kernel-feedback-list@...adcom.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        linux-omap@...r.kernel.org, Shawn Guo <shawnguo@...nel.org>,
        Keerthy J <j-keerthy@...com>, sudeep.holla@....com
Subject: Re: [PATCH v3 0/4] Generalize fncpy availability

[+Sudeep]

On Mon, Jun 19, 2017 at 10:32:38AM -0700, Florian Fainelli wrote:
> On 06/19/2017 05:24 AM, Mark Rutland wrote:
> > On Fri, Jun 16, 2017 at 05:07:40PM -0700, Florian Fainelli wrote:
> >> Hi all,
> > 
> > Hi Florian,
> > 
> >> This patch series makes ARM's fncpy() implementation more generic (dropping the
> >> Thumb-specifics) and available in an asm-generic header file.
> >>
> >> Tested on a Broadcom ARM64 STB platform with code that is written to SRAM.
> >>
> >> Changes in v3 (thanks Doug!):
> >> - correct include guard names in asm-generic/fncpy.h to __ASM_FNCPY_H
> >> - utilize Kbuild to provide the fncpy.h header on ARM64
> >>
> >> Changes in v2:
> >> - leave the ARM implementation where it is
> >> - make the generic truly generic (no)
> >>
> >> This is helpful in making SoC-specific power management code become true drivers
> >> that can be shared between different architectures.
> > > Could you elaborate on what this is needed for?
> 
> Several uses cases come to mind:
> 
> - it could be used as a trampoline code prior to entering S2 for systems
> that do not support PSCI 1.0

I think S2 here means PM_SUSPEND_MEM. It is very wrong to manage power
states through platform specific hooks on PSCI based systems, consider
upgrading to PSCI 1.0 please (or implement PSCI CPU_SUSPEND power
states that allow to achieve same power savings as PM_SUSPEND_MEM
by just entering suspend-to-idle).

> - any code that has a specific need to relocate a performance, security
> sensitive code into SRAM and use it as another pool of memory.
> 
> > 
> > My understanding was that on 32-bit, this was to handle idle / suspend
> > cases, whereas for arm64 that should be handled by PSCI.
> 
> For systems that support PSCI 1.0, I agree, but it may not be possible
> to update those systems easily, still use case 2 is completely valid.

Just to be clear, thinking of using platform specific suspend hooks
on PSCI systems is not a viable solution, I will let other people
comment on option 2.

> > what exactly do you intend to use this for?
> 
> At the moment we use it to enter S2 on ARM64 systems (ARCH_BRCMSTB)

"At the moment", where ?

> which are PSCI 0.2 only. And yes, we do have a plan to evaluate
> upgrading to PSCI 1.0, but in general, any SoC which as an addressable
> SRAM could use it for whatever purpose it sees fit.

Not to implement suspend hooks on PSCI 0.2 systems.

Thanks,
Lorenzo