A shortcut and easier way to enable USB booting without always calling the huge
firmware updater.
BRANCH=none
BUG=none
TEST=./enable_dev_usb_boot # successfully set dev_usb_boot value.
Change-Id: I9ebb3ce79ef58bc0a32926866d5e1827a92b6e74
Reviewed-on: https://gerrit.chromium.org/gerrit/33046
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Block devices return a size of 0 when stat'ed.
In order to be able to verify directly a raw partition, let's add a
special case to query the block device size.
BUG=chromium-os:34176
TEST="vbutil_kernel --verify /dev/sda4 --verbose" shows the actual
content not an error message.
BRANCH=none
Change-Id: Ibecf0a88816abf97305f0f87c0131ba7b66e386c
Reviewed-on: https://gerrit.chromium.org/gerrit/32302
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Jon Salz <jsalz@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@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>
If the --signprivate_pem option is used to vbutil_keyblock and without
an external signer, we were passing the wrong name to PrivateKeyReadPem()
causing all such invocations to fail. This CL fixes the typo.
(This particular path isn't current being used.)
BUG=none
TEST=manually verified with --signprivatekey_pem but without --external_signer.
BRANCH=none
Change-Id: I56df76a965706f654df1de8ac6e42738c15284c7
Reviewed-on: https://gerrit.chromium.org/gerrit/31556
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
On very large HDDs, the sector count was wrapping around. Switch most
calculations to bytes using uint64_t, and use BLKGETSIZE64 for checking
the loopback device size.
BUG=chrome-os-partner:12705
TEST=parrot build, manual testing
STATUS=Fixed
Change-Id: I1f7aea81151ed5cc130b1f6a05fda83f7a85150f
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31073
Reviewed-by: Elly Jones <ellyjones@chromium.org>
BUG=none
BRANCH=none
TEST=manual
Use it to dump the FMAP from a firmware image:
dump_fmap -h /build/link/firmware/image-link.bin
Change-Id: I94fb9396ea886b072845fadef6ef1e1e2ff85a59
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30784
Reviewed-by: Randall Spangler <rspangler@chromium.org>
mkfs.ext4 does not use the resize= hint for calculating inode ratios.
This means very tiny initial filesystems will not get enough inodes
once it has been resized. This calculates the desired inode ratio based
on the expected final size of the filesystem.
BUG=chrome-os-partner:12678
TEST=lumpy build, manual testing
STATUS=Fixed
Change-Id: I216aaaa6e0ef50e82265ee46ecac5a65bb077387
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30579
Reviewed-by: Gaurav Shah <gauravsh@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
Libraries (-llzma, -lyaml) should be in end of dependency list, otherwise
linking in static mode (-static) would fail.
BUG=none
TEST=emerge vboot_reference
Change-Id: Idd072443d042edfb214f5a958abd064bc18573ed
Reviewed-on: https://gerrit.chromium.org/gerrit/29738
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
The encrypted partition has been plagued with TPM problems, which means
systems that have a wedged TPM, or interrupt the TPM Ownership, Lockbox
creation, etc, all fail to keep the encrypted partition across a reboot.
As a result, we're forced to write the encryption key to disk initially,
and then throw it away once the system key from NVRAM can be used to
encrypt it.
On most systems that have a sane unowned TPM, the key will only be on
disk until the first login finishes and Cryptohome can Finalize the
NVRAM area. For all the other systems, they will continue to run, but
with their encryption key effectively in the clear. Technically, this
is not a regression from R21, so at least we can move forward and work
to improve this in the future.
Some attempt is made to wipe out the key, but this is especially ugly for
SSDs, since doing a "shred" just means the blocks will get moved around.
When ext4 supports "secure delete", we can move to that instead.
BUG=chromium-os:32951
TEST=alex build, manual testing
Change-Id: I9b9a0190ea0f47a277a150eb0882e4a507ff2927
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29123
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
When factory install happens, mount-encrypted is running on a tmpfs,
which can be detected via a W_OK check on the root filesystem.
BUG=chrome-os-partner:12033
TEST=alex build, manual test
Change-Id: I7bf5eaa244a50dd2a0de51760c964e970fa8e3aa
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28960
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Force mode of created key file to 0600, and make sure there is enough
room in the decryption buffer for any possible change to the decryption
algo.
BUG=None
TEST=alex build, manual testing
Change-Id: I89dceec22683ff66b5e1f61a63f14a1db1c4e2ee
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28892
Reviewed-by: Elly Jones <ellyjones@chromium.org>
If the config file is specified in the parameter list but we aren't able
to open (or read) the file, vbutil_kernel should return an error instead
of crashing with a Segmentation Fault.
BUG=chromium-os:33087
TEST=manual
Invoke vbutil_kernel with a bogus path for the config file (--config).
Change-Id: I32dab7c381b9094f4015a554bc59989f1bb329ef
Signed-off-by: Lucian Cojocar <cojocar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28740
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a Cr48 was upgraded from pre-R12, it will lack an NVRAM lockbox area
with no way to create one (TPM password has been thrown away already).
Detect this case and allow fallback to the other system key methods. If
it is a Cr48 running a modern OOBE, treat it like any other device and
require a modern NVRAM lockbox area.
BUG=chromium-os:32766
TEST=mario build, verified OOBE doesn't repeat, simulated pre-R12 uses UUID.
Change-Id: I2acf7ad8c5d16b1f314ba16c673fa3979a40f3de
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28231
Reviewed-by: Elly Jones <ellyjones@chromium.org>
EC FMAP has changed its section names because B partition has been removed. The
signing tool should now use area names "FW_MAIN" and "VBLOCK".
BUG=chrome-os-partner:11360
TEST=emerge-link vboot_reference
Change-Id: I41ff17257b5e2c8a0f4adb11088e121f94e93923
Reviewed-on: https://gerrit.chromium.org/gerrit/27970
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
On kernels prior to 3.1, the "allow_discard" option does not exist.
Allow for this by attempting to set up the table twice if the
allow_discard attempt fails.
BUG=chrome-os-partner:11529
TEST=link build, boots 3.2 ok, falls back when option is invalid.
Change-Id: I904d3770543ebdeb0eace9ffa8e6c654cf97976d
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28024
Reviewed-by: Elly Jones <ellyjones@chromium.org>
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>
