From e43f74ac0bfe2f137981bf196ae0bca387ba7860 Mon Sep 17 00:00:00 2001 From: Masahiro Yamada Date: Tue, 22 Aug 2017 15:19:20 +0900 Subject: [PATCH] doc: verified-boot: fix typos Signed-off-by: Masahiro Yamada --- doc/uImage.FIT/signature.txt | 10 +++++----- doc/uImage.FIT/verified-boot.txt | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index 7cdb7bf..a57cdab 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -81,7 +81,7 @@ $ openssl rsa -in keys/dev.key -pubout Device Tree Bindings -------------------- The following properties are required in the FIT's signature node(s) to -allow thes signer to operate. These should be added to the .its file. +allow the signer to operate. These should be added to the .its file. Signature nodes sit at the same level as hash nodes and are called signature@1, signature@2, etc. @@ -150,7 +150,7 @@ all available signing keys until one matches. - required: If present this indicates that the key must be verified for the image / configuration to be considered valid. Only required keys are normally verified by the FIT image booting algorithm. Valid values are -"image" to force verification of all images, and "conf" to force verfication +"image" to force verification of all images, and "conf" to force verification of the selected configuration (which then relies on hashes in the images to verify those). @@ -242,7 +242,7 @@ configuration 3 with kernel 1 and fdt 2: With signed images, nothing protects against this. Whether it gains an advantage for the attacker is debatable, but it is not secure. -To solved this problem, we support signed configurations. In this case it +To solve this problem, we support signed configurations. In this case it is the configurations that are signed, not the image. Each image has its own hash, and we include the hash in the configuration signature. @@ -327,7 +327,7 @@ Enabling FIT Verification In addition to the options to enable FIT itself, the following CONFIGs must be enabled: -CONFIG_FIT_SIGNATURE - enable signing and verfication in FITs +CONFIG_FIT_SIGNATURE - enable signing and verification in FITs CONFIG_RSA - enable RSA algorithm for signing WARNING: When relying on signed FIT images with required signature check @@ -336,7 +336,7 @@ CONFIG_IMAGE_FORMAT_LEGACY Testing ------- -An easy way to test signing and verfication is to use the test script +An easy way to test signing and verification is to use the test script provided in test/vboot/vboot_test.sh. This uses sandbox (a special version of U-Boot which runs under Linux) to show the operation of a 'bootm' command loading and verifying images. diff --git a/doc/uImage.FIT/verified-boot.txt b/doc/uImage.FIT/verified-boot.txt index e639e7a..41c9fa9 100644 --- a/doc/uImage.FIT/verified-boot.txt +++ b/doc/uImage.FIT/verified-boot.txt @@ -93,7 +93,7 @@ include hashes to verify images, so it is relatively straightforward to add signatures as well. The public key can be stored in U-Boot's CONFIG_OF_CONTROL device tree in -a standard place. Then when a FIT it loaded it can be verified using that +a standard place. Then when a FIT is loaded it can be verified using that public key. Multiple keys and multiple signatures are supported. See signature.txt for more information.