NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__.
All common C compilers pre-define the same macros to signal which
architecture the code is being compiled for: __arm__ for AArch32 (or
earlier versions) and __aarch64__ for AArch64. There's no need for TF-A
to define its own custom macros for this. In order to unify code with
the export headers (which use __aarch64__ to avoid another dependency),
let's deprecate the AARCH32 and AARCH64 macros and switch the code base
over to the pre-defined standard macro. (Since it is somewhat
unintuitive that __arm__ only means AArch32, let's standardize on only
using __aarch64__.)
Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200
Signed-off-by: Julius Werner <jwerner@chromium.org>
Instead of having a custom implementation of setjmp() and longjmp() it
is better to follow the C standard.
The comments in setjmp.h are no longer needed as there are no deviations
from the expected one, so they have been removed.
All SDEI code that relied on them has been fixed to use the new function
prototypes and structs.
Change-Id: I6cd2e21cb5a5bcf81ba12283f2e4c067bd5172ca
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Corrects typos in core code, documentation files, drivers, Arm
platforms and services.
None of the corrections affect code; changes are limited to comments
and other documentation.
Change-Id: I5c1027b06ef149864f315ccc0ea473e2a16bfd1d
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
Enforce full include path for includes. Deprecate old paths.
The following folders inside include/lib have been left unchanged:
- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}
The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).
For example, this patch had to be created because two headers were
called the same way: e0ea0928d5 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a2 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.
Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.
Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
This patch includes context.h from sdei_private.h to fix the
following compilation errors:
<snip>
In file included from services/std_svc/sdei/sdei_event.c:9:0:
services/std_svc/sdei/sdei_private.h: In function 'sdei_client_el':
services/std_svc/sdei/sdei_private.h:164:2: error: unknown type name 'cpu_context_t'
cpu_context_t *ns_ctx = cm_get_context(NON_SECURE);
^
services/std_svc/sdei/sdei_private.h:165:2: error: unknown type name 'el3_state_t'
el3_state_t *el3_ctx = get_el3state_ctx(ns_ctx);
^
services/std_svc/sdei/sdei_private.h:165:2: error: implicit declaration of function 'get_el3state_ctx' [-Werror=implicit-function-declaration]
services/std_svc/sdei/sdei_private.h:165:25: error: initialization makes pointer from integer without a cast [-Werror]
el3_state_t *el3_ctx = get_el3state_ctx(ns_ctx);
^
services/std_svc/sdei/sdei_private.h:167:2: error: implicit declaration of function 'read_ctx_reg' [-Werror=implicit-function-declaration]
return ((read_ctx_reg(el3_ctx, CTX_SCR_EL3) & SCR_HCE_BIT) != 0U) ?
^
services/std_svc/sdei/sdei_private.h:167:33: error: 'CTX_SCR_EL3' undeclared (first use in this function)
return ((read_ctx_reg(el3_ctx, CTX_SCR_EL3) & SCR_HCE_BIT) != 0U) ?
^
services/std_svc/sdei/sdei_private.h:167:33: note: each undeclared identifier is reported only once for each function it appears in
cc1: all warnings being treated as errors
<snip>
Change-Id: Id0cad56accf81b19cb0d301784f3f086dd052722
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
The codebase was using non-standard headers. It is needed to replace
them by the correct ones so that we can use the new libc headers.
Change-Id: I530f71d9510cb036e69fe79823c8230afe890b9d
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
These changes address most of the required MISRA rules. In the process,
some from generic code is also fixed.
No functional changes.
Change-Id: I6235a355e006f0b1c7c1c4d811b3964a64d0434f
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
commit 2ccfcb2ea5 ("SDEI: Determine client
EL from NS context's SCR_EL3") intended to read from SCR_EL3, but
wrongly read from SPSR_EL3 instead. This patch fixes that.
Change-Id: I8ffea39cc98ef59cb8e7a4c6ef4cb12011c58536
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
SDEI event dispatches currently only sets up the Non-secure context
before returning to the caller. The actual dispatch only happens upon
exiting EL3 next time.
However, for various error handling scenarios, it's beneficial to have
the dispatch happen synchronously. I.e. when receiving SDEI interrupt,
or for a successful sdei_dispatch_event() call, the event handler is
executed; and upon the event completion, dispatcher execution resumes
after the point of dispatch. The jump primitives introduced in the
earlier patch facilitates this feature.
With this patch:
- SDEI interrupts and calls to sdei_dispatch_event prepares the NS
context for event dispatch, then sets a jump point, and immediately
exits EL3. This results in the client handler executing in
Non-secure.
- When the SDEI client completes the dispatched event, the SDEI
dispatcher does a longjmp to the jump pointer created earlier. For
the caller of the sdei_dispatch_event() in particular, this would
appear as if call returned successfully.
The dynamic workaround for CVE_2018_3639 is slightly shifted around as
part of related minor refactoring. It doesn't affect the workaround
functionality.
Documentation updated.
NOTE: This breaks the semantics of the explicit dispatch API, and any
exiting usages should be carefully reviewed.
Change-Id: Ib9c876d27ea2af7fb22de49832e55a0da83da3f9
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
Currently, the dispatcher reads from SCR_EL3 register directly to
determine the EL of SDEI client. This is with the assumption that
SCR_EL3 is not modified throughout. However, with RAS work flows, it's
possible that SCR_EL3 register contains values corresponding to Secure
world, and therefore EL determination can go wrong. To mitigate this,
always read the register from the saved Non-secure context.
Change-Id: Ic85e4021deb18eb58757f676f9a001174998543a
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
The current macros only allow to define dynamic and statically-bound
SDEI events. However, there ought be a mechanism to define SDEI events
that are explicitly dispatched; i.e., events that are dispatched as a
result of a previous secure interrupt or other exception
This patch introduces SDEI_EXPLICIT_EVENT() macro to define an explicit
event. They must be placed under private mappings. Only the priority
flags are allowed to be additionally specified.
Documentation updated.
Change-Id: I2e12f5571381195d6234c9dfbd5904608ad41db3
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
The implementation currently supports only interrupt-based SDEI events,
and supports all interfaces as defined by SDEI specification version
1.0 [1].
Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in
BL31.
Update user guide and porting guide. SDEI documentation to follow.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
Change-Id: I758b733084e4ea3b27ac77d0259705565842241a
Co-authored-by: Yousuf A <yousuf.sait@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
Julius Werner
Antonio Nino Diaz
Paul Beesley
Varun Wadekar
Jeenu Viswambharan