Re: [PATCH v1 3/5] xen/arm: platforms: Add NXP S32CC platform code

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 10 Sep 2024, Julien Grall wrote:
> Hi,
> 
> On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
> > From: Andrei Cherechesu <andrei.cherechesu@xxxxxxx>
> > 
> > Added support for NXP S32CC platforms (S32G2, S32G3, S32R45),
> > which need SCMI over SMC calls forwarded to the firmware
> > running at EL3 (TF-A). Linux relies on the SCMI Platform
> > for system services such as clocking, reset, etc.
> 
> Is it SMCI as in the Arm spec? If so, this should not be platform specific.
> 
> Furthermore, I was under the impression that we can't blindly forward
> everything from a domain to the firmware. While it might be okayish for dom0,
> you also seem to give access to all the domains on the system is it intended?
> 
> Anyway, there is a series on the ML to add a mediator for SCMI in Xen (see
> [1]). I think it would be preferable to focus on getting it merged as it would
> benefit everyone and increase the security posture (we could restrict access).


Hi Andrei, Julien,

SCMI is very flexible and can be configured in a number of ways. In
general, Julien has a point that typically forwarding to firmware all
SCMI requests from Xen domains is not the desired behavior.

An an example, imagine the case where device1 is assigned to domain1 and
device2 is assigned to domain2. Now imagine that they both share a
clock. Domain1 and domain2 could fight over the clock frequency settings
using SCMI to change it, without being aware of each other activities.
It is likely that the system would malfunction.

If this kind of situations can happen on NXP S32CC platforms, then this
patch might not be a good idea. As Julien suggested, you might want to
have a look at Oleksii's approach. We could probably allow Dom0 to make
all SCMI calls. If you think that is OK, you need to add a
(is_hardware_domain(d)) check.

On the other hand, if your SCMI server implementation has a way to
prevent possible harmful activities from happening, or maybe all clocks
are fixed-clocks so there are actually no SCMI operations to control the
clocks, then it could be possible that this patch might be fine. I admit
it is unlikely because there is a number of ways SCMI could be used by
one domain to hurt another domain.

Can you please give us a brief overview on how SCMI is expected to work
on NXP S32CC?