measured_boot.md
1 # Measured Boot 2 Measured boot feature was initially implemented as an extension of Google 3 Verified Boot. However, the two features were decoupled since then and use of 4 measured boot no longer requires enabling vboot. 5 6 In most cases TPM eventlog is initialized during bootblock before TPM gets set 7 up, hence digests are not measured into TPM immediately, but are only cached in 8 the event log. Later, as part of TPM setup, the cached events are applied onto 9 TPM device. The behaviour is different if TPM_MEASURED_BOOT_INIT_BOOTBLOCK 10 kconfig is set, which moves TPM initialization into bootblock. 11 12 ## SRTM 13 A measured-based trust chain is one that begins with an initial entity that 14 takes the first measurement, referred to as the "Core Root of Trust for 15 Measurement" (CRTM), before control is granted to the measured entity. This 16 process of measurement and then passing control is referred to as a transitive 17 trust. When the CRTM can only ever be executed once during the power life-cycle 18 of the system, it is referred to as a "Static CRTM" (S-CRTM). Thus the trust 19 chain constructed from the S-CRTM is referred to as the Static Root of Trust for 20 Measurement (SRTM) trust chain. The theory is that as long as a proper 21 transitive trust is conducted as more code is allowed to execute, a trustworthy 22 record showing the provenance of the executing system may be provided to 23 establish the trustworthiness of the system. 24 25 ## IBB/CRTM 26 The "Initial Boot Block" (IBB) is a one-time executed code block loaded at the 27 reset vector. Under measured boot mode, the IBB measures itself before measuring 28 the next code block making it an S-CRTM for the measured boot trust chain, an 29 SRTM trust chain. Since the IBB measures itself and executes out of DRAM, it is 30 said to have a "Root of Trust" (RoT) that is rooted in software. 31 32 ## S-CRTM Hardening 33 To address attacks that took advantage of the IBB being self-referential with 34 both the "Root of Trust for Verification" (RTV) and "Root of Trust for 35 Measurement" (RTM) being rooted in software, hardening was implemented by CPU 36 manufactures. This was accomplished by introducing RoT, typically an RTV, to an 37 external entity provided by the manufacture that could be validated by the CPU 38 at boot. Examples of this are Intel's BootGuard and AMD's Hardware Validated 39 Boot (also known as Platform Secure Boot). These solutions work by having the 40 IBB invoke the manufacture provided RoT as early as possible, for which the CPU 41 has already validated or validates when invoked. The RoT will then validate the 42 IBB, thus moving the root for the respective trust chain, typically the 43 verification trust chain, into hardware. 44 45 It should be noted that when Intel BootGuard was originally designed, it 46 provided a measurement mode that resulted in the ACM (Authenticated Code 47 Module) becoming the S-CRTM for the SRTM trust chain. Unfortunately, this was 48 never deployed and thus relying on "Root of Trust for Verification" (RTV) 49 signature check as the only assertion rooted in hardware. 50 51 ## Known Limitations 52 At the moment measuring IBB dynamically and FMAP partitions are not possible but 53 will be added later to the implementation. 54 55 Also SoCs making use of VBOOT_RETURN_FROM_VERSTAGE are not able to use the 56 measured boot extension because of platform constraints. 57 58 ### Measurements 59 To construct the coreboot SRTM trust chain, the CBFS files which are part of the 60 IBB, are identified by a metadata tag. This makes it possible to have platform 61 specific IBB measurements without hard-coding them. 62 63 #### CBFS files (stages, blobs) 64 * CBFS data is measured as raw data before decompression happens. 65 * CBFS header is excluded from measurements. 66 * Measurements are stored in PCR 2 (by default, use PCR_SRTM kconfig option to 67 change). 68 69 #### Runtime Data 70 * CBFS data which changes by external input dynamically. Never stays the same. 71 * It is identified by TPM_MEASURED_BOOT_RUNTIME_DATA kconfig option and 72 measured into a different PCR (PCR_RUNTIME_DATA kconfig option, 3 by default) 73 in order to avoid PCR pre-calculation issues. 74 75 ![][srtm] 76 77 [srtm]: srtm.png 78 79 ### TPM eventlog 80 There are three supported formats of event logs: 81 * coreboot-specific format. 82 * [TPM1.2 Specification][TPM12] (chapter 11). 83 * [TPM2.0 Specification][TPM20] (chapter 10). 84 85 #### coreboot-specific format 86 ```c 87 struct tcpa_entry { 88 uint32_t pcr; /* PCR number. */ 89 char digest_type[10]; /* Hash algorithm name. */ 90 uint8_t digest[64]; /* Digest (tail can be unused). */ 91 uint32_t digest_length; /* Number of digest bytes used. */ 92 char name[50]; /* Description of what was hashed. */ 93 } __packed; 94 95 struct tcpa_table { 96 uint16_t max_entries; 97 uint16_t num_entries; 98 struct tcpa_entry entries[0]; 99 } __packed; 100 ``` 101 102 Single hash per PCR. No magic number or any other way of recognizing it. 103 Endianness isn't specified. 104 105 In principle can hold any hash with 512 bits or less. In practice, 106 SHA-1 (for TPM1) and SHA-256 (TPM2) are used. 107 108 Can be parsed by `cbmem`. 109 110 ##### Console dump format 111 The first column describes the PCR index used for measurement. 112 The second column is the hash of the raw data. The third column contains 113 the hash algorithm used in the operation. The last column provides 114 information about what is measured. First the namespace from where the data 115 came from, CBFS or FMAP, then the name used to look up the data 116 (region or file name). 117 118 #### TPM 1.2 format 119 Single hash per PCR (always SHA-1). First entry serves as a header, provides 120 ID and version. Always little endian. Event data describes what is being hashed 121 as a NUL-terminated string instead of providing the actual raw data. 122 123 Can be parsed by at least `cbmem` and Linux (exports in both text and binary 124 forms). 125 126 Packed data in vendor info section of the header: 127 ```c 128 uint8_t reserved; /* 0 */ 129 uint8_t version_major; /* 1 */ 130 uint8_t version_minor; /* 0 */ 131 uint32_t magic; /* 0x31544243 ("CBT1" in LE) */ 132 uint16_t max_entries; 133 uint16_t num_entries; 134 uint32_t entry_size; 135 ``` 136 All fields are little endian. 137 138 #### TPM 2.0 format 139 One or more hashes per PCR, but implementation is limited to single hash (SHA-1, 140 SHA-256, SHA-384 or SHA-512). First entry is overall compatible with TPM 1.2 and 141 serves as a header with ID, version and number of hashing algorithms used. 142 Always little endian. Event data describes what is being hashed as a 143 NUL-terminated string instead of providing the actual raw data. 144 145 By default SHA-1 is used for TPM1 and SHA-256 for TPM2. Other options are 146 selectable via kconfig menu. 147 148 Can be parsed by at least `cbmem`, Linux (exports only binary form) and 149 [Skiboot][skiboot]. 150 151 [skiboot]: https://github.com/open-power/skiboot/ 152 153 Packed data in vendor info section of the header: 154 ```c 155 uint8_t reserved; /* 0 */ 156 uint8_t version_major; /* 1 */ 157 uint8_t version_minor; /* 0 */ 158 uint32_t magic; /* 0x32544243 ("CBT2" in LE) */ 159 uint16_t max_entries; 160 uint16_t num_entries; 161 uint32_t entry_size; 162 ``` 163 All fields are little endian. 164 165 #### Example: 166 ```bash 167 PCR-2 e8f2b57c9ec5ea06d1bbd3240a753974d4c3e7c8cd305c20a8ea26eed906dc89 SHA256 [FMAP: COREBOOT CBFS: bootblock] 168 PCR-2 309a5fcb231d3a39127de2521792f332f9a69e05675ec52535d2dcded756dc19 SHA256 [FMAP: COREBOOT CBFS: fallback/verstage] 169 PCR-2 0fbba07a833d4dcfc7024eaf313661a0ba8f80a05c6d29b8801c612e10e60dee SHA256 [FMAP: RO_VPD] 170 PCR-2 431681113ed44cbf6f68a12c6e5687e901052f1d728a4777b2ad36e559962047 SHA256 [FMAP: GBB] 171 PCR-2 f47a8ec3e9aff2318d896942282ad4fe37d6391c82914f54a5da8a37de1300c6 SHA256 [FMAP: SI_DESC] 172 PCR-3 237f6f567f8597dbdff0a00690d34d21616af0dbe434b9a2d432b136c012765f SHA256 [FMAP: SI_ME] 173 PCR-2 7d2c7ac4888bfd75cd5f56e8d61f69595121183afc81556c876732fd3782c62f SHA256 [FMAP: SI_GBE] 174 PCR-0 62571891215b4efc1ceab744ce59dd0b66ea6f73 SHA1 [GBB flags] 175 PCR-1 a66c8c2cda246d332d0c2025b6266e1e23c89410051002f46bfad1c9265f43d0 SHA256 [GBB HWID] 176 PCR-2 ceca357524caf8fc73f5fa130f05a75293031962af884e18990d281eb259f5ff SHA256 [FMAP: FW_MAIN_B CBFS: fallback/romstage] 177 PCR-2 548a097604e0a975de76f98b04c7f0b0ddec03883dd69179e47a784704a1c571 SHA256 [FMAP: FW_MAIN_B CBFS: fspm.bin] 178 PCR-2 1e86b27008818244c221df2436b0113bd20a86ec6ec9d8259defe87f45d2f604 SHA256 [FMAP: FW_MAIN_B CBFS: spd2.bin] 179 PCR-2 05d78005fcfc9edd4ca5625f11b1f49991d17bdb7cee33b72e722bc785db55ae SHA256 [FMAP: FW_MAIN_B CBFS: fallback/postcar] 180 PCR-2 c13e95829af12a584046f1a6f3e1f6e4af691209324cfeeec573633399384141 SHA256 [FMAP: FW_MAIN_B CBFS: fallback/ramstage] 181 PCR-2 a6ec2761b597abd252dba2a7237140ef4a5a8e0d47cad8afb65fa16314413401 SHA256 [FMAP: FW_MAIN_B CBFS: cpu_microcode_blob.bin] 182 PCR-2 c81ffa40df0b6cd6cfde4f476d452a1f6f2217bc96a3b98a4fa4a037ee7039cf SHA256 [FMAP: FW_MAIN_B CBFS: fsps.bin] 183 PCR-2 4e95f57bbf3c6627eb1c72be9c48df3aaa8e6da4f5f63d85e554cf6803505609 SHA256 [FMAP: FW_MAIN_B CBFS: vbt.bin] 184 PCR-3 b7663f611ecf8637a59d72f623ae92a456c30377d4175e96021c85362f0323c8 SHA256 [FMAP: RW_NVRAM] 185 PCR-2 178561f046e2adbc621b12b47d65be82756128e2a1fe5116b53ef3637da700e8 SHA256 [FMAP: FW_MAIN_B CBFS: fallback/dsdt.aml] 186 PCR-2 091706f5fce3eb123dd9b96c15a9dcc459a694f5e5a86e7bf6064b819a8575c7 SHA256 [FMAP: FW_MAIN_B CBFS: fallback/payload] 187 ``` 188 189 #### Dump TPM eventlog in the OS: 190 ```bash 191 cbmem -L 192 ``` 193 194 #### Get CBFS file and print the hash 195 ```bash 196 cbfstool coreboot.rom extract -r COREBOOT -n fallback/romstage -U -f /dev/stdout | sha256sum 197 ``` 198 199 #### Get FMAP partition and print the hash 200 ```bash 201 cbfstool coreboot.rom read -n SI_ME -f /dev/stdout | sha256sum 202 ``` 203 204 ## DRTM 205 Certain hardware platforms, for example those with Intel TXT or AMD-V, provide 206 a mechanism to dynamically execute a CRTM, referred to as the "Dynamic 207 CRTM" (D-CRTM), at any point and repeatedly during a single power life-cycle of 208 a system. The trust chain constructed by this D-CRTM is referred to as the 209 "Dynamic Root of Trust for Measurement" (DRTM) trust chain. On platforms with 210 Intel TXT and AMD-V, the D-CRTM is the CPU itself, which is the reason for these 211 capabilities being referred to as having a "Root of Trust" (RoT) rooted in 212 hardware. 213 214 To provide as an authority assertion and for the DRTM trust chain attestations 215 to co-exist with the SRTM trust chain, the TPM provides localities, localities 216 1 - 4, which restrict access to a subset of the Platform Configuration 217 Registers (PCR), specifically the DRTM PCRs 17 - 22. The mechanism to assert 218 authority for access to these localities is platform specific, though the 219 intention was for it to be a hardware mechanism. On Intel x86 platforms this is 220 controlled through communication between the CPU and the PCH to determine if 221 the "Dynamic Launch" instruction, `GETSEC[SENTER]`, was executed and that the 222 CPU is in SMX mode. For AMD x86 platforms, this controlled with the APU with a 223 similar enforcement that the "Dynamic Launch" instruction, `SKINIT`, was 224 executed. 225 226 ## Platform Configuration Registers 227 PCRs are allocated as follows: 228 * PCRs 0-15 are SRTM PCRs. 229 - PCRs 0-7 are reserved for firmware usage. 230 * PCR 16 is the debug PCR. 231 * PCRs 17-22 are DRTM PCRs (PCR 22 is resettable from locality 1). 232 * PCR 23 is the application/user PCR and is resettable from locality 0. 233 234 coreboot uses 3 or 4 PCRs in order to store the measurements. PCRs 4-7 are left 235 empty. 236 237 The firmware computes the hash and passes it to TPM. 238 239 The bank used by the TPM depends on the selected eventlog format. CBFS hashes 240 use the same algorithm as the bank. However, GBB flags are always hashed by 241 SHA-1 and GBB HWID by SHA-256. This results in these hashes being truncated or 242 extended with zeroes in eventlog and on passing them to TPM. 243 244 ### If CHROMEOS kconfig option is set 245 vboot-specific (non-standard) PCR usage. 246 247 * PCR-0 - SHA1 of Google vboot GBB flags. 248 * PCR-1 - SHA256 of Google vboot GBB HWID. 249 * PCR-2 - Hash of Root of Trust for Measurement which includes all stages, 250 data and blobs. 251 * PCR-3 - Hash of runtime data like hwinfo.hex or MRC cache. 252 253 ### If CHROMEOS kconfig option is NOT set 254 See [TPM1.2 Specification][TPM12] (section 3.3.3) and 255 [TPM2.0 Specification][TPM20] (section 3.3.4) for PCR assignment information. 256 257 * PCR-0 - Unused. 258 * PCR-1 - SHA1 of Google vboot GBB flags, SHA256 of Google vboot GBB HWID. 259 * PCR-2 - Hash of Root of Trust for Measurement which includes all stages, 260 data and blobs. 261 * PCR-3 - Hash of runtime data like hwinfo.hex or MRC cache. 262 263 [TPM12]: https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementation_1-21_1_00.pdf 264 [TPM20]: https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf