Add an option into firmware updater to show the hash of recovery key and root key in each keysets |
||||||
Issue descriptionIf one firmware supports to multiple models then there would be a set of keys for each models in firmware updater. When updating process, the right key set will be updated into FW. Regarding HWID database, one item would be hash of root and recovery key. But it is not easy to get values. For developers of CL, they usually did the real update of FW into the device then calling probe utility to grab these information. For reviewers, either need to verify it by the same procedure in the device or need to extract FW updater then calling gbb_utility (get recovery key) and vbutil_key to get values. We can simplify these procedures by adding an option into firmware updater with a arg about model name / keyid then hash of recovery and right root key will be generated. At least it can benefit reviewer's effort. And potentially reduce developer of CL's effort (no necessary to do real updating then probing).
,
Sep 20 2017
,
Sep 20 2017
Context: https://chromium-review.googlesource.com/c/chromiumos/platform/firmware/+/660402 In this CL, I added support to extract a model specific image with the keyblocks included. You can then run futility show over that image and will see the hashes needed. Is this sufficient?
,
Sep 20 2017
re#3, Yes, I noticed this change and thanks for the information here. I am just thinking that maybe hash of recovery key and all root keys of models could be dumped. The use case leveraged it would be "HWID database builder" can update these information into different models by this new option instead of probing from a device. Because we don't know exactly that this device is the correct one or not. For example, partner had update model A's HWID from model B's device.
,
Sep 20 2017
it seems like the scope of firmware-updater is expanding into a factory utility tool, which seems potentially off a simple wrapper around the current script and futility will achieve this, but it seems more like a factory specific script than a function of running firmware updater
,
Sep 21 2017
re#5 On the other hand, to shown the information inside the chromeos-firmwareupdate would be the reasonable task handled by this updater itself in my view. Just like option -V.
,
Sep 21 2017
in the -V case, it's the master of that data (it's stored in the VERSION file in the shellball) in the key hash case, futility already supports this. futility is not part of the shellball though. it seems like an unnecessary coupling for the what the firmware updater is really designed to support
,
Sep 21 2017
If we did this I suggest it should happen in the signer. We could split the VERSION file into a lot of little VERSION files in each model subdir. Then the signer can append the key information to the model VERSION file when it finishes. Then we would need to update the pack_stub to print out all the VERSION files.
,
Sep 21 2017
agreed ... that would be more appropriate but still this case is easily handled with the current tooling available
,
Sep 21 2017
re#8 It sounds reasonable to me as well. One benefit I can imagine is that the key version can also be added into VERSION (ex: premp_key_v2 or mp_key_v3). By the way, to record my WIP currently in firmware updater first - https://chromium-review.googlesource.com/c/chromiumos/platform/firmware/+/676515
,
Sep 21 2017
> key version can also be added into VERSION (ex: premp_key_v2 or mp_key_v3). s/can also/might also/
,
Sep 21 2017
I had wanted to do something related as a little side project, just didn't get around to implementing it. There's the actually useful "vbutil_what_keys" script that unfortunately has not been maintained (since it currently is a manual process to add new keys). I had exchanged some ideas with Mike a while back to write a script for him that would dump out all the hashes of signing keys and that he could run automatically on the signer, then this little helper would always be up-to-date. Adding a new option also works.
,
Sep 27 2017
re#8 Hi sjg@ and shapiroc@, Could you point me a start point to study so I can implement your idea in signer side? Thanks.
,
Sep 27 2017
,
Jan 10 2018
I am not actively working on this so unassign myself first.
,
Jan 15 2018
Start to work
,
Jan 16 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/e0b3841863281a3fc3b188bfbab55d401fabdc73 commit e0b3841863281a3fc3b188bfbab55d401fabdc73 Author: Marco Chen <marcochen@chromium.org> Date: Tue Jan 16 12:08:26 2018 image_signing: Add sha1sum of keys in keyset to VERSION.signer. To record sha1sum of keys in keyset can help loem or unibuild projects to verify 1. whether rekey process is performed correctly during the factory build. 2. whether HWID database is updated correctly. BUG= chromium:763328 TEST=1) modify loem.ini to match what coral is. 2) ~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh recovery ./chromeos_10308.0.0_coral_recovery_dev-channel_mp-v4.bin ./src/platform/vboot_reference/tests/loemkeys ./output.bin 3) verify output file - VERSION.signer. BRANCH=none Change-Id: I80deadb04d9dc0eb66fc5ac45dce84e6f41f1a16 Signed-off-by: Marco Chen <marcochen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/866522 Reviewed-by: Simon Glass <sjg@chromium.org> [modify] https://crrev.com/e0b3841863281a3fc3b188bfbab55d401fabdc73/scripts/image_signing/sign_official_build.sh
,
Jan 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/bbd33ef5c3cc52d4fd52cd6cd7f30ff6f8588aa2 commit bbd33ef5c3cc52d4fd52cd6cd7f30ff6f8588aa2 Author: Marco Chen <marcochen@chromium.org> Date: Mon Jan 22 19:14:07 2018 image_signing: Add sha1sum of keys in keyset to VERSION.signer. To record sha1sum of keys in keyset can help loem or unibuild projects to verify 1. whether rekey process is performed correctly during the factory build. 2. whether HWID database is updated correctly. BUG= chromium:763328 TEST=1) modify loem.ini to match what coral is. 2) ~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh recovery ./chromeos_10308.0.0_coral_recovery_dev-channel_mp-v4.bin ./src/platform/vboot_reference/tests/loemkeys ./output.bin 3) verify output file - VERSION.signer. BRANCH=none Change-Id: I80deadb04d9dc0eb66fc5ac45dce84e6f41f1a16 Signed-off-by: Marco Chen <marcochen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/866522 Reviewed-by: Simon Glass <sjg@chromium.org> (cherry picked from commit e0b3841863281a3fc3b188bfbab55d401fabdc73) Reviewed-on: https://chromium-review.googlesource.com/879244 Reviewed-by: Shelley Chen <shchen@chromium.org> Commit-Queue: Shelley Chen <shchen@chromium.org> Tested-by: Shelley Chen <shchen@chromium.org> [modify] https://crrev.com/bbd33ef5c3cc52d4fd52cd6cd7f30ff6f8588aa2/scripts/image_signing/sign_official_build.sh
,
Jan 24 2018
The following revision refers to this bug: https://chrome-internal.googlesource.com/chromeos/cros-signing/+/2f80427a43eec19d43da8edbae9907983f892498 commit 2f80427a43eec19d43da8edbae9907983f892498 Author: Marco Chen <marcochen@chromium.org> Date: Wed Jan 24 09:11:54 2018
,
Jan 29 2018
,
May 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/f709cd2bee1cdff49ece4c7c3ab23950e4dd9d30 commit f709cd2bee1cdff49ece4c7c3ab23950e4dd9d30 Author: Marco Chen <marcochen@chromium.org> Date: Wed May 09 21:40:26 2018 image_signing: Add sha1sum of a key without loem keyset to VERSION.signer. CL:866522 supported the case of loem and uni-build projects but not for the project with one key only. After this CL, `gooftool finalize` can refer to VERSION.signer in order to get correct firmware key hash from recovery image. As the result, firmware_keys field can be removed from HWID database. BUG= chromium:763328 TEST=1) ~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh recovery ./chromeos_10644.0.0_soraka_recovery_dev-channel_mp.bin ./src/platform/vboot_reference/tests/devkeys ./output.bin 2) verify output file - VERSION.signer. BRANCH=None Change-Id: I376cd7038c0fe1d5cc71cb39cbabeb5e79994407 Reviewed-on: https://chromium-review.googlesource.com/1051429 Commit-Ready: Marco Chen <marcochen@chromium.org> Tested-by: Marco Chen <marcochen@chromium.org> Reviewed-by: Marco Chen <marcochen@chromium.org> Reviewed-by: C Shapiro <shapiroc@google.com> [modify] https://crrev.com/f709cd2bee1cdff49ece4c7c3ab23950e4dd9d30/scripts/image_signing/sign_official_build.sh
,
May 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/c694502ae336b9f89f6b73b2d67548a7385d74ef commit c694502ae336b9f89f6b73b2d67548a7385d74ef Author: Marco Chen <marcochen@chromium.org> Date: Mon May 14 16:14:47 2018 image_signing: Add sha1sum of the recovery key to VERSION.signer. firmware_keys field in the HWID database also contains hash of recovery key so need this information as well in order to deprecate firmware_keys field. BUG= chromium:763328 TEST=1) ~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh recovery ./chromeos_10644.0.0_soraka_recovery_dev-channel_mp.bin ./src/platform/vboot_reference/tests/devkeys ./output.bin 2) verify output file - VERSION.signer. BRANCH=None Change-Id: If2be93723e95d46fc0546239695be27c3229275c Reviewed-on: https://chromium-review.googlesource.com/1053334 Commit-Ready: Marco Chen <marcochen@chromium.org> Tested-by: Marco Chen <marcochen@chromium.org> Reviewed-by: Wei-Han Chen <stimim@chromium.org> Reviewed-by: C Shapiro <shapiroc@google.com> [modify] https://crrev.com/c694502ae336b9f89f6b73b2d67548a7385d74ef/scripts/image_signing/sign_official_build.sh |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by marcochen@chromium.org
, Sep 14 2017