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>
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>
The current bmpblock_utility doesn't preserve the order of images as
specified in the config yaml file. This doesn't affect the
functioning of the firmware, but does break this overly-restrictive
test.
Filed crosbug.com/19541 to fix this after Bill's current refactoring.
BUG=chromium-os:19541
TEST=make && make runtests
Change-Id: I03fe817bd191fec5f65aad37561a3224b6a2b1e6
Reviewed-on: http://gerrit.chromium.org/gerrit/6512
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>
BUG=chromium-os:17433
TEST=make && make runtests. Additional manual tests:
0. Insert a valid dev-signed USB key.
1. Boot with dev switch off.
`crossystem dev_boot_usb` should print 0.
2. Flip dev switch on.
`crossystem dev_boot_usb` should print 0.
Ctrl+U at dev screen should beep, but not boot USB.
3. Type `crossystem dev_boot_usb=1`. Should succeed.
`crossystem dev_boot_usb` should print 1.
4. Reboot system.
At the dev mode warning, press Ctrl+U
System should boot from USB key
`crossystem dev_boot_usb` should print 0.
5. Flip dev switch off.
`crossystem dev_boot_usb` should print 0.
6. Flip dev switch on.
`crossystem dev_boot_usb` should print 0.
Note that this does not apply to Cr-48, Alex, or ZGB.
Change-Id: Idf85fdd642f38f531c89e5fa5b1679e84936d4da
Reviewed-on: http://gerrit.chromium.org/gerrit/3875
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
