Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(484)

Issue 3083025: Make signing script re-sign Firmware AU payload, and update rootfs hash. (Closed)

Created:
10 years, 4 months ago by gauravsh
Modified:
9 years, 6 months ago
Reviewers:
Hung-Te, Will Drewry
CC:
chromium-os-reviews_chromium.org, Randall Spangler, gauravsh, Luigi Semenzato, Bill Richardson
Visibility:
Public.

Description

Make signing script re-sign Firmware AU payload, and update rootfs hash. The build signing script will now re-sign the chrome os AU payload in the image rootfs using the new keys. In addition, it will recalculate and update the RootFS hash (in the kernel partition) before re-signing the whole image using the new "official" keys. BUG=3496, 5264 TEST=manual >>>>>For testing rootfs hash updates 1) Ensure that image was build with the --enable_rootfs_verification flag 2) Mount the root file fs on the input image, and make a minor change to the root fs (e.g. adding a file) 3) Now boot from this image, drop into the shell and look for logs related to dm-bht in the dmesg output. 4) You should see dm-bht complaining about block hash mismatches $ dmesg | grep dm ..... <dm-bht errors>....... <errors of the form "dm-bht: Block hash match failed"> 4) Now re-sign the modified image using the sign_official_build script. This will re-calculate and update the rootfs hash. 5) Boot from the re-signed image. Look at dmesg output. 6) You should see NO dm-bht errors. >>>>>For testing re-signing of firmware payload Grab the firmware autoupdate shellball from /usr/sbin/chromeos-firmwareupdate in the output image's rootfs partition (number 3). Extract the shellball (--sb_extract flag), and grab the firmware bios.bin from the temporary directory. $ unpack_firmwarefd.sh bios.bin $ vbutil_firmware --verify firmwareA.vblock --signpubkey KEY_DIR/firmware.vbpubk --fv firmwareA.data [Verification should succeed] $ gbb_utility -g bios.bin --rootkey=rootkey --recoverykey=recoverykey "rootkey" should be the same as KEY_DIR/root_key.vbpubk "recoverykey" should be the same as KEY_DIR/recovery_key.vbpubk KEY_DIR: Directory containing the keys used to generate the output image.

Patch Set 1 #

Patch Set 2 : cleanup #

Total comments: 3

Patch Set 3 : review fixes #

Unified diffs Side-by-side diffs Delta from patch set Stats (+207 lines, -17 lines) Patch
M scripts/image_signing/common.sh View 1 2 2 chunks +49 lines, -1 line 0 comments Download
M scripts/image_signing/resign_firmwarefd.sh View 2 chunks +5 lines, -3 lines 0 comments Download
M scripts/image_signing/resign_image.sh View 2 chunks +5 lines, -4 lines 0 comments Download
M scripts/image_signing/sign_official_build.sh View 1 2 4 chunks +148 lines, -9 lines 0 comments Download

Messages

Total messages: 5 (0 generated)
gauravsh
Hung-Te for parts related to firmware autoupdate shellball (get_firmwarebin_from_shellball and resign_firmware_payload). Will for the rest ...
10 years, 4 months ago (2010-08-09 19:52:16 UTC) #1
Hung-Te
LGTM for shellball stuff
10 years, 4 months ago (2010-08-10 03:07:05 UTC) #2
gauravsh
Paging Mr. Drewry. Friendly ping to ensure this hasn't fallen off your radar. On Mon, ...
10 years, 4 months ago (2010-08-16 18:45:00 UTC) #3
Will Drewry
Some nits, but LGTM. However, I'm a bit worried this is following in chromeos-installer's footsteps ...
10 years, 4 months ago (2010-08-16 19:15:51 UTC) #4
gauravsh
10 years, 4 months ago (2010-08-16 20:17:11 UTC) #5
On Mon, Aug 16, 2010 at 12:15 PM,  <wad@chromium.org> wrote:
> Some nits, but LGTM.
>
> However, I'm a bit worried this is following in chromeos-installer's
> footsteps
> which are treacherous at best.  What are the plans for testing that these
> functions work and are reliable? (shunit2? rewrite?)

Good question. I have been sticking to bash without shunit2 mostly to
keep the dependency level to a minimum since these will be used on our
signing servers. In the long-run (next few weeks) I will re-write them
in python, and most definitely at the first sign of them getting
unwieldy (I think these scripts are "done" in their present state).

>
> The same questions apply to the installer/postinst, but I'd hate to see this
> keep growing to the point where signing is a confusing quagmire too :/  (Any
> suggestions on what the tools could do to make it easier are welcome too!)

Vadim has been working on a testing framework for firmware and has a
nice little python class for manipulating final firmware images. We
should have something similar for final Chrome OS images. There are
many opportunities for reuse, not to mention they integrate nicely
with our testing frameworks.

To summarize, I completely understand and agree with your concerns
(and have seen first hand how ugly build_image has gotten). I think
moving to python is the right future direction.
>
> thanks!
> will
>
>
> http://codereview.chromium.org/3083025/diff/2001/3004
> File scripts/image_signing/sign_official_build.sh (right):
>
> http://codereview.chromium.org/3083025/diff/2001/3004#newcode65
> scripts/image_signing/sign_official_build.sh:65: local
> rootfs_sectors=$(echo ${dm_config} | cut -f2 -d' ')
> Would be worth checking if dm_config is empty for sanity's sake.  We
> need the same in setimage.
>
> http://codereview.chromium.org/3083025/diff/2001/3004#newcode90
> scripts/image_signing/sign_official_build.sh:90: dd if=${hash_image}
> of=${rootfs_img} bs=512 seek=${rootfs_sectors} conv=notrunc
> nit: > 80 chars
>
> http://codereview.chromium.org/3083025/diff/2001/3004#newcode152
> scripts/image_signing/sign_official_build.sh:152: tar zcf - -C
> ${shellball_dir} . | uuencode firmware_package.tgz > ${new_fwblob}
> nit: > 80 chars
>
> http://codereview.chromium.org/3083025/show
>



-- 
-g

Powered by Google App Engine
This is Rietveld 408576698