linux-kernel - Re: SMP enablement on Cortex-R52 (using PSCI ?)

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:   Wed, 19 Apr 2023 18:50:26 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Sudeep Holla <sudeep.holla@....com>,
        Ayan Kumar Halder <ayankuma@....com>
Cc:     mark.rutland@....com, lpieralisi@...nel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Vladimir Murzin <vladimir.murzin@....com>,
        Stefano Stabellini <sstabellini@...nel.org>
Subject: Re: SMP enablement on Cortex-R52 (using PSCI ?)

On 19/04/2023 9:47 am, Sudeep Holla wrote:
> Hi Ayan,
> 
> On Fri, Apr 14, 2023 at 12:24:38PM +0100, Ayan Kumar Halder wrote:
>> Hi PSCI developers,
>>
>> We have a SoC where there are 4 Cortex-R52 which is distributed in two
>> clusters. So we have 2 Cortex-R52 in one cluster and 2 Cortex-R52 in another
>> cluster.
>>
>> We wish to enable SMP on the 2 R52 within a cluster with Xen hypervisor (EL2
>> software) running on them.
>>
>> We are trying to explore if we can use PSCI for booting the secondary cores.
>>
>> Refer Cortex-R52 TRM
>> (https://developer.arm.com/documentation/100026/0101/?lang=en ), it
>> specifies the following :-
>>
>> Page 24 - Section 1.4.1
>>
>> "Support for Exception levels, EL0, EL1, and EL2."
>>
>> Page 30 - Section 2.1.6
>>
>> "The Cortex-R52 processor does not implement TrustZone® technology. It does
>> not support the ability to distinguish between secure and non-secure
>> physical memories."
>>
>> Thus, there is no EL3 and secure world in Cortex-R52. It implements
>> AArch32-V8R architecture.
>>
> 
> KVM hypervisor use PSCI to bring up secondaries in the VMs. So I am sure we
> must be able to use the interface on Cortex-R52 without EL3.
> 
>>
>> Refer PSCI design document,
>> https://developer.arm.com/documentation/den0022/e/?lang=en
>>
>> Page 18 -
>> "The PSCI specification focuses on the interface between Security states for
>> power management. It provides a method for issuing power management
>> requests. To deal with the requests, the PPF must include a PSCI
>> implementation. A PSCI implementation might require communication between
>> the PPF and a Trusted OS or SP."
>>
>> Page 17 - Privileged Platform Firmware (PPF)
>>
>> "For Armv7 systems, or Armv8 systems using AArch32 at EL3, PPF executes in
>> EL3."
>>
>>  From the above two statements, I infer that PSCI requires a PPF (running at
>> EL3) and a Trusted OS (running at secure EL2). If this is correct, then R52
>> cannot support PSCI. Please correct me if I am mistaken.
>>
>> I wish to know how do we wake up the secondary core if PSCI is not
>> supported.
>>
> 
> I will check with the authors if EL3 is a must for PSCI implementation, but
> IMO it must not be though every aspects described in the spec may not apply
> when used across EL2/EL1 boundaries especially when EL3 is not implemented
> in the hardware.

Xen could provide PSCI to EL1 guests using the HVC conduit. However if 
EL2 is the highest implemented EL, then Xen is the most privileged 
software in the system - it would have to own the EL2 exception vectors, 
and it would have to own the low-level CPU bringup code. At that point 
it just wouldn't make much sense to HVC *itself* via the PSCI protocol 
when it could simply call the function directly.

Robin.