Make signing script re-sign Firmware AU payload, and update rootfs hash.

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.

[gauravsh, 2010-08-09 19:52:16]

Hung-Te for parts related to firmware autoupdate shellball 
(get_firmwarebin_from_shellball and resign_firmware_payload).

Will for the rest of the CL, especially recalculate_rootfs_hash.

[Hung-Te, 2010-08-10 03:07:05]

LGTM for shellball stuff

[gauravsh, 2010-08-16 18:45:00]

Paging Mr. Drewry. Friendly ping to ensure this hasn't fallen off your radar.

On Mon, Aug 9, 2010 at 8:07 PM,  <hungte@chromium.org> wrote:
> LGTM for shellball stuff
>
> http://codereview.chromium.org/3083025/show
>



-- 
-g

[Will Drewry, 2010-08-16 19:15:51]

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?)

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!)

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

[gauravsh, 2010-08-16 20:17:11]

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