You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(security): Formatting cleanup to Secure Boot page
Changes the indentation to 3 spaces, adds :file: and :code: directive to
appropriate places, and wrap long lines to 80 characters. While here,
also update the name "U-Boot" to have a consistent case everywhere, and
update ATF to TF-A.
Signed-off-by: T Pratham <t-pratham@ti.com>
@@ -15,7 +15,7 @@ pass authentication for Public Boot ROM to continue boot. It is then the respons
15
15
each next stage is itself authenticated. One weak link and all lower trust levels could be compromised.
16
16
17
17
.. Note::
18
-
Example: Forgetting to disable u-boot console or environment loading means a non-secured linux can be loaded. The U-Boot console (or command
18
+
Example: Forgetting to disable U-Boot console or environment loading means a non-secured linux can be loaded. The U-Boot console (or command
19
19
line interface (CLI)) and environment are powerful features that make it great for creating a customized boot process. However,
20
20
leaving either or them enabled in a production system allows non-secured software to be loaded and the Chain-of-Trust to be broken.
21
21
@@ -24,7 +24,7 @@ The following is an example list where Chain-of-Trust should be maintained.
24
24
- Remove U-Boot uEnv.txt loading support.
25
25
- Disable environment loading (the default built-in environment must be compiled to be the one you want).
26
26
- Environment must not fallback to other boot modes.
27
-
- Place firewalls in board-config to match the location of loaded artifacts (ATF/OP-TEE).
27
+
- Place firewalls in board-config to match the location of loaded artifacts (TF-A/OP-TEE).
28
28
- Update debug sections of initial image cert.
29
29
- Enable DM-verity/DM-crypt.
30
30
- Set root password or disable root account.
@@ -55,11 +55,12 @@ The following is an example list where Chain-of-Trust should be maintained.
55
55
.. Image:: /images/K3_KF.png
56
56
:scale:70%
57
57
58
-
Secure boot has layers. Some layers are trusted more than others. Secure ROM has the highest trust and Runtime Execution
59
-
Environment (REE) non-trustzone user-space applications have the least. If a
60
-
lower trust entity must load a higher trust code, an even higher trust entity
61
-
must verify it and not allow access by the lower trust entity after that
62
-
point. Some such trust inversions are as follows:
58
+
Secure boot has layers. Some layers are trusted more than others. Secure ROM
59
+
has the highest trust and Runtime Execution Environment (REE) non-trustzone
60
+
user-space applications have the least. If a lower trust entity must load a
61
+
higher trust code, an even higher trust entity must verify it and not allow
62
+
access by the lower trust entity after that point. Some such trust inversions
63
+
are as follows:
63
64
64
65
.. ifconfig:: CONFIG_part_variant in ('AM62LX')
65
66
@@ -73,7 +74,8 @@ point. Some such trust inversions are as follows:
73
74
- R5 Public Boot ROM loading TIFS
74
75
- Linux loading Trusted applications (TA)
75
76
76
-
These are called out in the sequence as shown in the following image and their method of ensuring trust is explained.
77
+
These are called out in the sequence as shown in the following image and
78
+
their method of ensuring trust is explained.
77
79
78
80
Secure Boot Flow
79
81
--------------------
@@ -128,7 +130,8 @@ Secure Boot Flow
128
130
location is device dependent. More details can be found in the device
129
131
"Technical Reference Manual".
130
132
131
-
The contents of this first stage image are authenticated and decrypted by the Secure ROM. Contents include:
133
+
The contents of this first stage image are authenticated and decrypted by
134
+
the Secure ROM. Contents include:
132
135
133
136
* `Texas Instruments Foundational Security (TIFS)` firmware: After authentication/decryption, TIFS firmware replaces the Secure ROM as the authenticator entity executing on the M4 core in the 2nd phase of the boot.
134
137
* BL-1: The pre-bootloader executed on the A53 core, initializes the console and DDR for the 2nd phase of the boot.
@@ -212,84 +215,98 @@ Secure Boot Flow
212
215
213
216
.. rubric:: U-Boot
214
217
215
-
The boot flow continues as it does on a non-secure device, until loading the next FIT image named `fitImage`. This FIT image includes the Linux kernel, DTB, and
216
-
other required boot artifacts. U-boot verifies the signed images on boot independently, without using TIFS. U-boot extracts each component from the FIT image and verifies its signature. Once u-boot verifies all components, it starts Linux. For more information, see: `U-Boot FIT Signature Documentation <https://docs.u-boot.org/en/latest/usage/fit/signature.html>`__
218
+
The boot flow continues as it does on a non-secure device, until loading the
219
+
next FIT image named :file:`fitImage`. This FIT image includes the Linux
220
+
kernel, DTB, and other required boot artifacts. U-Boot verifies the signed
221
+
images on boot independently, without using TIFS. U-Boot extracts each
222
+
component from the FIT image and verifies its signature. Once U-Boot verifies
223
+
all components, it starts Linux. For more information, see:
224
+
`U-Boot FIT Signature Documentation <https://docs.u-boot.org/en/latest/usage/fit/signature.html>`__
Loading Environment from FAT... *** Warning - bad CRC, using default environment
239
+
240
+
In: serial@2800000
241
+
Out: serial@2800000
242
+
Err: serial@2800000
243
+
Net: eth0: ethernet@8000000port@1
244
+
Hit any key to stop autoboot: 0
245
+
switch to partitions #0, OK
246
+
mmc1 is current device
247
+
SD/MMC found on device 1
248
+
Failed to load 'boot.scr'
249
+
1011 bytes read in 2 ms (493.2 KiB/s)
250
+
Loaded env from uEnv.txt
251
+
Importing environment from mmc1 ...
252
+
Running uenvcmd ...
253
+
7862647 bytes read in 328 ms (22.9 MiB/s)
254
+
## Loading kernel from FIT Image at 90000000 ...
255
+
Using 'k3-am642-evm.dtb' configuration
256
+
Trying 'kernel@1' kernel subimage
257
+
Description: Linux kernel
258
+
Type: Kernel Image
259
+
Compression: gzip compressed
260
+
Data Start: 0x900000f8
261
+
Data Size: 7743643 Bytes = 7.4 MiB
262
+
Architecture: AArch64
263
+
OS: Linux
264
+
Load Address: 0x80080000
265
+
Entry Point: 0x80080000
266
+
Verifying Hash Integrity ... OK
267
+
## Loading fdt from FIT Image at 90000000 ...
268
+
Using 'k3-am642-evm.dtb' configuration
269
+
Trying 'k3-am642-evm.dtb' fdt subimage
270
+
Description: Flattened Device Tree blob
271
+
Type: Flat Device Tree
272
+
Compression: uncompressed
273
+
Data Start: 0x90762a54
274
+
Data Size: 56436 Bytes = 55.1 KiB
275
+
Architecture: AArch64
276
+
Load Address: 0x83000000
277
+
Verifying Hash Integrity ... OK
278
+
Loading fdt from 0x90762a54 to 0x83000000
279
+
Booting using the fdt blob at 0x83000000
280
+
Uncompressing Kernel Image
281
+
Loading Device Tree to 000000008ffef000, end 000000008ffff602 ... OK
274
282
275
283
.. rubric:: Linux
276
284
277
-
If initramfs is included, we can trust our initial modules and tasks, but we cannot trust anything beyond this as the root file-system may have been
278
-
modified. To allow trusted use of files outside of our initramfs we use dm-verity. With this we can authenticate a block device as we read from it. As
279
-
any changes to this block-device will cause the authentication to fail, we cannot put any user-modifiable configurations or user installed programs
280
-
here. Only important, read-only, files should be placed on this partition, such as static kernel and operating system files and configurations. All
281
-
other files must be placed in a non-verifiable read-write user partition.
285
+
If initramfs is included, we can trust our initial modules and tasks, but we
286
+
cannot trust anything beyond this as the root file-system may have been
287
+
modified. To allow trusted use of files outside of our initramfs we use
288
+
dm-verity. With this we can authenticate a block device as we read from it. As
289
+
any changes to this block-device will cause the authentication to fail, we
290
+
cannot put any user-modifiable configurations or user installed programs here.
291
+
Only important, read-only, files should be placed on this partition, such as
292
+
static kernel and operating system files and configurations. All other files
293
+
must be placed in a non-verifiable read-write user partition.
282
294
283
295
HS Boot Flow Tools
284
296
-------------------
285
297
286
-
U-boot:
298
+
U-Boot:
287
299
288
300
.. ifconfig:: CONFIG_part_variant not in ('AM62LX')
289
301
290
-
The ti-u-boot source is a project used to create tiboot3.bin, tispl.bin, and u-boot.img. To create tiboot3.bin for K3 family devices, u-boot builds R5 SPL and
291
-
binman packages it in a `tiboot3.bin` image. To build A53 SPL, binman takes TF-A (bl31.bin), OPTEE (bl32.bin), A53 SPL, and A53 DTBs and packages
292
-
them in a `tispl.bin` image. U-Boot can then use the openssl library to sign each component as specified in k3-<soc>-binman.dtsi.
302
+
The ti-u-boot source is a project used to create :file:`tiboot3.bin`,
303
+
:file:`tispl.bin`, and :file:`u-boot.img`. To create :file:`tiboot3.bin`
304
+
for K3 family devices, U-Boot builds R5 SPL and binman packages it in a
305
+
:file:`tiboot3.bin` image. To build A53 SPL, binman takes TF-A
306
+
(:file:`bl31.bin`), OPTEE (:file:`bl32.bin`), A53 SPL, and A53 DTBs and
307
+
packages them in a :file:`tispl.bin` image. U-Boot can then use the
308
+
openssl library to sign each component as specified in
309
+
:file:`k3-<soc>-binman.dtsi`.
293
310
294
311
.. code-block:: console
295
312
@@ -320,47 +337,57 @@ U-boot:
320
337
321
338
Linux:
322
339
323
-
The ti-linux source is a TI project used to build Linux kernel, DTB, and other boot artifacts. Some of these components could be included in a verifiable image
324
-
`fitImage`. For HS devices, only the fitImage will be allowed to boot once `fitImage` has been authenticated.
340
+
The ti-linux source is a TI project used to build Linux kernel, DTB, and
341
+
other boot artifacts. Some of these components could be included in a
342
+
verifiable image :file:`fitImage`. For HS devices, only the fitImage will be
343
+
allowed to boot once :file:`fitImage` has been authenticated.
$ make CROSS_COMPILE64=aarch64-linux-gnu- PLATFORM=k3-<soc> CFG_ARM64_core=y
377
+
$ # Example use:
378
+
$ make CROSS_COMPILE64=aarch64-linux-gnu- PLATFORM=k3-<soc> CFG_ARM64_core=y
356
379
357
380
Ti-linux-firmware:
358
381
359
-
The ti-linux-firmware is a TI repository where all firmware releases are stored. Firmwares for a device family can also be found in the pre-built SDK
360
-
under :file:`<path-to-tisdk>/board-support/prebuilt-images/<evm>`. Binman expects to find the device firmware with the following appended to u-boot build command:
361
-
BINMAN_INDIRS=<path-to-tisdk>/board-support/prebuilt-images, and expects to find a ti-sysfw directory in this path.
382
+
The ti-linux-firmware is a TI repository where all firmware releases are
383
+
stored. Firmwares for a device family can also be found in the pre-built SDK
384
+
under :file:`<path-to-tisdk>/board-support/prebuilt-images/<evm>`. Binman
385
+
expects to find the device firmware with the following appended to U-Boot
386
+
build command:
387
+
:code:`BINMAN_INDIRS=<path-to-tisdk>/board-support/prebuilt-images`, and
388
+
expects to find a ti-sysfw directory in this path.
0 commit comments