Lines Matching full:must
38 <p>Note that if verification fails at any stage, the user must be visibly
94 must be used to verify the boot image.</p>
119 <p>Bootloader integrity must be verified using a hardware root of trust. For
120 verifying boot and recovery images, the bootloader must have a fixed OEM key
121 available to it. It must always attempt to verify the boot image using the OEM
124 <p>It must be possible for the user to flash alternative image verification keys
125 to the device, and the bootloader must try verification using these keys if
127 user-provided keystore must result in a notification to be shown, as described
154 <li> RED, indicating the device has failed verification. This must display a
158 <p>The recovery partition must also be verified and should be verified in the
170 above, a LOCKED device must boot into the GREEN state, YELLOW state, or RED
171 state during any attempted boot. It must not be possible to alter the user
176 its current chain of trust. In the image above, a VERIFIED device must boot
178 must not be possible to alter the user keystore in the VERIFIED state. It must
198 or the user-provided keystore at this point. However, signatures must also be
209 mounting additional partitions. Verification metadata must also be appended to the
219 <p>Most importantly, the bootloader must verify the integrity of the boot and/or
227 state transitions require a data wipe. Note the user must be asked for
301 <p>When altering partition contents, the bootloader must check the bits set by
334 <p>Users can flash their own verification keys to the device, which must be
340 keystore. It must not be possible to change the contents of the keystore unless
342 bootloader must sign it using the TEE and store the signed keystore. Before
343 using keys from the keystore, the bootloader must use the TEE to verify the
387 verification steps, it must pass the following information to the TEE Keymaster
412 system partition cannot be verified similarly to previous parts but must be
432 must be displayed to the user, similar to the warning the bootloader shows
447 changes, so any change to the system partition must result in the user being
448 notified, and no unverified data must leak to user space until a warning has
449 been shown. However, we must also assume most verification failures are
450 not the result of malicious behavior; so the user must also have an option to
454 it will send a <code>uevent</code> to notify user space of the error. This event must be
457 the persistent dm-verity state must be updated to set the mode flag to logging
458 mode, and the device must be rebooted. When the device restarts,
463 <p>In a verified device, the system partition must always be verified. But any
465 any read-only partition that contains executable code must be verified on a
468 <p>In order for a partition to be verified, signed verity metadata must be
472 mount the device, the user must be warned.</p>
511 4.1. The bootloader must ignore this field and must NOT use the key
512 specified in the certificate to verify the signature. Signatures must always be
571 in which case the appropriate type for <code>Key</code> must be used.</p>
575 <p>The location of the keystore is not specified here, but that location must be
578 <code>fastboot flash keystore <path></code>. Sufficient storage must be
