linux-kernel - RE: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox

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:   Mon, 27 May 2019 06:18:30 +0000
From:   Peng Fan <peng.fan@....com>
To:     Sudeep Holla <sudeep.holla@....com>,
        Florian Fainelli <f.fainelli@...il.com>
CC:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "jassisinghbrar@...il.com" <jassisinghbrar@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "andre.przywara@....com" <andre.przywara@....com>,
        "van.freenix@...il.com" <van.freenix@...il.com>,
        "festevam@...il.com" <festevam@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox

Hi Sudeep,

> Subject: Re: [PATCH 0/2] mailbox: arm: introduce smc triggered mailbox
> 
> On Thu, May 23, 2019 at 10:30:50AM -0700, Florian Fainelli wrote:
> > Hi,
> >
> > On 5/22/19 10:50 PM, Peng Fan wrote:
> > > This is a modified version from Andre Przywara's patch series
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Fpatchwork%2Fcover%2F812997%2F&amp;data=02%7C01%7Cpe
> ng.fan%40nxp.com%7Cfa2ba15f479b49eb219f08d6e0713ea3%7C686ea1d3b
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C636943174355592142&amp;sdat
> a=Y94rnxDEoMm9nyRyjJrYBqRduc5XkvvQhno7zfIQ%2B04%3D&amp;reserve
> d=0.
> > > [1] is a draft implementation of i.MX8MM SCMI ATF implementation
> > > that use smc as mailbox, power/clk is included, but only part of clk
> > > has been implemented to work with hardware, power domain only
> > > supports get name for now.
> > >
> > > The traditional Linux mailbox mechanism uses some kind of dedicated
> > > hardware IP to signal a condition to some other processing unit,
> > > typically a dedicated management processor.
> > > This mailbox feature is used for instance by the SCMI protocol to
> > > signal a request for some action to be taken by the management
> processor.
> > > However some SoCs does not have a dedicated management core to
> > > provide those services. In order to service TEE and to avoid linux
> > > shutdown power and clock that used by TEE, need let firmware to
> > > handle power and clock, the firmware here is ARM Trusted Firmware
> > > that could also run SCMI service.
> > >
> > > The existing SCMI implementation uses a rather flexible shared
> > > memory region to communicate commands and their parameters, it still
> > > requires a mailbox to actually trigger the action.
> >
> > We have had something similar done internally with a couple of minor
> > differences:
> >
> > - a SGI is used to send SCMI notifications/delayed replies to support
> > asynchronism (patches are in the works to actually add that to the
> > Linux SCMI framework). There is no good support for SGI in the kernel
> > right now so we hacked up something from the existing SMP code and
> > adding the ability to register our own IPI handlers (SHAME!). Using a
> > PPI should work and should allow for using request_irq() AFAICT.
> >
> 
> We have been thinking this since we were asked if SMC can be transport.
> Generally out of 16 SGIs, 8 are reserved for secure side and non-secure has 8.
> Of these 8, IIUC 7 is already being used by kernel. So unless we manage to get
> the last one reserved exclusive to SCMI, it makes it difficult to add SGI support
> in SCMI.
> 
> We have been telling partners/vendors about this limitation if they use SMC
> as transport and need to have dedicated h/w interrupt for the notifications.

This is an option, and we could add optional property.

> 
> Another issue could be with virtualisation(using HVC) and EL handling so called
> SCMI SGI. We need to think about those too. 

Using dedicated HW for virtualization that support vcpu scheduling might be
not a good choice, do you mean this? Dedicated pin vcpu to pcpu should be fine,
just like jailhouse hypervisor.

I will try to get more info on this
> and come back on this.

Looking forward.

Thanks,
Peng.

> 
> --
> Regards,
> Sudeep