This changes the signature of the function above so that it takes an additional
parameter that specifies which EC image vboot wants. This is better than making
U-Boot decide because U-Boot doesn't really keep track of which version it is
(it peeks at internal vboot data) and vboot does.
Also, some consts were removed from the image pointer pointer. The pointer
itself will be changed in the body of the function to tell vboot where the EC
has been loaded, and the contents of the buffer will be changed because U-Boot
will have to actually load the EC there.
BUG=chrome-os-partner:11148
TEST=Built vboot_reference, vboot_reference-firmware, chromeos-u-boot, and
chromeos-bootimage for Daisy and Link and saw them complete successfully with
and without the signature for U-Boot's version of this function being updated.
That works because the function isn't actually being used yet.
Change-Id: I2814c8210eb5b3d965bb8bbf23c0f283f9e44c90
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/27755
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Doesn't check the EC hash, but does jump to the correct image, for now
assuming the hash is good.
BUG=chrome-os-partner:11087
TEST=manual
- Power+refresh. System boots. EC is in RO (verify via 'ectool version')
- Create a BIOS signed *without* RO-normal.
- Power+refresh. System boots. EC ends up in A.
- ectool eventgetb. Event 0x2000 IS present, indicating EC has rebooted
- ectool eventclearb -1
- Power button to shut down, then power button to power back on.
- ectool eventgetb. Event 0x2000 is NOT present.
- crossystem recovery_request=123 && reboot. System reboots to recovery mode
and EC is in read-only (verify via EC console 'sysinfo')
- Power off and on. System boots. EC ends up in A again.
Change-Id: I39682d1bf7215c62a4b20613d029e78194b98826
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27574
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This gives the AP a chance to save NvStorage data first.
BUG=chrome-os-partner:11087
TEST=none yet; API isn't used yet
Change-Id: Iae7a24958fb076039795b92d9edb73d7e6ebfc6f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27525
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
On some systems, we require the VGA option ROM to be loaded before VbInit()
is called so we can display BIOS screens. If that hasn't happened, we
request it and reboot. Alternatively, if we don't need the option ROM
(normal mode) but we've already loaded it, we un-request it and reboot just
in case there are security vulnerabilities that might be exposed.
Not all systems need preloaded option ROMs. There is an additional input
flag that indicates whether this matters or not.
BUG=chrome-os-partner:8789
TEST=manual
Using keyboard-based dev-mode, switch between normal and dev mode and back.
It should work as expected.
Change-Id: Id1d662014d47ab648c73db4b1647520801f3a0b8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27125
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Nothing uses this yet; this is just a placeholder so the u-boot code
which sets the flag based on the FDT can go in.
BUG=chrome-os-partner:11087
TEST=if it builds it works
Change-Id: Ie04e3330bcda5c07d34a49391627316bd6232b5a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26874
Reviewed-by: Simon Glass <sjg@chromium.org>
This reverts commit 552ae43be0.
vboot should set up dev switch value in output flag of VbInit, instead
of exposing TPM getter to U-Boot.
BUG=chrome-os-partner:10947
TEST=build okay for Snow and Alex
Change-Id: Iee884dbf758fef0cacfed6bcbab373ab5ec5aa25
Reviewed-on: https://gerrit.chromium.org/gerrit/26556
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Firmware needs to be able to read virtual dev switch to set up device
tree blob which is passed to kernel and eventually read by crossystem.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chrome-os-partner:10947
TEST=With this change, U-Boot can read virtual dev switch.
Change-Id: Ifac2ec3d39b8e9c1100031fdef085c28bb8b37c7
Reviewed-on: https://gerrit.chromium.org/gerrit/26394
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
For fastest boot, we don't want to load the VGA Option ROM every time, but
only when we need it. Coreboot does that loading, but it can't always know
when it's needed (with keyboard-based dev-mode, coreboot can't tell if we're
in dev-mode or not). By the time we get to U-Boot, it's too late, so we need
two extra bits - one for vboot to tell coreboot to load the Option ROM and
another for coreboot to let vboot know it's been done.
BUG=chrome-os-partner:8789
TEST=manual
The only visible change is that crossystem will now have an "oprom_needed"
flag that can be set or cleared. Nothing actually pays attention to it yet,
though.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I521a6afdfb8ea17a8148b32eeb858844c981de9c
Reviewed-on: https://gerrit.chromium.org/gerrit/26272
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The VbExTrustEC function should be implemented in the BIOS, not the vboot
library. Also, weak references don't seem to work with our linker, so we'll
have to just require it always.
BUG=chrome-os-partner:9953
TEST=none
This must go in with a simultaneous change to U-Boot. The only test is
whether or not everything continues to compile.
Change-Id: I8a5ccb167eec3bcacbe892cf0bdcfe550a1f57d6
Reviewed-on: https://gerrit.chromium.org/gerrit/25557
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@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>
Since the "ownership" permament flag does not indicate if the TPM is
currently owned, the state of TPM Ownership must be read via a Capability
read of TPM_CAP_PROP_OWNER. This adds the "getownership" function.
BUG=chromium-os:22172
TEST=x86-alex build & manual test
Change-Id: I2fc9e933e891ba40190d008436b22496dced1c93
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24784
Reviewed-by: Will Drewry <wad@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>
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>
Omit this check because this check is not really necessary and it is
dealing more harms than goods to ARM boards.
While body load address is configurable, it is not quite possible to fix
all the build scripts and runtime scripts to carry this address; so in
reality all scripts use the default body load address.
The problem is, this default address is not friendly to ARM boards, and
it virtually makes this check fails on ARM boards.
BUG=chromium-os:28077
TEST=emerge-{daisy,x86-alex} vboot_reference
TEST=load_kernel_test -b 1 chromiumos_image.bin
TEST=run verified boot on Daisy
Change-Id: I1a1cc0aedf254e2a2b680046812ab7154f26dea7
Reviewed-on: https://gerrit.chromium.org/gerrit/20947
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
When the filesystem resizing process starts, it has the TPM open,
which means it can collide with tcsd after the main process exits.
Additionally, improve the debugging around TPM usage for better timing
analysis.
BUG=None
TEST=lumpy build & manual testing
Change-Id: I7028131015fb972c99e8b3d035f58346f08fbd06
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19535
Reviewed-by: Elly Jones <ellyjones@chromium.org>
Due to the limitation of servo that is unable to send U keys, dev USB boot
(triggered by Ctrl-U) is unable to be tested on FAFT. To solve it, firmware
should add an addition key combination to workaround it. Ctrl-Enter is the
one we picked.
BUG=chrome-os-partner:6759
TEST=compile the firmware and update it to Lumpy; during the dev screen,
press Ctrl-Enter to trigger USB boot.
Change-Id: I8215a241c3c07dc2f5e194c324459f106d007f47
Reviewed-on: https://gerrit.chromium.org/gerrit/15749
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Add ability to report a single PCR value via the tpmc utility. Using
/sys/devices/platform/tpm_tis/pcrs is too slow, since it reads all
PCRs before returning. Anything wanting to read PCR0 on a time-critical
path needs maximum speed.
BUG=chromium-os:22172
TEST=install and test x86-alex.
Change-Id: I2d450961d33fa314d54b909135a74aa756279ec6
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/13891
Reviewed-by: Luigi Semenzato <semenzato@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>
This adds a flag to the list of values returned by VbInit(). When
this flag is set, the BIOS may be asked to boot something other than
ChromeOS. If this requires some sort of special preparation, the BIOS
should do it.
BUG=chromium-os:22454
TEST=none
There is no test for this. It requires a change to the BIOS in order
to do anything differently, and we haven't yet decided whether the
BIOS should pay attention to it.
Change-Id: I5d89e7cd5b745ee74b8ace7fa613c0db03eebefd
Reviewed-on: https://gerrit.chromium.org/gerrit/11714
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
This enables us to support playing sounds in the background if the BIOS
allows it, so we don't have to block while beeping is happening. The new
declaration is:
VbError_t VbExBeep(uint32_t msec, uint32_t frequency);
If the audio codec can run in the background, then:
zero frequency means OFF, non-zero frequency means ON
zero msec means return immediately, non-zero msec means delay (and
then OFF if needed)
else:
non-zero msec and non-zero frequency means ON, delay, OFF, return
zero msec or zero frequency means do nothing and return immediately
The return value is used by the caller to determine the capabilities. The
implementation should always do the best it can if it cannot fully support
all features - for example, beeping at a fixed frequency if frequency
support is not available. At a minimum, it must delay for the specified
non-zero duration.
Currently, VbExBeep() is called only when displaying the dev-mode screen.
BUG=none
TEST=manual
I've tested on x86 and ARM, all timeouts and noises work as before.
Note that ARM and coreboot will require a corresponding change to their
VbExBeep() implementations, which will have to be handled with separate,
simultaneous CLs.
Change-Id: I3417ae4b99d9d0aee63f2ccaeed39b61d4333e5d
Reviewed-on: http://gerrit.chromium.org/gerrit/8234
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The --flags is added to get/set the "flags" field.
BUG=chrome-os-partner:2317
TEST=gbb_utiltiy --get --flags bios.bin # see flags as 0
gbb_utility --set --flags=0x3052 bios.bin
# for version error message for GBB1.0 files,
# and see flag value changed for GBB1.1+ files
gbb_utility --get --flags bios.bin
# flag as 0 for GBB1.0, 0x3052 for GBB1.1+
Change-Id: I7aab62c8fc32ea08b4822e496f543511ff5e5ebc
Reviewed-on: http://gerrit.chromium.org/gerrit/6721
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The vboot_api.h doesn't require the BIOS display the ASCII HWID in
a graphical form (ARM U-Boot doesn't know how), so we have to do it
ourselves. This change makes that possible.
Summary of changes:
* bmpblk_font.h defines a structure to map ASCII chars to BMPs
* bmpblk_font utility generates that font structure
* bmpblock format is bumped to version 1.2
- YAML file specifies font to use for $HWID
- make_default_yaml updated to emit the new format
- README updated to describe the difference
BUG=chromium-os:18631
TEST=manual
I've tested this on ARM, like so:
Inside the chroot, build a U-Boot that uses it:
emerge-tegra2_kaen vboot_reference vboot_reference-firmware
emerge-tegra2_kaen tegra-bct tegra2-public-firmware-fdts \
chromeos-u-boot chromeos-bootimage
Outside chroot, but in src/platform/vboot_reference:
make
<copy ./build/utility/bmpblk_font and ./build/utility/bmpblk_utility to
somewhere in your $PATH>
make clean
cd scripts/newbitmaps/fonts
bmpblk_font --outfile ../images/hwid_fonts.bin outdir/*
cd scripts/newbitmaps/images
make arm
cd out_arm
<edit DEFAULT.yaml>
bmpblk_utility -z 2 -c DEFAULT.yaml arm_bmpblock.bin
<use gbb_utility to replace the bitmaps in the U-Boot image, boot it>
The HWID string is displayed.
Change-Id: I782004a0f30c57fa1f3bb246e8c59a02c5e9f561
Reviewed-on: http://gerrit.chromium.org/gerrit/6544
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Also fixes returned value from Memset(). And SafeMemcmp() should
return 0 (equal) if comparing 0 bytes, to match the behavior of memcmp().
BUG=chromium-os:17564
TEST=make && make runtests
Change-Id: Id43e70eecf04815216e1fd952271af35e0a66396
Reviewed-on: http://gerrit.chromium.org/gerrit/6539
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
bmpblk_utility correctly supports this field, which can be used by the
factory process to map the localization to the correct locale. We forgot to
put the entries in the DEFAULT.yaml file. This change corrects that for
future releases.
BUG=none
TEST=none
Change-Id: Iea65d7439e6ef8cc8730ec1b862abba87041d93f
Reviewed-on: http://gerrit.chromium.org/gerrit/6424
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
The vboot library needs to decompress the images so that it can handle those
that are special cases (like rendering the HWID). This means that 1) it
needs access to the BIOS' native decompression routine, and 2) that
VbExDisplayImage() only needs to handle the uncompressed native-format image
and doesn't need to know about how the image is packed in the GBB.
BUG=chromium-os:19134
TEST=manual
This requires a change to vboot_api.h, which requires a (simultaneous)
matching change to the BIOS, at least for U-Boot, which builds separately.
I've made that change and run the "vbexport_test display" command from the
modified U-Boot, but that also requires a change to the way U-Boot is built
so that I can get at the U-Boot commandline.
Change-Id: I449fb467cd3a68e742f27ec41b95d52685459d89
Reviewed-on: http://gerrit.chromium.org/gerrit/6129
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Still need to update gbb_utility and firmware to use the flags.
BUG=chrome-os-partner:2317
TEST=make && make runtests
Change-Id: I16c77a175c78efa3212a00bbf94d68384ef1829f
Reviewed-on: http://gerrit.chromium.org/gerrit/4817
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
This also fixes one place where TPM error codes were getting lost.
BUG=chromium-os:18132
TEST=make && make runtests
Change-Id: I83c74e1103805f166d1dc7448be7d67bd46d15b3
Reviewed-on: http://gerrit.chromium.org/gerrit/4659
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Try #2, now that ARM has the fix from http://gerrit.chromium.org/gerrit/4667
This cleans up the TPM calls inside vboot_reference.
* TPM calls share mode code between boot modes.
* Better handling for TPM_E_MUST_REBOOT, particularly in recovery mode.
* TAB screen shows current TPM versions.
No changes required to the wrapper API; these changes are internal to vboot.
BUG=chromium-os:18084
TEST=make && make runtests; built for both alex and tegra2-seaboard
Original-Change-Id: I2a52066f2889210af83409872b10f9d6380470af
(cherry picked from commit da55560cddcf7a1aa8a881cdf52792a21a01e766)
Change-Id: I120797145772116f09b8125b9e56fdbb11dc16b3
Reviewed-on: http://gerrit.chromium.org/gerrit/4671
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This cleans up the TPM calls inside vboot_reference.
* TPM calls share mode code between boot modes.
* Better handling for TPM_E_MUST_REBOOT, particularly in recovery mode.
* TAB screen shows current TPM versions.
No changes required to the wrapper API; these changes are internal to vboot.
BUG=chromium-os:18084
TEST=make && make runtests; built for both alex and tegra2-seaboard
Change-Id: I2a52066f2889210af83409872b10f9d6380470af
Reviewed-on: http://gerrit.chromium.org/gerrit/4611
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Add recovery reason for already in recovery and need to reboot to
recovery to let the TPM init.
Add vboot_struct fields.
Fix type for keyblock flags param to SetTPMBootModeState().
BUG=none
TEST=make && make runtests
Change-Id: I4035bdb377aaebaca03a43799be57977166da739
Reviewed-on: http://gerrit.chromium.org/gerrit/4599
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
The old (v2.0) parser is compatible with new (v2.1) structs. That is,
this won't break existing firmware or vbutil_firmware.
A new (v2.1) parser parsing an old (v2.0) struct will return 0 for the
flags.
This will be used to support the RO-normal code path in a subsequent CL.
BUG=chromium-os:17304
TEST=added unit tests; make && make runtests
Change-Id: I73bcd8acd3330b0d7d143061b5ef838e6d79cf1a
Reviewed-on: http://gerrit.chromium.org/gerrit/4030
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
