@@ -19,8 +19,8 @@ Punchboot is a secure and fast bootloader for embedded systems. It is designed t
19
19
- Minimize software download time in production
20
20
- Be useful for day-to-day development
21
21
22
- Punchboot is designed for embedded systems and therefore it has a minimalistic
23
- apporach. There is no run-time configuration, everything is configured in
22
+ Punchboot is designed for embedded systems and therefore it has a minimalistic
23
+ apporach. There is no run-time configuration, everything is configured in
24
24
the board files.
25
25
26
26
Punchboot could be useful if you care about the following:
@@ -108,22 +108,22 @@ this way many different public keys can be stored in a flash memory and every
108
108
time the device boots it will compute a sha256 checksum and compare it to the
109
109
fused checksum.
110
110
111
- Punchboot is designed to be a part of a secure boot chain. This means that
112
- the bootloader is cryptographically signed, the ROM code of the SoC must
113
- support a mechanism to validate this signature, otherwise there is no
111
+ Punchboot is designed to be a part of a secure boot chain. This means that
112
+ the bootloader is cryptographically signed, the ROM code of the SoC must
113
+ support a mechanism to validate this signature, otherwise there is no
114
114
root of trust.
115
115
116
116
When punchboot has been verified it, in turn, will load and verify the next
117
117
software component in the boot chain. The bootloader _ only_ supports signed
118
118
binaries.
119
119
120
120
## Testing and integration tests
121
- Punchboot uses QEMU for all module and integration tests. The 'test' platform
122
- and board target relies on virtio serial ports and block devices. The punchboot
123
- cli can be built with a domain socket transport instead of USB for communicating
121
+ Punchboot uses QEMU for all module and integration tests. The 'test' platform
122
+ and board target relies on virtio serial ports and block devices. The punchboot
123
+ cli can be built with a domain socket transport instead of USB for communicating
124
124
with an QEMU environment.
125
125
126
- The test platform code includes gcov code that calls the QEMU semihosting API
126
+ The test platform code includes gcov code that calls the QEMU semihosting API
127
127
for storing test coverage data on the host.
128
128
129
129
Building and running tests:
@@ -135,30 +135,30 @@ $ make check
135
135
136
136
## Device identity
137
137
138
- Most modern SoC's provide some kind of unique identity, that is guaranteed to
139
- be unique for that particular type of SoC / Vendor etc but can not be guarateed
138
+ Most modern SoC's provide some kind of unique identity, that is guaranteed to
139
+ be unique for that particular type of SoC / Vendor etc but can not be guarateed
140
140
to be globally unique.
141
141
142
- Punchboot provides a UUID3 device identity based on a combination of the unique
142
+ Punchboot provides a UUID3 device identity based on a combination of the unique
143
143
data from the SoC and an allocated, random, namspace UUID per platform.
144
144
145
- When booting a linux system this information is relayed to linux through
145
+ When booting a linux system this information is relayed to linux through
146
146
in-line patching of the device-tree.
147
147
The device identity can be found in '/proc/device-tree/chosen/device-uuid'
148
148
149
149
## Command mode
150
150
151
- Command mode is entered when the system can't boot or if the bootloader is
151
+ Command mode is entered when the system can't boot or if the bootloader is
152
152
forced by a configurable, external event to do so.
153
153
154
- In the command mode it is possible to update the bootloader, write data to
155
- partitions and install default settings. From v0.3 and forward
156
- an 'authentication cookie' must be used to interact with the bootloader to
157
- prevent malicious activity. The only command that can be executed without
154
+ In the command mode it is possible to update the bootloader, write data to
155
+ partitions and install default settings. From v0.3 and forward
156
+ an 'authentication cookie' must be used to interact with the bootloader to
157
+ prevent malicious activity. The only command that can be executed without
158
158
authentication is listing the device information (including the device UUID)
159
159
160
- The authentication cookie consists of the device UUID encrypted with one of
161
- the active key pair's private key.
160
+ The authentication cookie consists of the device UUID encrypted with one of
161
+ the active key pair's private key.
162
162
163
163
## punchboot tool
164
164
The punchboot CLI is used for interacting with the command mode. A summary of the features available:
@@ -223,7 +223,7 @@ Authenticating using key index 0 and './0B177094-6B62-3572-902E-C1DE339ECB01.tok
223
223
Read 103 bytes
224
224
Authentication successful
225
225
```
226
- Now the command mode is fully unlocked. The token is of course only valid for
226
+ Now the command mode is fully unlocked. The token is of course only valid for
227
227
the individual unit with that perticular UUID.
228
228
229
229
## Metrics
@@ -279,4 +279,3 @@ The POR time is off due to some unidentified problem with the SCU firmware.
279
279
3 . Implement test case(s) to ensure that future changes do not break legacy
280
280
4 . Run checks: cp configs/test_defconfig .config && make check
281
281
5 . Create pull request
282
-
0 commit comments