tree af8aaa9515ce7858e9668e47bf2cf9e6b2971bd0
parent 8b73f7732287ae55d50b9a03d8a8a9a4e29e647c
author Andre Przywara <andre.przywara@arm.com> 1682599601 +0100
committer Andre Przywara <andre.przywara@arm.com> 1683129631 +0100

fix(psci): do not panic on illegal MPIDR

Commit 66327414fb1e ("fix(psci): potential array overflow with cpu on")
changed an assert in the PSCI library's psci_cpu_on_start() function to
a runtime error message, followed by a panic. This does not seem right
for two reasons:
- We must not panic() triggered by conditions influenced by lower EL
  callers. If non-secure world provides illegal arguments to a PSCI
  call, we can easily detect this and return -PSCI_E_INVALID_PARAMS, as
  the PSCI spec demands. In fact this is done already, which brings us
  to the next reason:
- psci_cpu_on_start() is effectively a function private to the PSCI
  library: its prototype is in psci_private.h. It's just not static
  because it lives in a different code file from the main PSCI code.
  We check for illegal MPID values already in psci_cpu_on(), and return
  an error value to the caller, as we should. This function is the ONLY
  caller of psci_cpu_on_start(), so there is no way we get an illegal
  target_cpu argument into this function. An assert() is thus the proper
  way to check for this.

Mostly revert the patch mentioned above, just extending the assert so
that it does also check for not exceeding the array boundaries.
To harden the code, add a check against PLATFORM_MAX_CORE_COUNT in
psci_validate_mpidr(), and return with the proper PSCI error code if
this number is exceeded.

This also fixes the sun50i_a64 build with DEBUG=1, which exceeded an
SRAM limit due to the error message.

Change-Id: I48fc58d96b0173da5b934750f4cadf7884ef5e42
Signed-off-by: Andre Przywara <andre.przywara@arm.com>