chromeos-tpm-recovery has not been used for anything in forever (see
CL:238236), but it is still installed on every image. Resetting the TPM
(e.g. to resolve rollback issues when reflashing an MP-signed device to
dev firmware) is a common request by developers, and I get tired of
always digging out the required tpmc commands manually again. Let's
repurpose this script as a simple one-shot tool for developers to reset
their TPM, so the next time someone asks we can just tell them 'boot a
test image in recovery mode and run chromeos-tpm-recovery'.
BRANCH=none
BUG=chromium:419942
TEST=Ran on a Jerry, confirmed that TPM spaces were reset.
Change-Id: Ia95246cfed3dc9b0c6fdb0481218e3ae14d8318a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271512
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
This is done to break a circular DEPENDency as we want to
send UMA stats from tcsd. Without this, metrics depends on
vboot_reference which depends on trousers which depends on
metrics. Technically the vboot_reference dependency on trousers
is header-file only, but we can't cope with that.
BUG=chromium:481552
TEST=compiled with emerge-<something> vboot_reference
BRANCH=none
Change-Id: Iea5c0c39bb70977c9d375e63ea607687debe9f9f
Reviewed-on: https://chromium-review.googlesource.com/267744
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
AFAICT this property is not really used by anything. All factory
scripts that need detailed memory info get it from mosys. Most
platforms display "unknown" which causes confusion whenever
a bug is filed to support crossystem on a new platform.
BUG=chrome-os-partner:36176
BRANCH=none
TEST=no more "unknown" ddr-type shown in crossystem output on speedy
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I97e66c362e9d88c843128a411512d5a76ac5f87d
Reviewed-on: https://chromium-review.googlesource.com/263982
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
vboot currently uses the |SHA256_CTX| name, which is claimed by OpenSSL.
To work around this, it defines OPENSSL_NO_SHA, but that can't be done
at compile time:
The OPENSSL_NO_* defines are set by OpenSSL to reflect the configuration
that it was built with so that users of OpenSSL can disable features as
needed. They can affect the contents of structures any thus the ABI of
the library.
If these defines are set outside of OpenSSL, then the library and the
code that uses it will have incompatible ABIs. At that point it's only
functioning by blind luck.
This change renames the name-collisions so that this hack isn't needed.
This is the same change as was made internally in cl/85758149.
BUG=none
BRANCH=none
TEST=emerge-samus coreboot; make runtests
Change-Id: I709da2507f341896d89d50129ce30ffb111a20d1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263506
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For test purposes it should be possible to clear the wipeout request
raised by firmware.
BRANCH=none
BUG=chrome-os-partner:36059
TEST=verified that crossystem wipeout_request=0 changes the bit from 1
to 0, and wipeout_request=1 does not change it from 0 to 1.
Change-Id: Ic45ec03ed3e40e6fee4244804b8c231ee88af95b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262466
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This commands reads/sets a bit in the kernel-reserved area
of the vboot context nvram. The bit can also be set by the
driver during execution of a TPM command, to check if the
command is interrupted by a panic or power loss. Under
some circumstances, this correlates with the TPM assuming
it is under attack.
BUG=chromium:431360
TEST=try "crossystem tpm_attack" and variations
BRANCH=none
Change-Id: I87215d5a0becfb5c01e0b69867a339bfe6fd0b68
Reviewed-on: https://chromium-review.googlesource.com/261339
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
It has become necessary to be able to "factory reset" certain devices
on firmware request. The best mechanism for this is NVRAM, as the
request needs to be detected very early in the boot process, before
other means of communications with the upper layers are available.
A previously unused NVRAM bit (bit 0x08 at offset zero) is taken for
this purpose.
A new flag is introduced to allow the firmware to signal the need to
assert this bit.
A new variable name/parameter ('wipeout_request') added to crossystem
to provide user space access to the setting of the dedicated NVRAM
bit.
BRANCH=storm
BUG=chrome-os-partner:37219
TEST=with all the patches applied, on storm, holding the recovery
button at startup for 10 seconds, causes 'crossystem
wipeout_request' to report '1'.
Change-Id: If1f6f061ce5b3f357b92aaa74cb129671dc30446
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/259857
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This command reads a single .pem file and emits the public and
private keys generated from it. It can produce both the old-style
vboot 1.0 keys (.vbpubk and .vbprivk), or the new vboot 2.1
format keys (.vbpubk2 and .vbprik2). The default is the new
format, but you can give futility the --vb1 arg to force the old
format.
A test is included.
BUG=chromium:231547
BRANCH=ToT
TEST=make runtests
Change-Id: I4713dc5bf34151052870f88ba52ddccf9d4dab50
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246766
Reviewed-by: Randall Spangler <rspangler@chromium.org>
CL:221230 added the new NVRAM fields fw_prev_tried and fw_prev_result.
It also provided support in the crossystem library to decode these
values, but it forgot to add them to the table of allowed crossystem
options so they actually cannot be queried by the command line tool. Fix
that since this information is useful to debug failures after updating.
BRANCH=R41
BUG=chrome-os-partner:36183
TEST=make runtests VBOOT2=1. cros deployed onto Jerry and confirmed
fw_prev_tried and fw_prev_result are correct.
Change-Id: I8bad7266379d959f5370b7ebeefbbba939c5de06
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245143
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch reinstates the external GPT support which was previously
committed and reverted. Improvements since last time include:
- Cleaned-up internal interface based on code review
- Function correctly on legacy bootloaders (e.g., depthcharge before
NAND-related patches are added)
- Better comments
- Treat new field values = 0 -> not use new feature
- Tests are added to ensure external GPT flag is passed down properly
The original commit had change-id
I5a77e417aea8ee9442d18c200d1b073aa5375ecf
Its commit message is reproduced below, and then an additional test.
----
To support an external GPT, disks have two new attributes:
- A binary flag indicating whether the GPT is in the same address
space as the payloads or a separate one.
- The number of sectors of the streaming portion of storage, as
opposed to the portion containing the GPT.
These have been added elsewhere to GptData (in cgptlib) and BlockDev
(in depthcharge). This patch adds the plumbing between those, including
in the DiskInfo interface between the firmware and vboot.
BUG=chromium:425677
BRANCH=none
TEST=Interactively wrote the GPT with cgpt and observed the following
boot with depthcharge to read the GPT from SPI and then read from
the proper locations in NAND flash.
TEST=make runalltests passes.
TEST=boots from USB with depthcharge from HEAD.
Change-Id: Ia7956517a7b9da0301f01fac5a10204f6d78cf4f
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234640
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The dev_debug_vboot program can sometimes interfere with
automated firmware testing because it takes too long to read the
BIOS flash. Limiting the sections of flash that are read may
help, but in some cases skipping this program entirely may be
better.
This CL does three things:
1. dev_debug_vboot will read only some sections of the BIOS
flash, falling back to reading the whole thing only if it
fails at that.
2. dev_debug_vboot will source /etc/default/vboot_reference if it
exists. Putting DEV_DEBUG_FORCE=1 in that file will prevent
dev_debug_vboot from reading the flash at all unless it's
invoked with --force option.
3. The Makefile will create the /etc/default/vboot_reference file
in the install directory, setting DEV_DEBUG_FORCE to the value
in effect at build time. This will let a future CL change the
default behavior for each target.
BUG=chromium:438854
BRANCH=none
TEST=manual
Built and tested on Samus. /etc/default/vboot_reference was
present, containing "DEV_DEBUG_FORCE=". The dev_debug_vboot
script ran normally.
Manually changing /etc/default/vboot_reference to contain
"DEV_DEBUG_FORCE=1" and rebooting caused dev_debug_vboot to stop
before reading the BIOS flash.
I also manually forced various flashrom invocations to fail to
test each part of the new flow.
Change-Id: Ib319dd16b9026162d01f435f15570ec8ba99c512
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233228
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This reverts commit 5040a945df.
This patch breaks booting any image (both fixed and
removable) on Veyron_Pinky (and presumably every other
non-NAND board?). By the power vested in me through the
office of ChromeOS tree sheriff (well, five hours early
but whatever) it is hereby reverted!
BUG=chromium:425677
BRANCH=none
TEST=Can successfully boot on Veyron_Pinky again.
Change-Id: I9323a3d5e34491337fc7eb09dd00d845ac42997d
Reviewed-on: https://chromium-review.googlesource.com/229963
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
To support an external GPT, disks have two new attributes:
- A binary flag indicating whether the GPT is in the same address
space as the payloads or a separate one.
- The number of sectors of the streaming portion of storage, as
opposed to the portion containing the GPT.
These have been added elsewhere to GptData (in cgptlib) and BlockDev
(in depthcharge). This patch adds the plumbing between those, including
in the DiskInfo interface between the firmware and vboot.
BUG=chromium:425677
BRANCH=none
TEST=Interactively wrote the GPT with cgpt and observed the following
boot with depthcharge to read the GPT from SPI and then read from
the proper locations in NAND flash.
make runalltests passes.
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Change-Id: I5a77e417aea8ee9442d18c200d1b073aa5375ecf
Reviewed-on: https://chromium-review.googlesource.com/228943
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds a field in the GBB header to store the sha256 digest of
the HWID string, and updates gbb_utility so that it stores the
digest when it modifies the HWID. Because this is a new field,
the GBB_MINOR_VER is incremented.
BUG=chromium:415227
BRANCH=ToT
TEST=make runtests, VBOOT2=1 make runtests
Since the GBB is in the RO firmware, there should be no side
effects for existing devices (but even without that, they should
handle a minor version change without complaint).
Change-Id: Icdb2a0b564677b0b65e58df897d2ec5af3964998
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221360
This just involves deleting the "set -o pipefail" line. With
bash, that meant that any program failure in a pipe would be
fatal. Without it, only the last program matters. This usually
means that the last command simply gets no input, in which case
the program just appears to do nothing instead of complaining
about whatever the problem was.
Since vbutil_what_keys is generally only used to help debug a
failure to boot, that's not a major problem.
BUG=chromium:419773
BRANCH=ToT
TEST=manual
Tried on a Pit, it works:
localhost ~ # /tmp/vbutil_what_keys /dev/mmcblk0
-e
IMAGE: /dev/mmcblk0
part 2 kernel: d6170aa480136f1f29cf339a5ab1b960585fa444 (!DEV DEV !REC) developer keys
part 4 kernel: d6170aa480136f1f29cf339a5ab1b960585fa444 (!DEV DEV !REC) developer keys
localhost ~ # flashrom -r /tmp/bios.bin
flashrom v0.9.4 : 904e8a5 : Sep 22 2014 20:47:40 UTC on Linux 3.8.11 (armv7l), built with libpci 3.1.10, GCC 4.8.x-google 20140307 (prerelease), little endian
Reading flash... SUCCESS
localhost ~ # /tmp/vbutil_what_keys /tmp/bios.bin
-e
BIOS: /tmp/bios.bin
hwid: PIT D3A-D4Q-A3L
root key: a026a7a4a0bf0fa32d6b7aa90a80d5ef01a3b799 Daisy MP-v3, Peach-Pi MP, Peach-Pit MP-v2, Snow MP
recovery key: 6d9a2ca8b3080a97e1e5a4efbc5386ead77c3c7f Peach-Pit MP-v2
localhost ~ #
Change-Id: I171da3bf688032f469d7a5cdb42278d8028b7e0d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221176
Reviewed-by: Mike Frysinger <vapier@chromium.org>
scripts/sign_data.sh is just a wrapper to do this:
./signature_digest_utility $1 $3 \
| openssl rsautl -sign -pkcs -inkey $2
AFAICT, that script is only invoked by the SignatureFile()
function in host/lib/file_keys.c, which is not referenced by
anything. I think I can remove both of those things.
Also remove utility/gbb_utility.cc, which should have been done
long ago in commit 6f39615.
BUG=none
BRANCH=ToT
TEST=make runalltests
Also ran it on daisy_spring-paladin and link-tot-paladin.
Change-Id: I16de5022765806f11bf6144d7ffd8cc849578a68
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216719
Reviewed-by: Mike Frysinger <vapier@chromium.org>
We still create the symlinks (FOO -> futility), but this
change invokes those built-in functions with "futility FOO ..."
instead of using the FOO symlink.
Note that the scripts/ directory is unchanged. That's a
separate CL, since we don't have tests for that.
BUG=chromium:231547
BRANCH=ToT
TEST=make runtests
In addition to running "make runtests", I temporarily
modified the Makefile to avoid creating the symlinks at all.
The tests still passed.
Change-Id: I96863259b9df02a3611f759a7509bf4090ae03e8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216717
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There are a number of tests that haven't even been compiled in a LOOOONG
time. Let's get them out of the way. We can always put them back later.
I'm adding a comment to this CL in the Makefile.
BUG=none
BRANCH=ToT
TEST=make runalltests
Change-Id: Id2d9f0b71fc40e4a260f54cf919c6af5e0ff85c5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214610
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Update the unit tests which use it to use futility. No functional
changes to it, just relocation.
Remove the futility test which checks the exact list of supported
commands. This doesn't have a good way of handling
conditionally-compiled commands, and will be even harder to maintain
as we add more commands in the future. Presence of sub-commands is
still ensured by the other tests which use them (such as
vb2_firmware_tests.sh)
BUG=chromium:231547
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests
Change-Id: Idddb639276e4c6449d023d40ac7977123113bd28
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213191
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This change adds these formerly external utilities into the futility binary:
dev_sign_file
dump_kernel_config
gbb_utility
vbutil_firmware
vbutil_kernel
These target binaries will remain independent of futility, since they are
not directly related to verified boot:
cgpt
crossystem
tpm_init_temp_fix
tpmc
Also, dumpRSAPublicKey is removed from the target, since it is only used on
the build host to create new keypairs.
This change also add several additional tests.
BUG=chromium:224734
BRANCH=ToT
CQ-DEPEND=CL:210391,CL:210568,CL:210587
TEST=manual
make runtests
make clean
Also build and test:
- normal image
- test image
- recovery image
- firmware shellball
Note that this CL depends on simultaneous changes to the chromeos-initramfs
ebuild.
Change-Id: If791b5e9b5aac218ceafa9f45fc1785f16b91a64
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210403
There are a few utilities that print the full path of any file they open.
This isn't necessary, and it just has to be ignored when running regression
tests from different directories.
This just removes that extra noise.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: I4291bca7952a0d7371f8682b7d57545361c6341c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207619
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We've been creating and linking against a library called "libvboot_host.a"
for two different reasons. The main purpose is to build the vboot_reference
tools found in the utility/ directory. But there are some external userspace
programs that would also like to use some functions in this library.
This change establishes libvboot_host.a as the library for use by external
userspace programs only, and creates a new libvboot_util.a library that's
only used inside this source tree to build the vboot utilities.
BUG=chromium:231567
BRANCH=ToT
TEST=manual
Build and run the local tests:
make runalltests
make clean
Build Link firmware and all the utilities:
emerge-link chromeos-base/vboot_reference \
sys-boot/depthcharge \
sys-boot/coreboot \
chromeos-base/chromeos-ec \
chromeos-base/chromeos-firmware-link \
chromeos-base/chromeos-cryptohome \
chromeos-base/update_engine \
chromeos-base/chromeos-installer \
chromeos-base/chromeos-login \
chromeos-base/verity
Build Lumpy utilities, which include the 32-bit cros_installer:
emerge-lumpy chromeos-base/vboot_reference \
chromeos-base/chromeos-login \
chromeos-base/verity \
chromeos-base/update_engine \
chromeos-base/chromeos-installer \
chromeos-base/chromeos-cryptohome
Change-Id: Ie81ff1f74a6356cb8fab7d98471139d7758c4f19
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207016
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This constructs a test firmware using the old vboot signing utilities,
and then verifies it using vboot2 libraries. This ensures vboot2 can
read files signed by the current signing process.
BUG=chromium:370082
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Icc113c982e5ed99382a4592f9ab688784e853c8e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204561
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I'm breaking the last chunk of vboot2 into smaller pieces as I add
tests. This has the api-level routines actually called by depthcharge.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: Ic7c082fc5faa0b874b2fa5a15ebda7135dcafe0b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200151
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We use a few bytes of battery-backed nvram to save some flags across
reboots. However if the battery discharges completely, these flags are lost.
There aren't any security issues with that since they reset to safe values,
but some of the flags are used to configure how the system boots in
dev-mode.
If a dev-mode user has completely replaced ChromeOS with some other OS, then
she often needs to set the dev_boot_usb and/or dev_boot_legacy flags as well
in order to boot it using Ctrl-U or Ctrl-L. If the battery dies, then those
flags are cleared, and the only way to make the Chromebook boot again is by
going through recovery, which wipes the disk.
This change uses a new NV space in the TPM to back up some of the nvram
flags. These nvram fields will be backed up:
block_devmode
dev_boot_legacy
dev_boot_signed_only
dev_boot_usb
fwupdate_tries
loc_idx
Because writing to the TPM space is slow and limited to an unspecified but
finite number of cycles, we only back up the fields when specifically
requested by the new backup_nvram_request flag. This flag will be set by
crossystem whenever it is used to change any of the fields listed above. The
backup will be attempted at the NEXT boot (because the TPM is locked after
booting), and the backup_nvram_request flag will be cleared if the backup
was successfull.
Note that this CL is for Top of Trunk only. The firmware will create the
required TPM spaces on systems that have never been booted, but we don't yet
have a secure or reliable method to update existing systems.
FYI, on Link, determining that the TPM's backup NV space doesn't exist adds
about 6ms to the boot time. If it does exist, the backup_nvram_request flag
is cleared automatically so it won't check until it's set again.
BUG=chromium:362105
BRANCH=ToT (only!)
TEST=manual
Testing this is a long and involved process. Read on...
First, there are host-side tests for it. In the chroot:
cd src/platform/ec
make runtests
Second, to test on a completely NEW system that was first booted with a BIOS
that contains this CL, do this:
Enter dev-mode
Use crossystem to set values for the fields listed above
Confirm that "backup_nvram_request" is set to 1
Reboot
Use crossystem to confirm that "backup_nvram_request" is now 0
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Use crossystem to confirm that the backed up fields are still good, while
the others have been reset to default values
Switch to normal mode
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Look at the bios info in chrome://system to see what crossystem says
Confirm that the dev_boot_* flags are all 0, while the others are restored
Third, to set things up to test this on an existing system (I used Link),
you have update the BIOS, delete both the Kernel and Firmware NV spaces in
the TPM, then reboot so that the BIOS will create the Backup, Kernel, and
Firmware spaces. It will only do that if they're all missing.
Open it up, disable write-protect, attach a servo, etc.
Switch to dev-mode, log in.
Run make_dev_firmware.sh
Reboot in recovery mode, and insert a USB stick with a test image on it.
NOTE: In order to fiddle with the TPM, we'll *always* have to boot in
recovery mode, since that's the only time the TPM is left unlocked. That's
NOT the same as pressing Ctrl-U at the scary boot screen. The rest of
these steps assume you've booted in recovery mode and are running from the
test image on the USB stick.
Run
make_dev_ssd.sh --remove_rootfs_verification --recovery_key
Reboot (recovery mode)
Run
mv /etc/init/tcsd.conf /etc/init/tcsd.conf.disabled
Reboot (recovery mode).
Run "tpmc getvf". It should say
deactivated 0
disableForceClear 0
physicalPresence 1
physicalPresenceLock 0
bGlobalLock 0
Run "tpmc geto". It should say
Owned: no
Now you'll need to build the "tpm-nvtool" utility. In the chroot:
cd src/third_party/tpm/nvtool
make
Copy that to the DUT, in /usr/local/bin.
Now run
tcsd
tpm-nvtool --list | grep Index
You may see a number of spaces, but you should at least see these:
# NV Index 0x00001007
# NV Index 0x00001008
Run
tpm_takeownership
It will prompt you for two passwords (and confirm each one). Respond with
something you can remember like "google".
Run
tpm-nvtool --release --index 0x1007 --owner_password "google"
tpm-nvtool --release --index 0x1008 --owner_password "google"
Verify that it worked with
tpm-nvtool --list | grep Index
Power off.
Using servo, flash the new BIOS that has this CL in it.
Power on, normally this time (not recovery mode). If all goes well, it
should create the correct NV spaces and boot into the SSD. Copy tpm-nvtool
into this image too, and run
tpm-nvtool --list | grep Index
You should now see at least these spaces:
# NV Index 0x00001007
# NV Index 0x00001008
# NV Index 0x00001009
Now you're ready to test the backup/recover feature.
Change-Id: I00031fa0774720147327e2ae0f37e26b34b86341
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202138
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Currently, this does nothing. It just sets a flag that nothing looks at.
Don't get all wound up - we haven't abandoned our principles. This will
eventually be used to allow enterprise-enrolled customers to prevent
unauthorized use of developer mode in the Chrome OS devices that THEY OWN.
This is not Google deciding to turn a feature off, it's allowing the OWNER
to control the use of the feature. In some situations, the owner can be held
liable for what others do with the owner's equipment. This will help the
owner avoid those situations while their device is out of their immediate
control.
BUG=none
BRANCH=ToT
TEST=manual
Set the flag with:
crossystem block_devmode=1
Clear it with:
crossystem block_devmode=0
Retrieve the value ("0" or "1") like so:
val=$(crossystem block_devmode)
echo "the flag is $val"
or just test it directly like so:
if crossystem 'block_devmode?1' ; then
echo "devmode is blocked"
else
echo "devmode is allowed"
fi
It should be persistent across reboots.
Change-Id: I097f15b307e1c3a2a9db595e9495028a2eea6309
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197771
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a VB_MAX_STRING_PROPERTY for callers that don't
want to guess at how big to make their buffers.
Additionally, it changes the size parameter to VbGetPropertyString()
from int to size_t.
BUG=None
TEST=compile the code
BRANCH=none
Change-Id: I22809d48e13b535593cb22a56444e2dcb27791a5
Reviewed-on: https://chromium-review.googlesource.com/175039
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
Querying "debug_build" allows the caller to determine whether the
image has requested debug, independent of the setting of the
dev_mode switch.
BUG=chromium:308678
BRANCH=none
TEST=use the new command option on both base and dev images
Change-Id: I369f26d75156f2e88d9f6f467efbf8f633e78bda
Reviewed-on: https://chromium-review.googlesource.com/174107
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.
Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.
Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.
The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.
The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.
The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.
BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference
Change-Id: If2b8bbe467fdbd643239d8d9b5d7aa98df4d286f
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167361
At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.
Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.
Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.
The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.
The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.
The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.
BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference
Change-Id: I2c19e9dc2ed602d0642bbf4f7d27f79fe9fad873
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In case of a TPM error, tpmc returns the TPM error code, which can
be greater than 255. In that case the error code is truncated.
Some error codes, such as TPM_E_RETRY, end with a zero byte,
resulting in a successful exit code. This is despicable.
BUG=chromium:234357
TEST=tested with exit codes < 255. Too hard to generate the others.
BRANCH=none
Change-Id: I891a5c0659c06aac778449e2a0a935c5f82ccdb8
Reviewed-on: https://chromium-review.googlesource.com/66885
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
The "-p internal:bus=*" is now deprecated by "-p {host,ec}" because we may have
EC on SPI bus.
BUG=none
TEST=manually executed dev_debug_vboot and see correct output.
BRANCH=none
Change-Id: I6363c09c2ebf57812bf35b7db220303a2786db20
Reviewed-on: https://gerrit.chromium.org/gerrit/66321
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
When copying the vmlinuz zeropage, the entries were being truncated even
though the boot protocol version was being retained. This means that
booting a kernel that depended on details from the zeropage's ignored
areas would find invalid information. Fix this by copying out the entire
possible range of memory.
BUG=chromium:230212
TEST=kernels can boot with CONFIG_RELOCATABLE
BRANCH=None
Change-Id: Ifb94bedcf881e17ab20fff44d8c1c1885b15ef9e
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47832
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This stops creating dump_fmap as a standalone utility and builds it into
futility. Since it was already invoked as a symlink, no user-visible changes
should be observed.
BUG=chromium:224734
BRANCH=none
TEST=manual, trybots
sudo FEATURES=test emerge vboot_reference
FEATURES=test emerge-$BOARD vboot_reference
Change-Id: I68d1bea0c1867043b2633e15509b95c2717009a7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47672
Reviewed-by: Randall Spangler <rspangler@chromium.org>
FindKernelConfig() is used to extract the kernel cmdline from a kernel
partition. It's only used in the chromeos-installer, but was a bit awkward.
This changes the calling parameters to make it simpler.
BUG=chromium:221544
BRANCH=none
TEST=manual
CQ-DEPEND=CL:46835
FEATURES=test sudo emerge vboot_reference
FEATURES=test emerge-$BOARD vboot_reference
Change-Id: Ib7192175d72ad51387d8d122ead4490a4aa62300
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46834
The chromeos-installer uses several functions from the vboot_reference
userspace library, but the names of those functions are inconsistent:
IsZero
MapFile
VbGetSystemPropertyString
cgpt_add
cgpt_boot
cgpt_create
cgpt_get_boot_partition_number
cgpt_get_num_non_empty_partitions
cgpt_get_partition_details
cgpt_prioritize
cgpt_set_attributes
find_kernel_config
The Google C++ style guide says types and functions should use CamelCase,
while variables use lower_case_with_underscores.
Kernel style (which vboot_reference tries to be more-or-less compatible
with) uses lower_case_with_underscores for everything, but that really only
has to apply to firmware stuff. For userspace, we can use the Google style.
BUG=chromium:221544
BRANCH=none
TEST=buildbot
CQ-DEPEND=CL:46045
Renaming/cleanup only; no functional changes.
Change-Id: I9c82c9ff8909be88586194c8ffdb435fc771195f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46044
These were macros that were never used, or that were only set to one thing and
could be substituted up front.
I left in code guarded by the HAVE_ENDIAN_H and HAVE_LITTLE_ENDIAN macros even
though those are never defined because they guard a reportedly significantly
faster implementation of some functionality, at least according to a comment
in the source. It would be a good idea to enable that code path and see if it
really does make a big difference before removing it entirely.
BUG=None
TEST=Built for Link, Daisy, and the host with FEATURES=test. Built depthcharge
for Link and booted in normal mode.
BRANCH=None
Change-Id: I934a4dd0da169ac018ba07350d56924ab88b1acc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/45687
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This moves all the old userspace utilities generated by vboot_reference into
a subdirectory not in $PATH, and replaces them with symlinks to a single
executable named 'futility'. At the moment that utility just execs the
original utilities (optionally logging that fact first).
Ultimately, the old utilities will be subsumed into a single binary instead
of multiple separate executables.
There is a matching CL needed to make the recovery image creation work.
BUG=chromium-os:37062
BRANCH=none
CQ-DEPEND=CL:44864
TEST=auto
To test, build everything, test everything. It should work as before in all
cases. I have built normal images, test images, factory installers, recovery
images; they all seem to work.
I've run trybots on daisy-paladin link-paladin lumpy-paladin and alex-paladin.
Change-Id: Ie93db676f2ed2a64e4b13b3b5dc6b65a77db0f8c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44871
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This utility sets up the encrypted directories for Chrome OS at boot time.
It uses some of the TPM-related libraries from vboot_reference, but it
isn't really part of the verified boot process itself so I'm moving it into
the cryptohome repo where it belongs.
This CL just removes the code from vboot_reference. Another CL will put it
into cryptohome, and yet another will change the ebuilds to notices.
BUG=chromium-os:39264
BRANCH=none
TEST=auto
CQ-DEPEND=CL:44301, CL:44302
This is just refactoring, not a new feature. After all the CLs are in, the
platform_EncryptedStateful autotest should continue to pass as before.
Change-Id: I6bb436ae57140e89581cb0be5dc2385b8f3ff5e2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44303
Reviewed-by: Kees Cook <keescook@chromium.org>
In an effort to reduce the chances of a kernel bug wrecking filesystems
during encrypted-stateful shutdown, add explicit sync() calls during
shutdown.
BUG=chrome-os-partner:17610
TEST=link build, shutdown with simulated panic in LOOP_CLR_FD results in
successful journal replays
BRANCH=None
Change-Id: I4be981ebd0270d275ae81a79e3195bc72b70d984
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43736
Reviewed-by: Grant Grundler <grundler@chromium.org>
AFAICT, we don't actually run this test anywhere. If we do, we shouldn't
hard-code the path to the real chromeos-tpm-recovery utility, because we
may need to move it around.
BUG=none
BRANCH=none
TEST=none
Change-Id: I295d57d659adf564ca964efc91d95dfdd1ff00aa
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43174
Reviewed-by: Randall Spangler <rspangler@chromium.org>
