For factory images, we want to be able to retain /var across reboots
without interacting with the TPM, and ultimately hold the test suite
in a pre-built image so we can avoid needing to wipe the entire
filesystem when switching modes.
BUG=chrome-os-partner:11392, chrome-os-partner:9419
TEST=link build, manual testing
Change-Id: I58aab24455670697e3df494632d5105dde75ee85
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27793
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Jon Salz <jsalz@chromium.org>
Samsung want to know what memory type on the device. So this CL adds a
new field ddr_type to crossystem utility in order to query this info.
It is only available on ARM platform so far.
BUG=chrome-os-partner:10857
TEST=Built and boot on Snow successfuly. On userspace, query the field via:
localhost ~ # crossystem ddr_type
ddr3
Change-Id: I01d1dec412fe4052e1ea6cfe2e53830da97a710b
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26411
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Simon Glass <sjg@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>
When doing a migration, try to guess at a smaller minimum size for the
initial filesystem so that systems with giant drives are not needlessly
penalized. Start with an even smaller initial filesystem size (16M).
Move debug time counters into the main .o file to avoid compiler
insanity when turning debug on and off.
BUG=chromium-os:22172
TEST=link build & boot, manual testing
Change-Id: I47c3ffb6e4cd88c4f0ead6fa21724704c7ed1630
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25638
Reviewed-by: Elly Jones <ellyjones@chromium.org>
Libraries go into $LDLIBS while linker flags go into $LDFLAGS.
Also make sure the utility subdir respects the env $LDFLAGS so that
we can do things like `make LDFLAGS=-static` and get static binaries.
BUG=None
TEST=`emerge vboot_reference` still works
TEST=`emerge-arm-generic vboot_reference` still works
Change-Id: I989a21bc559bc6d471bc33c057c708bda2eda67e
Reviewed-on: https://gerrit.chromium.org/gerrit/24728
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Rather than use the host's pkg-config, we want to use the target's.
This way we query the right .pc files.
BUG=None
TEST=`emerge vboot_reference` still works
TEST=`emerge-arm-generic vboot_reference` still works
Change-Id: I083a987ee6c23716f8d79eb14e7c38c12e18b8f8
Reviewed-on: https://gerrit.chromium.org/gerrit/24727
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@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>
When testing mount-encrypted, allow for the "MOUNT_ENCRYPTED_ROOT"
environment variable to define the root directory of all the internal
mount paths. By default, it remains "/". This changes all the formerly
static globals to dynamic.
Add support for environment variable "MOUNT_ENCRYPTED_FSCK" which
causes a fsck during the "umount" phase.
Improve loopback name handling and add debugging.
Rename "device" command to "info", add path details.
BUG=chromium-os:22172
TEST=x86-alex build, manual testing
Change-Id: Icf89a0a5283d38e098fa8e1d92a84b1cccacb4db
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23580
Reviewed-by: Will Drewry <wad@chromium.org>
When shutting the system down, mount-encrypted can be used to clean up
all its bind mounts and devices.
BUG=None
TEST=x86-alex build, manual testing
Change-Id: I025ce8c16c55f8556d7fff45eb6ac2b7a835101a
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/21913
Reviewed-by: Elly Jones <ellyjones@chromium.org>
Instead of taking images apart, signing bits, and reassembling them, this
just operates on the entire image at once. The image can be built without
regard to the signing process, and then the signing can be done in one step
afterwards.
BUG=chrome-os-partner:7459
TEST=none
No test at the moment, since we don't have the rest of the vboot stuff
working yet.
Change-Id: Icbde9cbb89d0ef85c0f6b8ac0637e0a51a894199
Reviewed-on: https://gerrit.chromium.org/gerrit/22116
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@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>
The default behavior of dump_kernel_config is changed from using
CROS_32BIT_ENTRY_ADDR to reading from kernel preamble. The main
motivation for this change is in preparation for ARM boards of which
kernel body load address cannot be CROS_32BIT_ENTRY_ADDR. Since we do
not want that all ARM calling sides of dump_kernel_config have to carry
the kloadaddr argument, it would be better to let dump_kernel_config
read this address from the kernel preamble by default.
BUG=chromium-os:28077
TEST=Run dump_kernel_config w/ and w/o this change
Change-Id: I5eddcc35e5970dfce02cc66208438c57351f1c81
Reviewed-on: https://gerrit.chromium.org/gerrit/19660
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Don Garrett <dgarrett@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>
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>
I've found a bug in vbutil_kernel, but the names of some of the internal
variables and struct members make it hard to follow (which is probably why
the bug exists). Before I fix it, I need to rename some things so we can see
what's wrong. This does that.
BUG=none (yet)
TEST=manual
make
make runtests
Change-Id: I8646c8acd33c58ccd52668943bcee4d0664716aa
Reviewed-on: https://gerrit.chromium.org/gerrit/18146
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7878
TEST=none
Well, you could test it like so:
flashrom -r /dev/null -i GBB:/tmp/GBB.bin
vbutil_what_keys GBB.bin
except that the current ChromeOS image doesn't include vbutil_what_keys. It
probably should, but that's a different CL.
Change-Id: I1e5b6cf30a81a46cb5c8c5d9b10f351dafa9ca87
Reviewed-on: https://gerrit.chromium.org/gerrit/15359
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7878
TEST=manual
Run vbutil_what_keys specifying either a BIOS or disk image signed with the
Stumpy MP keys. It should identify it as such. For example:
vbutil_what_keys chromeos_1675.0.0_stumpy_recovery_dev-channel_mp.bin
or
vbutil_what_keys bios.bin
The output should contain the strings "Stumpy MP" somewhere, if the image or
BIOS is signed with the Stumpy MP keys.
Change-Id: I575b7358ced4234c918eff40cdeb17fe06ab331c
Reviewed-on: https://gerrit.chromium.org/gerrit/15271
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
export them as a library to be used by post installer programs.
A matching change to vboot_reference-9999.ebuild is also required.
TEST=Built, verified library symbols with nm on x86-mario, amd64-generic.
BUG=chromium-os:25381
Change-Id: Icb23838a8cd804e0c66718c6d4d60f639ee6b72f
Reviewed-on: https://gerrit.chromium.org/gerrit/14770
Commit-Ready: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>
This implements a platform_family value within the crossystem utility,
as the platform (particularly for ARM) is not easily accessable elsewhere at
runtime.
For the ARM side this contains a table which is used to determine the platform
family based on the /proc/device-tree/compatible entry. Similarly on x86 the
table is used to check against PCI entries. Additional entries can be made
as new platform families emerge.
BUG=chromium-os:24669
TEST=Manual, verified that crossystem runs properly and returns a valid
platform_family value on various platforms (mario, alex, z600, x220, etc).
Change-Id: Id0e973902d27ead471c1243bcc6c3292acc8479d
Reviewed-on: https://gerrit.chromium.org/gerrit/13520
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@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>
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 new version adds a bunch more output, displays the TPM rollback version
values (if it can; Cr-48 doesn't export this info through crossystem), looks
for and validates all kernels on all devices, etc.
It also add some command-line arguments to use to examine files containing
BIOS, kernel, and disk images.
BUG=chromium-os:6676
TEST=manual
Boot, wait a minute or so, then log in and go to chrome://system
Click the Expand button for "verified boot". You should see a bunch of
useful text describing the firmware and kernel partitions.
I tried this on Cr-48, Stumpy, and Kaen.
Change-Id: I2d9aa0fcb0c12cf2b951ce9e2316b89532901125
Reviewed-on: https://gerrit.chromium.org/gerrit/11327
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
The rest of the chromiumos build system uses amd64 as the
architecture name for 64bit x86. This adds support for this
name to vbutil.
BUG=chromium-os:21284
TEST=vbutil --arch amd64 should not return unknown architecture
Change-Id: I37531591a7a31486f6447ae611d54569d1ea59d5
Reviewed-on: http://gerrit.chromium.org/gerrit/9959
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This changes the code accept x86.* as an alias for x86 architecture
since both x86 and x86_64 systems will handle things identically
BUG=chromium-os:20336
TEST=try to use update_kernel.sh on a system running an x86_64 kernel
Change-Id: Icf18925bdb8583cd53c6f6254c7493bdec540465
Reviewed-on: http://gerrit.chromium.org/gerrit/7873
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
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>
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 firmware image packing is now done by cros_bundle_firmware of
cros-devutils package, and we may retire pack_firmware_image.
BUG=none
TEST=emerge vboot_reference && [ ! -x /usr/bin/pack_firmware_image ]
Change-Id: I177508bf8aada822535fe61258cd1a0df52bfac6
Reviewed-on: http://gerrit.chromium.org/gerrit/5979
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Simon Glass <sjg@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>
