9. Secure Development Guidelines
This page contains guidance on what to check for additional security measures, including build options that can be modified to improve security or catch issues early in development.
9.1. Security considerations
Part of the security of a platform is handling errors correctly, as described in the previous section. There are several other security considerations covered in this section.
9.1.1. Do not leak secrets to the normal world
The secure world must not leak secrets to the normal world, for example in response to an SMC.
9.1.2. Handling Denial of Service attacks
The secure world should never crash or become unusable due to receiving too many normal world requests (a Denial of Service or DoS attack). It should have a mechanism for throttling or ignoring normal world requests.
9.1.3. Preventing Secure-world timing information leakage via PMU counters
The Secure world needs to implement some defenses to prevent the Non-secure world from making it leak timing information. In general, higher privilege levels must defend from those below when the PMU is treated as an attack vector.
Refer to the Performance Monitoring Unit guide for detailed information on the PMU registers.
18.104.22.168. Timing leakage attacks from the Non-secure world
Since the Non-secure world has access to the
PMCR register, it can
configure the PMU to increment counters at any exception level and in both
Secure and Non-secure state. Thus, it attempts to leak timing information from
the Secure world.
Shown below is an example of such a configuration:
This configuration instructs
PMCCNTR_EL0 to increment
at Secure EL1, Secure EL2 (if implemented) and EL3.
Since the Non-secure world has fine-grained control over where (at which exception levels) it instructs counters to increment, obtaining event counts would allow it to carry out side-channel timing attacks against the Secure world. Examples include Spectre, Meltdown, as well as extracting secrets from cryptographic algorithms with data-dependent variations in their execution time.
22.214.171.124. Secure world mitigation strategies
MDCR_EL3 register allows EL3 to configure the PMU (among other things).
The Arm ARM details all of the bit fields in this register, but for the PMU
there are two bits which determine the permissions of the counters:
SPMEfor the programmable counters.
SCCDfor the cycle counter.
Depending on the implemented features, the Secure world can prohibit counting in AArch64 state via the following:
ARMv8.2-Debug not implemented:
Prohibit general event counters and the cycle counter:
MDCR_EL3.SPME == 0 && PMCR_EL0.DP == 1 && !ExternalSecureNoninvasiveDebugEnabled().
0, so by default general events should not be counted in the Secure world.
PMCR_EL0.DPbit therefore needs to be set to
1when EL3 is entered and
PMCR_EL0needs to be saved and restored in EL3.
ExternalSecureNoninvasiveDebugEnabled()is an authentication interface which is implementation-defined unless ARMv8.4-Debug is implemented. The Arm ARM has detailed information on this topic.
The only other way is to disable the
PMCR_EL0.Ebit upon entering EL3, which disables counting altogether.
Prohibit general event counters:
MDCR_EL3.SPME == 0.
Prohibit cycle counter:
MDCR_EL3.SPME == 0 && PMCR_EL0.DP == 1.
PMCR_EL0therefore needs to be saved and restored in EL3.
Prohibit general event counters: as in ARMv8.2-Debug.
Prohibit cycle counter:
MDCR_EL3.SCCD == 1
In Aarch32 execution state the
MDCR_EL3 alias is the
which has some of the bit fields of
MDCR_EL3, most importantly the
9.2. Build options
Several build options can be used to check for security issues. Refer to the Build Options for detailed information on these.
BRANCH_PROTECTIONbuild flag can be used to enable Pointer Authentication and Branch Target Identification.
ENABLE_STACK_PROTECTORbuild flag can be used to identify buffer overflows.
Wbuild flag can be used to enable a number of compiler warning options to detect potentially incorrect code.
W=0 (default value)
Wvlaflags are enabled.
Wpacked-bitfield-compatare GCC specific flags that are also enabled.
Refer to the GCC or Clang documentation for more information on the individual options: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html and https://clang.llvm.org/docs/DiagnosticsReference.html.
Werrorflag is enabled by default in TF-A and can be disabled by setting the
Ebuild flag to 0.
Copyright (c) 2019-2020, Arm Limited. All rights reserved.