Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 1 | Trusted Firmware-A Coding Guidelines |
| 2 | ==================================== |
| 3 | |
Paul Beesley | ea22512 | 2019-02-11 17:54:45 +0000 | [diff] [blame^] | 4 | |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 5 | |
| 6 | .. contents:: |
| 7 | |
| 8 | The following sections contain TF coding guidelines. They are continually |
| 9 | evolving and should not be considered "set in stone". Feel free to question them |
| 10 | and provide feedback. |
| 11 | |
| 12 | Some of the guidelines may also apply to other codebases. |
| 13 | |
| 14 | **Note:** the existing TF codebase does not necessarily comply with all the |
| 15 | below guidelines but the intent is for it to do so eventually. |
| 16 | |
Paul Beesley | 8b4bdeb | 2019-01-21 12:06:24 +0000 | [diff] [blame] | 17 | Checkpatch overrides |
| 18 | -------------------- |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 19 | |
| 20 | Some checkpatch warnings in the TF codebase are deliberately ignored. These |
| 21 | include: |
| 22 | |
| 23 | - ``**WARNING: line over 80 characters**``: Although the codebase should |
| 24 | generally conform to the 80 character limit this is overly restrictive in some |
| 25 | cases. |
| 26 | |
| 27 | - ``**WARNING: Use of volatile is usually wrong``: see |
| 28 | `Why the “volatile” type class should not be used`_ . Although this document |
| 29 | contains some very useful information, there are several legimate uses of the |
| 30 | volatile keyword within the TF codebase. |
| 31 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 32 | Headers and inclusion |
| 33 | --------------------- |
| 34 | |
| 35 | Header guards |
| 36 | ^^^^^^^^^^^^^ |
| 37 | |
| 38 | For a header file called "some_driver.h" the style used by the Trusted Firmware |
| 39 | is: |
| 40 | |
| 41 | .. code:: c |
| 42 | |
| 43 | #ifndef SOME_DRIVER_H |
| 44 | #define SOME_DRIVER_H |
| 45 | |
| 46 | <header content> |
| 47 | |
| 48 | #endif /* SOME_DRIVER_H */ |
| 49 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 50 | Include statement ordering |
| 51 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 52 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 53 | All header files that are included by a source file must use the following, |
| 54 | grouped ordering. This is to improve readability (by making it easier to quickly |
| 55 | read through the list of headers) and maintainability. |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 56 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 57 | #. *System* includes: Header files from the standard *C* library, such as |
| 58 | ``stddef.h`` and ``string.h``. |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 59 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 60 | #. *Project* includes: Header files under the ``include/`` directory within TF |
| 61 | are *project* includes. |
| 62 | |
| 63 | #. *Platform* includes: Header files relating to a single, specific platform, |
| 64 | and which are located under the ``plat/<platform_name>`` directory within TF, |
| 65 | are *platform* includes. |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 66 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 67 | Within each group, ``#include`` statements must be in alphabetical order, |
| 68 | taking both the file and directory names into account. |
| 69 | |
| 70 | Groups must be separated by a single blank line for clarity. |
| 71 | |
| 72 | The example below illustrates the ordering rules using some contrived header |
| 73 | file names; this type of name reuse should be otherwise avoided. |
Paul Beesley | e5f0f0a | 2019-01-31 11:39:01 +0000 | [diff] [blame] | 74 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 75 | .. code:: c |
| 76 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 77 | #include <string.h> |
| 78 | |
| 79 | #include <a_dir/example/a_header.h> |
| 80 | #include <a_dir/example/b_header.h> |
| 81 | #include <a_dir/test/a_header.h> |
| 82 | #include <b_dir/example/a_header.h> |
| 83 | |
| 84 | #include "./a_header.h" |
| 85 | |
| 86 | Include statement variants |
Sandrine Bailleux | f5a9100 | 2019-02-08 10:50:28 +0100 | [diff] [blame] | 87 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 88 | |
| 89 | Two variants of the ``#include`` directive are acceptable in the TF codebase. |
| 90 | Correct use of the two styles improves readability by suggesting the location |
| 91 | of the included header and reducing ambiguity in cases where generic and |
| 92 | platform-specific headers share a name. |
| 93 | |
| 94 | For header files that are in the same directory as the source file that is |
| 95 | including them, use the ``"..."`` variant. |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 96 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 97 | For header files that are **not** in the same directory as the source file that |
| 98 | is including them, use the ``<...>`` variant. |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 99 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 100 | Example (bl1_fwu.c): |
Paul Beesley | e5f0f0a | 2019-01-31 11:39:01 +0000 | [diff] [blame] | 101 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 102 | .. code:: c |
| 103 | |
| 104 | #include <assert.h> |
| 105 | #include <errno.h> |
| 106 | #include <string.h> |
| 107 | |
| 108 | #include "bl1_private.h" |
| 109 | |
| 110 | Platform include paths |
| 111 | ^^^^^^^^^^^^^^^^^^^^^^ |
| 112 | |
| 113 | Platforms are allowed to add more include paths to be passed to the compiler. |
| 114 | The ``PLAT_INCLUDES`` variable is used for this purpose. This is needed in |
| 115 | particular for the file ``platform_def.h``. |
| 116 | |
| 117 | Example: |
Paul Beesley | e5f0f0a | 2019-01-31 11:39:01 +0000 | [diff] [blame] | 118 | |
Paul Beesley | 5981d11 | 2019-01-22 11:36:41 +0000 | [diff] [blame] | 119 | .. code:: c |
| 120 | |
| 121 | PLAT_INCLUDES += -Iinclude/plat/myplat/include |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 122 | |
| 123 | Types and typedefs |
| 124 | ------------------ |
| 125 | |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 126 | Use of built-in *C* and *libc* data types |
Sandrine Bailleux | f5a9100 | 2019-02-08 10:50:28 +0100 | [diff] [blame] | 127 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 128 | |
| 129 | The TF codebase should be kept as portable as possible, especially since both |
| 130 | 64-bit and 32-bit platforms are supported. To help with this, the following data |
| 131 | type usage guidelines should be followed: |
| 132 | |
| 133 | - Where possible, use the built-in *C* data types for variable storage (for |
| 134 | example, ``char``, ``int``, ``long long``, etc) instead of the standard *C99* |
| 135 | types. Most code is typically only concerned with the minimum size of the |
| 136 | data stored, which the built-in *C* types guarantee. |
| 137 | |
| 138 | - Avoid using the exact-size standard *C99* types in general (for example, |
| 139 | ``uint16_t``, ``uint32_t``, ``uint64_t``, etc) since they can prevent the |
| 140 | compiler from making optimizations. There are legitimate uses for them, |
| 141 | for example to represent data of a known structure. When using them in struct |
| 142 | definitions, consider how padding in the struct will work across architectures. |
| 143 | For example, extra padding may be introduced in AArch32 systems if a struct |
| 144 | member crosses a 32-bit boundary. |
| 145 | |
| 146 | - Use ``int`` as the default integer type - it's likely to be the fastest on all |
| 147 | systems. Also this can be assumed to be 32-bit as a consequence of the |
Paul Beesley | 54c83cf | 2019-01-21 11:57:42 +0000 | [diff] [blame] | 148 | `Procedure Call Standard for the Arm Architecture`_ and the `Procedure Call |
| 149 | Standard for the Arm 64-bit Architecture`_ . |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 150 | |
| 151 | - Avoid use of ``short`` as this may end up being slower than ``int`` in some |
| 152 | systems. If a variable must be exactly 16-bit, use ``int16_t`` or |
| 153 | ``uint16_t``. |
| 154 | |
| 155 | - Avoid use of ``long``. This is guaranteed to be at least 32-bit but, given |
| 156 | that `int` is 32-bit on Arm platforms, there is no use for it. For integers of |
| 157 | at least 64-bit, use ``long long``. |
| 158 | |
| 159 | - Use ``char`` for storing text. Use ``uint8_t`` for storing other 8-bit data. |
| 160 | |
| 161 | - Use ``unsigned`` for integers that can never be negative (counts, |
| 162 | indices, sizes, etc). TF intends to comply with MISRA "essential type" coding |
| 163 | rules (10.X), where signed and unsigned types are considered different |
| 164 | essential types. Choosing the correct type will aid this. MISRA static |
| 165 | analysers will pick up any implicit signed/unsigned conversions that may lead |
| 166 | to unexpected behaviour. |
| 167 | |
| 168 | - For pointer types: |
| 169 | |
| 170 | - If an argument in a function declaration is pointing to a known type then |
| 171 | simply use a pointer to that type (for example: ``struct my_struct *``). |
| 172 | |
| 173 | - If a variable (including an argument in a function declaration) is pointing |
| 174 | to a general, memory-mapped address, an array of pointers or another |
| 175 | structure that is likely to require pointer arithmetic then use |
| 176 | ``uintptr_t``. This will reduce the amount of casting required in the code. |
| 177 | Avoid using ``unsigned long`` or ``unsigned long long`` for this purpose; it |
| 178 | may work but is less portable. |
| 179 | |
| 180 | - For other pointer arguments in a function declaration, use ``void *``. This |
| 181 | includes pointers to types that are abstracted away from the known API and |
| 182 | pointers to arbitrary data. This allows the calling function to pass a |
| 183 | pointer argument to the function without any explicit casting (the cast to |
| 184 | ``void *`` is implicit). The function implementation can then do the |
| 185 | appropriate casting to a specific type. |
| 186 | |
| 187 | - Use ``ptrdiff_t`` to compare the difference between 2 pointers. |
| 188 | |
| 189 | - Use ``size_t`` when storing the ``sizeof()`` something. |
| 190 | |
Paul Beesley | 244c783 | 2019-01-21 12:02:09 +0000 | [diff] [blame] | 191 | - Use ``ssize_t`` when returning the ``sizeof()`` something from a function that |
| 192 | can also return an error code; the signed type allows for a negative return |
| 193 | code in case of error. This practice should be used sparingly. |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 194 | |
| 195 | - Use ``u_register_t`` when it's important to store the contents of a register |
| 196 | in its native size (32-bit in AArch32 and 64-bit in AArch64). This is not a |
| 197 | standard *C99* type but is widely available in libc implementations, |
| 198 | including the FreeBSD version included with the TF codebase. Where possible, |
| 199 | cast the variable to a more appropriate type before interpreting the data. For |
| 200 | example, the following struct in ``ep_info.h`` could use this type to minimize |
| 201 | the storage required for the set of registers: |
| 202 | |
| 203 | .. code:: c |
| 204 | |
| 205 | typedef struct aapcs64_params { |
| 206 | u_register_t arg0; |
| 207 | u_register_t arg1; |
| 208 | u_register_t arg2; |
| 209 | u_register_t arg3; |
| 210 | u_register_t arg4; |
| 211 | u_register_t arg5; |
| 212 | u_register_t arg6; |
| 213 | u_register_t arg7; |
| 214 | } aapcs64_params_t; |
| 215 | |
Sandrine Bailleux | f5a9100 | 2019-02-08 10:50:28 +0100 | [diff] [blame] | 216 | If some code wants to operate on ``arg0`` and knows that it represents a 32-bit |
| 217 | unsigned integer on all systems, cast it to ``unsigned int``. |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 218 | |
| 219 | These guidelines should be updated if additional types are needed. |
| 220 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 221 | Avoid anonymous typedefs of structs/enums in headers |
| 222 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 223 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 224 | For example, the following definition: |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 225 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 226 | .. code:: c |
| 227 | |
| 228 | typedef struct { |
| 229 | int arg1; |
| 230 | int arg2; |
| 231 | } my_struct_t; |
| 232 | |
| 233 | |
| 234 | is better written as: |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 235 | |
| 236 | .. code:: c |
| 237 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 238 | struct my_struct { |
| 239 | int arg1; |
| 240 | int arg2; |
| 241 | }; |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 242 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 243 | This allows function declarations in other header files that depend on the |
| 244 | struct/enum to forward declare the struct/enum instead of including the |
| 245 | entire header: |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 246 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 247 | .. code:: c |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 248 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 249 | #include <my_struct.h> |
| 250 | void my_func(my_struct_t *arg); |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 251 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 252 | instead of: |
| 253 | |
| 254 | .. code:: c |
| 255 | |
| 256 | struct my_struct; |
| 257 | void my_func(struct my_struct *arg); |
| 258 | |
| 259 | Some TF definitions use both a struct/enum name **and** a typedef name. This |
| 260 | is discouraged for new definitions as it makes it difficult for TF to comply |
| 261 | with MISRA rule 8.3, which states that "All declarations of an object or |
| 262 | function shall use the same names and type qualifiers". |
| 263 | |
| 264 | The Linux coding standards also discourage new typedefs and checkpatch emits |
| 265 | a warning for this. |
| 266 | |
| 267 | Existing typedefs will be retained for compatibility. |
| 268 | |
| 269 | Error handling and robustness |
| 270 | ----------------------------- |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 271 | |
| 272 | Using CASSERT to check for compile time data errors |
| 273 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 274 | |
| 275 | Where possible, use the ``CASSERT`` macro to check the validity of data known at |
| 276 | compile time instead of checking validity at runtime, to avoid unnecessary |
| 277 | runtime code. |
| 278 | |
| 279 | For example, this can be used to check that the assembler's and compiler's views |
| 280 | of the size of an array is the same. |
| 281 | |
| 282 | .. code:: c |
| 283 | |
| 284 | #include <cassert.h> |
| 285 | |
| 286 | define MY_STRUCT_SIZE 8 /* Used by assembler source files */ |
| 287 | |
| 288 | struct my_struct { |
| 289 | uint32_t arg1; |
| 290 | uint32_t arg2; |
| 291 | }; |
| 292 | |
| 293 | CASSERT(MY_STRUCT_SIZE == sizeof(struct my_struct), assert_my_struct_size_mismatch); |
| 294 | |
| 295 | |
| 296 | If ``MY_STRUCT_SIZE`` in the above example were wrong then the compiler would |
| 297 | emit an error like this: |
| 298 | |
| 299 | .. code:: c |
| 300 | |
| 301 | my_struct.h:10:1: error: size of array ‘assert_my_struct_size_mismatch’ is negative |
| 302 | |
| 303 | |
| 304 | Using assert() to check for programming errors |
| 305 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 306 | |
| 307 | In general, each secure world TF image (BL1, BL2, BL31 and BL32) should be |
| 308 | treated as a tightly integrated package; the image builder should be aware of |
| 309 | and responsible for all functionality within the image, even if code within that |
| 310 | image is provided by multiple entities. This allows us to be more aggressive in |
| 311 | interpreting invalid state or bad function arguments as programming errors using |
| 312 | ``assert()``, including arguments passed across platform porting interfaces. |
| 313 | This is in contrast to code in a Linux environment, which is less tightly |
| 314 | integrated and may attempt to be more defensive by passing the error back up the |
| 315 | call stack. |
| 316 | |
| 317 | Where possible, badly written TF code should fail early using ``assert()``. This |
| 318 | helps reduce the amount of untested conditional code. By default these |
| 319 | statements are not compiled into release builds, although this can be overridden |
| 320 | using the ``ENABLE_ASSERTIONS`` build flag. |
| 321 | |
| 322 | Examples: |
| 323 | |
| 324 | - Bad argument supplied to library function |
| 325 | - Bad argument provided by platform porting function |
| 326 | - Internal secure world image state is inconsistent |
| 327 | |
| 328 | |
| 329 | Handling integration errors |
| 330 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 331 | |
| 332 | Each secure world image may be provided by a different entity (for example, a |
| 333 | Trusted Boot vendor may provide the BL2 image, a TEE vendor may provide the BL32 |
| 334 | image and the OEM/SoC vendor may provide the other images). |
| 335 | |
| 336 | An image may contain bugs that are only visible when the images are integrated. |
| 337 | The system integrator may not even have access to the debug variants of all the |
| 338 | images in order to check if asserts are firing. For example, the release variant |
| 339 | of BL1 may have already been burnt into the SoC. Therefore, TF code that detects |
| 340 | an integration error should _not_ consider this a programming error, and should |
| 341 | always take action, even in release builds. |
| 342 | |
| 343 | If an integration error is considered non-critical it should be treated as a |
| 344 | recoverable error. If the error is considered critical it should be treated as |
| 345 | an unexpected unrecoverable error. |
| 346 | |
| 347 | Handling recoverable errors |
| 348 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 349 | |
| 350 | The secure world **must not** crash when supplied with bad data from an external |
| 351 | source. For example, data from the normal world or a hardware device. Similarly, |
| 352 | the secure world **must not** crash if it detects a non-critical problem within |
| 353 | itself or the system. It must make every effort to recover from the problem by |
| 354 | emitting a ``WARN`` message, performing any necessary error handling and |
| 355 | continuing. |
| 356 | |
| 357 | Examples: |
| 358 | |
| 359 | - Secure world receives SMC from normal world with bad arguments. |
| 360 | - Secure world receives SMC from normal world at an unexpected time. |
| 361 | - BL31 receives SMC from BL32 with bad arguments. |
| 362 | - BL31 receives SMC from BL32 at unexpected time. |
| 363 | - Secure world receives recoverable error from hardware device. Retrying the |
| 364 | operation may help here. |
| 365 | - Non-critical secure world service is not functioning correctly. |
| 366 | - BL31 SPD discovers minor configuration problem with corresponding SP. |
| 367 | |
| 368 | Handling unrecoverable errors |
| 369 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 370 | |
| 371 | In some cases it may not be possible for the secure world to recover from an |
| 372 | error. This situation should be handled in one of the following ways: |
| 373 | |
| 374 | 1. If the unrecoverable error is unexpected then emit an ``ERROR`` message and |
| 375 | call ``panic()``. This will end up calling the platform-specific function |
| 376 | ``plat_panic_handler()``. |
| 377 | 2. If the unrecoverable error is expected to occur in certain circumstances, |
| 378 | then emit an ``ERROR`` message and call the platform-specific function |
| 379 | ``plat_error_handler()``. |
| 380 | |
| 381 | Cases 1 and 2 are subtly different. A platform may implement ``plat_panic_handler`` |
| 382 | and ``plat_error_handler`` in the same way (for example, by waiting for a secure |
| 383 | watchdog to time-out or by invoking an interface on the platform's power |
| 384 | controller to reset the platform). However, ``plat_error_handler`` may take |
| 385 | additional action for some errors (for example, it may set a flag so the |
| 386 | platform resets into a different mode). Also, ``plat_panic_handler()`` may |
| 387 | implement additional debug functionality (for example, invoking a hardware |
| 388 | breakpoint). |
| 389 | |
| 390 | Examples of unexpected unrecoverable errors: |
| 391 | |
| 392 | - BL32 receives an unexpected SMC response from BL31 that it is unable to |
| 393 | recover from. |
| 394 | - BL31 Trusted OS SPD code discovers that BL2 has not loaded the corresponding |
| 395 | Trusted OS, which is critical for platform operation. |
| 396 | - Secure world discovers that a critical hardware device is an unexpected and |
| 397 | unrecoverable state. |
| 398 | - Secure world receives an unexpected and unrecoverable error from a critical |
| 399 | hardware device. |
| 400 | - Secure world discovers that it is running on unsupported hardware. |
| 401 | |
| 402 | Examples of expected unrecoverable errors: |
| 403 | |
| 404 | - BL1/BL2 fails to load the next image due to missing/corrupt firmware on disk. |
| 405 | - BL1/BL2 fails to authenticate the next image due to an invalid certificate. |
| 406 | - Secure world continuously receives recoverable errors from a hardware device |
| 407 | but is unable to proceed without a valid response. |
| 408 | |
| 409 | Handling critical unresponsiveness |
| 410 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 411 | |
| 412 | If the secure world is waiting for a response from an external source (for |
| 413 | example, the normal world or a hardware device) which is critical for continued |
| 414 | operation, it must not wait indefinitely. It must have a mechanism (for example, |
| 415 | a secure watchdog) for resetting itself and/or the external source to prevent |
| 416 | the system from executing in this state indefinitely. |
| 417 | |
| 418 | Examples: |
| 419 | |
| 420 | - BL1 is waiting for the normal world to raise an SMC to proceed to the next |
| 421 | stage of the secure firmware update process. |
| 422 | - A Trusted OS is waiting for a response from a proxy in the normal world that |
| 423 | is critical for continued operation. |
| 424 | - Secure world is waiting for a hardware response that is critical for continued |
| 425 | operation. |
| 426 | |
| 427 | Security considerations |
| 428 | ----------------------- |
| 429 | |
| 430 | Part of the security of a platform is handling errors correctly, as described in |
| 431 | the previous section. There are several other security considerations covered in |
| 432 | this section. |
| 433 | |
| 434 | Do not leak secrets to the normal world |
| 435 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 436 | |
| 437 | The secure world **must not** leak secrets to the normal world, for example in |
| 438 | response to an SMC. |
| 439 | |
| 440 | Handling Denial of Service attacks |
| 441 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 442 | |
| 443 | The secure world **should never** crash or become unusable due to receiving too |
| 444 | many normal world requests (a *Denial of Service* or *DoS* attack). It should |
| 445 | have a mechanism for throttling or ignoring normal world requests. |
| 446 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 447 | Performance considerations |
| 448 | -------------------------- |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 449 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 450 | Avoid printf and use logging macros |
| 451 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 452 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 453 | ``debug.h`` provides logging macros (for example, ``WARN`` and ``ERROR``) |
| 454 | which wrap ``tf_log`` and which allow the logging call to be compiled-out |
| 455 | depending on the ``make`` command. Use these macros to avoid print statements |
| 456 | being compiled unconditionally into the binary. |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 457 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 458 | Each logging macro has a numerical log level: |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 459 | |
| 460 | .. code:: c |
| 461 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 462 | #define LOG_LEVEL_NONE 0 |
| 463 | #define LOG_LEVEL_ERROR 10 |
| 464 | #define LOG_LEVEL_NOTICE 20 |
| 465 | #define LOG_LEVEL_WARNING 30 |
| 466 | #define LOG_LEVEL_INFO 40 |
| 467 | #define LOG_LEVEL_VERBOSE 50 |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 468 | |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 469 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 470 | By default, all logging statements with a log level ``<= LOG_LEVEL_INFO`` will |
| 471 | be compiled into debug builds and all statements with a log level |
| 472 | ``<= LOG_LEVEL_NOTICE`` will be compiled into release builds. This can be |
| 473 | overridden from the command line or by the platform makefile (although it may be |
| 474 | necessary to clean the build directory first). For example, to enable |
| 475 | ``VERBOSE`` logging on FVP: |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 476 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 477 | ``make PLAT=fvp LOG_LEVEL=50 all`` |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 478 | |
| 479 | Use const data where possible |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 480 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 481 | |
| 482 | For example, the following code: |
| 483 | |
| 484 | .. code:: c |
| 485 | |
| 486 | struct my_struct { |
| 487 | int arg1; |
| 488 | int arg2; |
| 489 | }; |
| 490 | |
| 491 | void init(struct my_struct *ptr); |
| 492 | |
| 493 | void main(void) |
| 494 | { |
| 495 | struct my_struct x; |
| 496 | x.arg1 = 1; |
| 497 | x.arg2 = 2; |
| 498 | init(&x); |
| 499 | } |
| 500 | |
| 501 | is better written as: |
| 502 | |
| 503 | .. code:: c |
| 504 | |
| 505 | struct my_struct { |
| 506 | int arg1; |
| 507 | int arg2; |
| 508 | }; |
| 509 | |
| 510 | void init(const struct my_struct *ptr); |
| 511 | |
| 512 | void main(void) |
| 513 | { |
| 514 | const struct my_struct x = { 1, 2 }; |
| 515 | init(&x); |
| 516 | } |
| 517 | |
| 518 | This allows the linker to put the data in a read-only data section instead of a |
| 519 | writeable data section, which may result in a smaller and faster binary. Note |
| 520 | that this may require dependent functions (``init()`` in the above example) to |
| 521 | have ``const`` arguments, assuming they don't need to modify the data. |
| 522 | |
Paul Beesley | fd68834 | 2019-01-21 16:11:28 +0000 | [diff] [blame] | 523 | Library and driver code |
| 524 | ----------------------- |
| 525 | |
| 526 | TF library code (under ``lib/`` and ``include/lib``) is any code that provides a |
| 527 | reusable interface to other code, potentially even to code outside of TF. |
| 528 | |
| 529 | In some systems drivers must conform to a specific driver framework to provide |
| 530 | services to the rest of the system. TF has no driver framework and the |
| 531 | distinction between a driver and library is somewhat subjective. |
| 532 | |
| 533 | A driver (under ``drivers/`` and ``include/drivers/``) is defined as code that |
| 534 | interfaces with hardware via a memory mapped interface. |
| 535 | |
| 536 | Some drivers (for example, the Arm CCI driver in ``include/drivers/arm/cci.h``) |
| 537 | provide a general purpose API to that specific hardware. Other drivers (for |
| 538 | example, the Arm PL011 console driver in ``drivers/arm/pl011/pl011_console.S``) |
| 539 | provide a specific hardware implementation of a more abstract library API. In |
| 540 | the latter case there may potentially be multiple drivers for the same hardware |
| 541 | device. |
| 542 | |
| 543 | Neither libraries nor drivers should depend on platform-specific code. If they |
| 544 | require platform-specific data (for example, a base address) to operate then |
| 545 | they should provide an initialization function that takes the platform-specific |
| 546 | data as arguments. |
| 547 | |
| 548 | TF common code (under ``common/`` and ``include/common/``) is code that is re-used |
| 549 | by other generic (non-platform-specific) TF code. It is effectively internal |
| 550 | library code. |
| 551 | |
Paul Beesley | 4e2e1b2 | 2019-01-17 15:44:37 +0000 | [diff] [blame] | 552 | .. _`Why the “volatile” type class should not be used`: https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html |
Paul Beesley | 54c83cf | 2019-01-21 11:57:42 +0000 | [diff] [blame] | 553 | .. _`Procedure Call Standard for the Arm Architecture`: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf |
| 554 | .. _`Procedure Call Standard for the Arm 64-bit Architecture`: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf |