There are several places where the same recovery_reason was used to report
slightly different points of failure. Let's create some new codes instead.
Remember that recovery mode is handled by RO firmware, so if an updated RW
firmware uses one of the new error codes, pressing TAB at the recovery
screen will say "We have no idea what this means". That's not a bug. This CL
deprecates the original codes, so the fact that the RO firmware doesn't
recognize it just means it's a new code reported by a new RW BIOS.
BUG=chromium-os:36562
TEST=manual
BRANCH=parrot
Run
make && make runtests
It should pass. You can test some of the error cases on actual hardware by
using
crossystem recovery_reason=86
reboot
and pressing TAB at the recovery screen. For that example you should see the
message
recovery_reason: 0x56 TPM lock error in rewritable firmare
Change-Id: I123c781e6c6f6fe0284c4fd49f5f5a855eece7df
Reviewed-on: https://gerrit.chromium.org/gerrit/38652
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the cgpt utility complaints about parameter errors, it is
impossible to tell what exactly went wrong. This change consolidates
error definitions and adds a function to convert integer error values
into text messages.
BRANCH=none
BUG=none
TEST=manual
. emerge-link vbooot_reference
. copy generated `cgpt' to a Link device
. run command with wrong arguments with respect to the existing GPT:
localhost var # ./cgpt add -i 3 -b 3985408 -s 1757184 -t rootfs -l ROOT-A /dev/sda
ERROR: cgpt add: Starting LBA overlaps
ERROR: cgpt add: -i 3 -l ROOT-A -b 3985408 -s 1757184 -t 3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC
. on the host, in the chroot in src/platform/vboot_reference run
$ make && make runtests
observe all tests succeed
Change-Id: Ibd23ca0430a875f70524adc99e0509b26ae699b2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34003
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This option is disabled per default and can be enabled with
crossystem dev_boot_legacy=1
or by setting the GBB flag
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080
BUG=chrome-os-partner:6108
TEST=crossystem dev_boot_legacy=1
boot to dev mode screen, press CTRL-L, see SeaBIOS start
(other CLs needed)
BRANCH=link
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Change-Id: I593d2be7cff5ca07b8d08012c4514a172bd75a38
Reviewed-on: https://gerrit.chromium.org/gerrit/31265
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
%L is, in some standard libraries like U-Boot's, a synonym for %ll which is
for long long integers, required by the C99 standard to be at least 64 bits.
For practical purposes that basically means %ll should be used with 64 bit
values. Since %L seems to be non-standard and, at least in U-Boot's case, %ll
is recognized in the same way, %ll seems preferable.
BUG=chrome-os-partner:8339
TEST=Booted ChromeOS using depthcharge and U-Boot. Booted with
depthcharge/libpayload which does not support %L and saw a number where %L had
been printed.
BRANCH=None
Change-Id: Id51fb5c9295e0dd65b42a5c0738eb34c8210a2b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/32660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We need to know not only whether the HW WP pin is asserted, but whether the
flash chip has configured its software protection registers to actually
protect anything. This flag can be used to indicate that.
BUG=chrome-os-partner:13265
BRANCH=link
TEST=none
This just adds the flag. Nothing actually sets the flag yet, so there's
nothing to test.
Change-Id: Icba9945fb56eb3a4681486c630cbbdc9232485ef
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31642
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Modifying the size of an existing partition without modifying the start as
well assumed the start was at block 0. Sometimes it was caught, often it
wasn't.
Fix the error, add a test to catch the problem.
BUG=chrome-os-partner:13090
BRANCH=all
TEST=manual
make && make runtests
Change-Id: I4f5a5031a90a3e78d886ed3573f61305316a3f1f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31418
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I'm about to add a new test to fix some borkage with cgpt. First step is to
clean up the script a little bit.
BUG=none (yet)
BRANCH=all
TEST=manual
make && make runtests
Change-Id: I2311b5eb20aff80c4a0435cf1d10331c679af3c0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31379
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When we changed the bmpblk version from 1.2 to 2.0, the tests weren't
updated.
BUG=chrome-os-partner:11078
BRANCH=all
TEST=manual
make && make runtests
Change-Id: I244a9aeeb34be912fe6058687394c37d0e474890
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31377
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds two new flags to crossystem:
clear_tpm_owner_request
clear_tpm_owner_done
The first one requests that the firmware clear the TPM owner on the
next boot. When the firmware does this, it will set
clear_tpm_owner_request=0, and set clear_tpm_owner_done=1. The OS can
use the done-flag as a hint that trusted things guarded by the TPM are
no longer trustable.
BUG=chromium-os:31974
TEST=manual
crossystem
// both flags initially 0
crossystem clear_tpm_owner_request=1
crossystem clear_tpm_owner_done=1
// request=1, done=0; done can be cleared but not set by crossystem
reboot
tpmc getownership
// owned=no
crossystem
// request=0, done=1
crossystem clear_tpm_owner_done=0
crossystem
// both flags 0 again
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I49f83f3c39c3efc3945116c51a241d255c2e42cd
Reviewed-on: https://gerrit.chromium.org/gerrit/25646
Since /var has moved to the encrypted partition, use the real system
mount location for /var so it doesn't matter which filesystem it is bind
mounted to.
BUG=None
TEST=link build, tests pass
Change-Id: I2831949f3c1cf71765d97720b5ca64b869ec1fa4
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28033
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
And enable dev_boot_usb by default.
And disable rollback checks.
The first flag is necessary for factory to build with keyboard
controlled dev mode. The other flags are really handy for development
on systems where you've defeated firmware WP and are installing custom
firmware.
BUG=chromium-os:31844
TEST=make && make runtests
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I9d837fee676cb0186ea98f13005ad60a9ab86393
Reviewed-on: https://gerrit.chromium.org/gerrit/25265
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Confirmed via codesearch that these fields are not used outside of
vboot_reference itself, and the only use inside vboot_reference is one
test which checked that the test error generation itself worked.
BUG=chromium-os:31668
TEST=make && make runtests
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Ic393e126ca2853f7aaff19ffd6fcdbdb1c47689f
Reviewed-on: https://gerrit.chromium.org/gerrit/24895
Reviewed-by: Simon Glass <sjg@chromium.org>
BUG=chrome-os-partner:9706
TEST=manual
Currently, Link is the only platform that enables this feature.
To enter dev-mode:
Boot into recovery mode using the magic key chord. At the Insert screen,
press Ctrl-D. You'll be asked if you want to enter developer mode. If you
then press ENTER, it will reboot with dev-mode enabled. If you press SPACE
or ESC, it will return to the Insert screen.
If you enter recovery mode through any other means, or if dev-mode is
already enabled, pressing Ctrl-D at the Insert screen will have no effect.
To return to normal mode:
Reboot. At the Dev screen, press ENTER or SPACE. It will reboot to
recovery mode and ask you if you want to return to normal mode. If you
press ESC or power off, you'll still be in dev-mode. Press ENTER or SPACE,
and it will reboot into normal mode (of course, if you've messed up your
images while in dev-mode, you'll just come right back to recovery mode
again).
You can also request a direct return to normal mode by running
crossystem disable_dev_request=1
and rebooting.
Change-Id: I435905855a6c39932ee466cc046bdc4c4c860f98
Reviewed-on: https://gerrit.chromium.org/gerrit/24160
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
When linking tools that need OpenSSL functions on the target, the
resolution of SHA* functions was being redirected to the firmware
cryptolib instead of the OpenSSL implementations, which was causing
OpenSSL calls to crash. This renames the internal implementations
to avoid the collision.
BUG=None
TEST=make runtests passes, mount-encrypted runs on target again.
Change-Id: Ica4fb04faf203ae3b4118c540f18d40239753810
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23305
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If VbInit() is instructed to look at a virtual dev-mode switch, then it will
use value contained in the TPM's firmware space instead of a hardware GPIO
to determine if developer mode is enabled.
This change just makes it look. It doesn't provide a way to actually set
the value in the TPM. VbInit() isn't being told to look yet, either. Those
changes are coming.
BUG=chrome-os-partner:9706
TEST=none
The usual sanity-check applies:
make
make runtests
But to actually test that this stuff is working IRL requires special tweaks
to other components and monitoring the serial debug output from both EC and
CPU. We'll save the hands-on tests for when it's all done.
Change-Id: Ie485ad2180224e192238bf2a5dbf95bbcb9130f9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23067
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9707
TEST=manual
make
make runtests
You can also test it by clearing the TPM, then manually looking at the TPM
regions. In dev-mode, clear the regions and you'll see something like this:
localhost ~ # tpmc read 1007 a
1 0 0 0 0 0 0 0 0 0
localhost ~ # tpmc read 1008 d
1 4c 57 52 47 0 0 0 0 0 0 0 0
localhost ~ #
Go back to normal mode and reboot, and you'll see something like this:
localhost ~ # tpmc read 1007 a
2 0 1 0 1 0 0 0 0 4f
localhost ~ # tpmc read 1008 d
2 4c 57 52 47 1 0 1 0 0 0 0 55
localhost ~ #
The important things are that the first number is now 2, instead of 1, and
the last number is not zero (it's a checksum, so it'll vary depending on the
other numbers, which will themselves vary according to the firmware and
kernel versions).
Change-Id: Ia4040311c2a4b2819792549b883377c8b6b89d48
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/22856
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This just adds the vbutil_ec tool (and a simple test of the library
functions related to it).
BUG=chrome-os-partner:7459, chromium-os:27142
TEST=manual
make
make runtests
Change-Id: I2a2c4e7cfb8ac6ce2229c5de4252a5cc89321fa5
Reviewed-on: https://gerrit.chromium.org/gerrit/21868
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chromium-os:12430
TEST=manual
Running "make; make runtests" in src/platform/vboot_refererence will test
this change. Tests for use on a Chromebook are described in the bug report,
but will require a USB or SD card that has a physical write-protect switch.
Change-Id: I16a67bad3b59bec0981f4064f51fb1a29da65a90
Reviewed-on: https://gerrit.chromium.org/gerrit/21474
Tested-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
This started out as a simple fix for a minor bug and turned into a nearly
complete rewrite. Now that it's done I'm not sure it really matters. This
version is a lot cleaner about handling command-line args, but isn't
otherwise noticeably better. Sigh.
BUG=none
TEST=manual
make
make runtests
Change-Id: I9c194e9c0e6418488635989ef666bc83c6e39816
Reviewed-on: https://gerrit.chromium.org/gerrit/18268
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We need all the libraries to come after the objects, not before, otherwise
static and --as-needed linking fails when the linker drops the libraries.
BUG=None
TEST=`emerge vboot_reference` still works
Change-Id: Id98571a90115ab5ace68a0c795de86d7fe78f133
Reviewed-on: https://gerrit.chromium.org/gerrit/18290
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
We need to use the .pc file to get the compiling/linking details,
so switch over to that.
While we're here, fix the hardcoded `ar` to use $(AR) from the env.
BUG=chromium-os:16623
TEST=`emerge-x86-alex vboot_reference` builds & links CgptManagerTests against newer libbase
Change-Id: I20865138fdfd1725415d737ad5fdbc4c134079a7
Reviewed-on: https://gerrit.chromium.org/gerrit/17533
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
This change prepares for modifying VbFirmwarePreambleHeader and
VbKernelPreambleHeader by adding a bunch of current-version data and tests
of that data. Once we change the structs, we'll still need to be sure that
we can still generate, sign, and verify things using the old-style structs
too so that we can release updates to existing devices.
If we changed the structs and then created the test data, we couldn't be
certain that we're still doing it right.
BUG=chromium-os:20124
TEST=manual
make
make runtests
Change-Id: I39310a0d853dbf63a8ca8ff9a0fb4440017c692a
Reviewed-on: https://gerrit.chromium.org/gerrit/17530
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The existing library had a bunch of dependencies which are too many to
build for the 32-bit platform. So this checkin prunes the dependency
list by building only things that are absolutely required for the
functionality used in 32-bit Post-Installer.
Made the use of libuuid restricted only to cgpt and unit tests so that
libcgpt-cc.a doesn't depend on it.
BUG=chromium-os:25374
TEST=Built 32-bit and 64-bit. Tested 32-bit post-install.
Change-Id: Idd0826fdf507a95728fee8adac9520e26f05d469
Reviewed-on: https://gerrit.chromium.org/gerrit/16433
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
CgptManager exposes the cgpt commands via a C++ library so that
the post-installer for 32- to 64-bit upgrade can link directly
against a library and thus avoid any shell dependency.
The default make target will not build libcgpt-cc.a since it
requires some dependencies that are available only in chroot.
A separate follow-up checkin to the vboot_reference
ebuild will enable emerging the libcgpt-cc.a by default.
BUG=chromium-os:25374
TEST=Tested with the new unit tests for CgptManager,
ran existing cgpt unit tests, as well as running the
cgpt commands manually. Built on both amd64 and x86.
Tested that vboot_reference is also buildable outside of chroot.
Tested that vboot_reference-firmware and vboot_reference-tests
also build fine with these changes.
CQ-DEPEND=I99f6c321e09c2425eaa8171d78685d2d731954c8
Change-Id: I59a896255b8ea2fc8b1b2150ae7c4ff9d0769699
Reviewed-on: https://gerrit.chromium.org/gerrit/15730
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
Previously, it was going to recovery only when no disks existed. That didn't
catch the case where disks exist but none of them are usable.
BUG=chrome-os-partner:7715
TEST=manual
I've added a test specifically for this, so just
make
make runtests
should verify it.
To test on actual hardware, find a disk or USB drive that has something
other than 512 bytes per LBA, and try it. It won't be bootable, but using it
shouldn't hang the system or cause weird behavior.
Once in recovery, press TAB, and you should see the reason code
VBNV_RECOVERY_RW_NO_DISK
Change-Id: I475ddd01e13fa806025a2107c260c030d098a17e
Reviewed-on: https://gerrit.chromium.org/gerrit/14816
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:7428
TEST=manual
Switch to dev-mode, turn it on, see how long it takes.
With gbb.flags == 1 (factory mode), it should take 2 seconds.
(You'll see a warning on the screen if gbb.flags is nonzero)
With gbb.flags == 0 (after factory install), it should take 30 seconds.
You should hear two beeps at 20 seconds.
Change-Id: I4f14128b87d3482e291b1b40a11a6d27c72c1ad1
Reviewed-on: https://gerrit.chromium.org/gerrit/14534
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
When you enter dev-mode,
Pressing Ctrl-U to boot from USB is DISABLED.
Booting any self-signed kernel from the SSD is ENABLED.
This replaces the "crossystem dev_boot_custom" argument with
"crossystem dev_boot_signed_only", which has the opposite polarity.
So if you want to dev-mode to only boot official kernels, you have to
explictly set it that way. If you leave dev-mode and then come back,
it will go back to the conditions shown above.
BUG=chrome-os-partner:5954
TEST=manual
Just run the factory flow. It was broken; this should fix it (except for any
workarounds that were added while it was broken; those may need to be
reverted).
Change-Id: I13e0edbc0e77c5d6ea609dabf771085006cd1805
Reviewed-on: https://gerrit.chromium.org/gerrit/11853
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
As shipped, H2C only loads the option ROM for the built-in video, and that
only when it needs display the BIOS warning screens.
By setting a flag in the GBB, you can allow all option ROMs to be loaded:
Note that we'll never enable this ourselves (and there's a factory test to
ensure that*) because it executes non-verified code. But if a customer wants
to void their warranty and set this flag in the read-only flash so they can
install and use other PCI devices, they should be able to do so.
BUG=chrome-os-partner:6148
TEST=none
The only way to test this is to use a BIOS that was compiled with serial
debugging enabled, so there's nothing for QA to do. If you have such a BIOS,
you can see the difference like so:
flashrom -r oldbios.bin
gbb_utility -s --flags=2 oldbios.bin newbios.bin
flashrom -w newbios.bin
<reboot>
When bit 1 of the GBB flags is 0, you'll see these lines in the serial
output:
LoadOpRomImage-->GetSystemConfigurationTable Status = Success
LoadOpRomImage-->GetH2cBootMode Status = Success
When bit 1 of the GBB flags is 1, you'll see these lines in the serial
output:
LoadOpRomImage-->GetSystemConfigurationTable Status = Success
LoadOpRomImage-->GetH2cBootMode Status = Success
LoadOpRomImage-->PCI OpRom on 1.0.0 is allowed!!!
This happens in any boot mode (normal, developer, recovery).
--
*The factory test for GBB zero flags is gft_clear_gbb_flags.sh, in
src/platform/factory_test_tools
Change-Id: I31a10cc9d562b4b83669ca8a114b60e87ae28b0a
Reviewed-on: https://gerrit.chromium.org/gerrit/11505
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Although we're now using a single unified BIOS, it is pretty nice to be able
to get a shell in developer mode while still using verified boot for the
kernel and filesystem. Alex & ZGB implemented this by requiring the dev-mode
user to install a special dev-mode BIOS. We don't do that, but we DO require
setting a special flag with "crossystem" to accomplish the same thing.
In order to allow booting a self-signed kernel, you must boot in developer
mode, open a shell, and run this:
crossystem dev_boot_custom=1
Special note to internal developers: If you're in the habit (as I am) of
booting directly from a USB stick in dev-mode, you'll have to run this:
crossystem dev_boot_custom=1 dev_boot_usb=1
Just using dev_boot_usb=1 is no longer enough, because the USB kernel is
signed using the recovery key and by pressing Ctrl-U, we validate it with
the kernel data key. That worked before this change because any self-signed
kernel was fine, and that's how the USB key was treated. Now it actually
requires a verified signature until you enable dev_boot_custom=1 also.
BUG=chrome-os-partner:5954
TEST=manual
Boot once in normal mode, which clears the special flags. Then switch to
developer mode. You should be able to boot and get a root shell.
Run
crossystem dev_boot_usb=1
Obtain a USB recovery image that's keyed differently. For example, if you're
testing with dev-keys, use a PVT-signed image or vice-versa.
Reboot into dev-mode with the USB recovery stick inserted. At the dev-mode
screen, press Ctrl-U. You should hear a single beep, but it should not boot.
Press Ctrl-D to boot from the hard drive, log in to a shell and run
crossystem dev_boot_custom=1
Repeat the previous test. This time when you press Ctrl-U, it should boot
the recovery image. Turn the system off before it does anything.
That's it.
Change-Id: I1811ee9a188974b3f94c83c52b00b60028b86c69
Reviewed-on: https://gerrit.chromium.org/gerrit/11442
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Yaay, LoadFirmware() finally has unit tests!
Fix minor memory leak in LoadFirmware().
BUG=chromium-os:17564
TEST=make && make runtests
Change-Id: I7eabc14484271f488b77f286e846781ccc22b8f2
(cherry picked from commit 2b7c5635d7069c55a1d96d11b99d02291b7e308b)
Reviewed-on: http://gerrit.chromium.org/gerrit/7052
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
