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>
We want a quick and human-friendly way to match keys with
signatures, so we decided to give each key a unique GUID and
carry that ID around when signing things.
But then we realized that we could autogenerate a unique
identifier from the .pem file itself, which is even better
because then we can match our binary keypair structs with the
openssl file used to generate them.
This change replaces the GUID id with a sha1sum calculated from
the public key's "keyb" blob.
BUG=none
BRANCH=none
TEST=make runtests
Also:
futility show tests/testkeys/key_rsa4096.pem
futility create tests/testkeys/key_rsa4096.pem foo
futility show foo.vbp*
Note that the GUID is the same for all files.
Change-Id: Ie44e46c83433718b1ff0163c1e7c51ec331b99f9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256181
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Because all of our private key structs carry around the openssl
struct rsa_st data blobs, we can use those blobs to extract the
corresponding public key and generate a digest of it.
This lets us match our public and private keys without having to
rely on the filenames. There's no crypto verification without
actually *using* them, of course, but it's handy for quick reference.
BUG=chromium:231574
BRANCH=none
TEST=make runtests
This also adds a test to ensure that all the public and private
keys generated from the same .pem file have the same sha1sums.
Change-Id: If83492437e3ef37f7c4ebca4675336b75f631901
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246768
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This enhances the futility show command to recognize and identify
our public and private key files, for both the old vboot 1.0
format and the new vboot 2.1 format.
BUG=chromium:231547
BRANCH=ToT
TEST=make runtests
vboot 1.0:
futility show tests/devkeys/*.vbp*
vboot 2.1:
futility create tests/testkeys/key_rsa2048.pem foo
futility show foo.vbp*
Change-Id: I9d7641db03e480b416790a7da6b473215444128a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246767
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>
postinst needs access to a kernel that is bootable from legacy BIOS.
futility provides extraction of a bootable vmlinuz from the kernel
partition via the command line. This patch provides a function which
does the same thing and is suitable for static linking into postinst
with minimal additonal code linked in. This way we can avoid issues with
running dynamic executables during postinst.
BRANCH=none
TEST=None
BUG=chromium:455343
Change-Id: Iaec2f48e4d8f78a4bbfcc1636b6ce478e95e9a8e
Reviewed-on: https://chromium-review.googlesource.com/251760
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
1. Increase kernel preamble revision from 2.1 to 2.2.
2. Add flags field to kernel preamble.
3. Update futility to accept flags parameter for vbutil_kernel and
cmd_sign for kernel.
4. Pass in an extra flags field to SignKernelBlob and
CreateKernelPreamble.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=1) "make runalltests" completes successfully. 2) vboot_reference
compiles successfully for ryu. 3) Verified flags field in header using
futility show.
Change-Id: If9f06f98778a7339194c77090cbef4807d5e34e2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/245950
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The following works from a Mac with these changes:
make Q= ARCH=arm HAVE_MACOS=1 `pwd`/build/futility/futility
Only vbutil_keyblock and vbutil_kernel have been exercised.
BUG=none
TEST='make Q= ARCH=arm HAVE_MACOS=1 `pwd`/build/futility/futility'
BRANCH=none
Signed-off-by: David Riley <davidriley@chromium.org>
Change-Id: Ie69cfee0c650d4ff96be6322083a2fea1543ee39
Reviewed-on: https://chromium-review.googlesource.com/246773
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
The kernel chromeos_arm platform device provides the recovery status
with the consideration of active polarity.
Thus make crossystem to read from chromeos_arm device first. If this
is not available, read directly from gpio pin status.
BUG=chrome-os-partner:36425
BRANCH=none
TEST=ran on kitty,
'crossystem recoverysw_cur' return 0 with recovery switch off
'crossystem recoverysw_cur' return 1 with recovery switch on
Change-Id: Ie20630d7d07aeadf24044cd3ffc495df7cdd8a4a
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/246883
Tested-by: Titan Lee <titanlee@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Titan Lee <titanlee@nvidia.com>
A truncated BIOS with an otherwise valid FMAP that now points way
off the end of the file shouldn't cause coredumps.
BUG=none
BRANCH=ToT
TEST=make runtests
Change-Id: Idf96e1e6a381bf0fe0b1cb2d16e3dad39ce7a0dc
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245500
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Adding functionality to allow for rebuilding of vmlinuz after it
has been processed into vblock and header stripped. Basically appends
the 16-bit header of a vmlinuz image onto the end of the vblock.
BUG=chromium:438302
BRANCH=none
TEST=Successfully ran "make runalltests".
Also, ran:
1. Repack kernel block (so that 16-bit header is included):
"vbutil_kernel --pack kern_0 ..."
2. Verify kernel: "vbutil_kernel --verify kern_0 ... ". This should
be done before booting into kernel, but not necessary for it to work.
3. Rebuild vmlinuz image:
"vbutil_kernel --get-vmlinuz kern_0 --vmlinuz-out vm.out"
4. Set up kexec with vmlinuz (this should complete with no errors):
"kexec -l vm.out (other kernel cmd line args)"
5. Boot into kernel:
"kexec -e"
Change-Id: Iaa1582a1aedf70b43cdb3a56cde1fb248f1793d4
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232750
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When working on NAND, we do not actually work with one device name. We
work on a temporary file instead. Moreover, depending on the type of the
partition, we need to show different devices.
BUG=None
BRANCH=None
TEST=All commands must be run on storm_nand
TEST=/usr/bin/cgpt.bin find -t kernel should print out /dev/mtd2
TEST=/usr/bin/cgpt.bin find -t rootfs should print out /dev/ubiblock5_0
TEST=/usr/bin/cgpt.bin find -t data should print out /dev/ubi1_0
Change-Id: Ia36777ffa6a9cfc7c8ec4b128e49ece140428238
Reviewed-on: https://chromium-review.googlesource.com/242291
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@google.com>
This patch changes the FMAP detection mechanism in host utilities to use
the same algorithm as flashrom: try to check the offset with the largest
possible alignment first, then subsequently check other offsets in the
order of larger to smaller alignments. This provides consistency between
the tools and makes the chance of finding the "wrong" FMAP (e.g. a bit
pattern that just looks like an FMAP header, maybe from a piece of
source code that tries to look for the same) less likely, since we
usually try to prefer large alignments for the FMAP offset (for flashrom
efficiency).
BRANCH=None (should be updated on the signers... is that a branch?)
BUG=chromium:447051
TEST='make runtests'. Manually ran the new dump_fmap on all images in
tests/futility/data, and on a "known broken" Veyron_Pinky image that had
a "fake" FMAP header at a 4-byte aligned offset.
Change-Id: I15873573a93f3926c70136679dccd626e5038614
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240750
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Now that lib20 and lib21 are distinct, they can have overlapping
struct names. This will be cleaner in the long run, since vboot 2.0
(lib20) is just a temporary stepping stone to vboot 2.1 (lib21). It
would be a shame to need to carry around the overhead of that extra
digit forever.
No functional changes, just a lot of renaming.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And compile firmware for veyron_pinky
Change-Id: I25f348fd31e32d08ca576836dfdd1278828765a1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233183
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Code which compiles against fwlib2 no longer knows or cares about the
new data structures. This should shrink fwlib2 a bit. This is part 3
of 4 changes which split vboot 2.0 struct handling (old vboot1
structs) from vboot 2.1 struct handling (new style structs).
No functional changes; just shuffling around code.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And compile firmware for veyron_pinky.
Change-Id: Ibccd7d1974e07f38b90c19c924ef3b1ffcb77d62
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233020
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is part 1 of a series of 4 changes which rearrange the vboot2
files and unit tests so that we can more cleanly switch over from
old-style structs to new-style structs.
No functional changes, just shuffling around code.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And build firmware for veyron_pinky.
Change-Id: I170d737bf151a6bafe61cde23b3d2f7a3fae43ce
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232978
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Also add vb2_common_desc() helper function to return the description
for an object starting with a common struct header.
And use the new host lib function to create the keyblock for verifying
the firmware lib.
Add tests for everything new.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I1fadb3e249e771a692cc69b23620c6ddd46a48ac
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231721
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes the hacky conversion from old-style packed keys and
signatures, which existed only because at the time we didn't have the
ability in hostlib to create new-format key and signature structs
directly.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Id7cb3dfce740f2546464a4caae2629af864d7b45
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231543
Including signing with bare hashes, and signing an object with more
than one signature. With unit tests, even.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Iad0b9f9f6cca7129071aebf0cbc60c0daa94d382
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231452
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
And unit tests for them.
Move roundup32() into hostlib.
Fix WriteFile() returning success even if it failed to write to the file.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I8a115335c088dc5c66c88423d1ccbda7eaca1996
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230844
Previously, "cgpt" called out to "flashrom" directly to read and write
NOR area. This CL removes that dependency and always treats "drive_path"
as the storage of GPT structs. This makes it consistent that whatever
device that cgpt reads from or writes to is always the device that
stores GPT structs. We only need to pass in the size of the drive that
contains the partitions, but we do not need to access to that drive.
More information is in the bug.
BUG=chromium:432611
BRANCH=none
TEST=unittest
CQ-DEPEND=CL:228942
Change-Id: Id0139adf70463cec4f2924de8b9a4725dbec822b
Reviewed-on: https://chromium-review.googlesource.com/229736
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Storing nvram in SPI Flash becomes more and more popular. Retrieving
it takes quite a while due to various flashrom issues. While flashrom
still needs to be improved to minimize its running time, a good speed
up can be achieved by caching the nvram contents in crossystem.
The cache is invalidated each time nvram is written (this could be
optimized by updating the local copy, but probably is not worth the
extra effort).
BRANCH=storm
BUG=chrome-os-partner:33592
TEST=crossystem runs much faster now:
localhost var # time /var/tmp/crossystem
. . .
real 0m1.669s
user 0m0.790s
sys 0m0.170s
localhost var #
Change-Id: Ie4a483efc189257ff58c92bdc39871b917c89727
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228655
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The current logic for finding a GPIO expects only one gpiochip
entry to exist in /sys/class/gpio. With Samus there is a second
entry because the codec also exports a set of GPIOs.
To solve this we can use the gpiochip#/label file and compare
against the GPIO controller name described in ACPI.
This adds support for that detection method, as well as a new
GPIO controller entry for INT3437:00 which is used in Broadwell
systems.
BUG=chrome-os-partner:33098
BRANCH=samus
TEST=crossytem wpsw_cur works on samus (TOT with enabled codec)
Change-Id: Ib06f25c7c7e1451a3ab3bb00fd063e23b4d75878
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224156
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Currently ReadFileInt assumes that an integer value read from a file
is never going to be "-1" and uses that value to indicate failure.
In particular for GPIO values that may be returned by the kernel it
is possible for them to be not simply 0 or 1 but instead a bit within
the GPIO status register that indicates the value.
The function semantics are changed to have the caller pass in the
variable to store the integer in, and use the return code explicitly
as a pass or fail condition.
This requires all the callers of ReadFileInt to be changed to use the
new scheme, and the x86 ReadGpio function is changed to normalize the
GPIO value that is read from the kernel instead of assuming it is
always 1 for active high values.
BUG=chrome-os-partner:32645
BRANCH=samus,auron
TEST=build for samus, check crossystem output and ensure that all
values are properly reported and that wpsw_cur is correct now.
Also tested to ensure no changes in output on: x86-alex, daisy,
peach_pit, lumpy, stumpy, nyan_big, nyan_blaze, rush_ryu, panther,
wolf, zako, auron, rambi, squawks, parrot_ivb, veyron_pinky
Change-Id: I824152eed5f96cf1faaa18ba31a01f4d346ad172
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223009
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is just a cosmetic tweak to make it a bit clearer that
mosys is the underlying interface for these particular vbnv
read/write functions.
BUG=none
BRANCH=none
TEST=it still compiles
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ide172bfecf608a30489d25026268aedfc421ce4d
Reviewed-on: https://chromium-review.googlesource.com/222062
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This handles VBNV data stored in SPI flash which happens to be
the exact same way we handle VBNV data stored in the EC.
BUG=chrome-os-partner:31529
BRANCH=none
TEST=with CL:221349 applied, crossystem on storm no longer
spews tons of errors
Change-Id: I021d9f430acfac34dff44a927361a5a0e5ae2ff8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222061
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This gives recovery mode information on two boots back instead of one,
which may be handy for debugging.
It also allows determining whether a failure of the current boot
should try the other slot or go to recovery, using only information
stored in NV storage.
Added crossystem support for printing the fields, and unit tests.
BUG=chrome-os-partner:32585
BRANCH=none
TEST=make runtests; VBOOT2=1 make runtests
Change-Id: Ia9f4186210d30217b902db7c513ae4ab8851f8f4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221230
Reviewed-by: Daisuke Nojiri <dnojiri@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>
It doesn't yet handle block devices, but it can display normal files
containing a entire BIOS image, a GBB, a VBLOCK, a .vbpubk, a .vblock,
and a firmware preamble (VbFirmwarePreambleHeader).
The command-line options are not well-documented.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: I181f6331ae23599302bbaee3f270e8af9586cf06
Reviewed-on: https://chromium-review.googlesource.com/216032
Commit-Queue: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The functions that look for the FMAP and its entries should return more
useful values.
BUG=none
BRANCH=ToT
TEST=make runtests
No functional changes.
Change-Id: I4b62ea0de972bceb3d58f4ee8eb82ad065ddcbae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214630
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Provide a PublicKeyLooksOkay() function to sanity-check VbPublicKey structs.
This was just part of PublicKeyRead(), but I want to separate the reading
from the checking.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: I1dd808e623e2a7fdc2789e02305619111a7b01e6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214621
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This CL accesses the partition entry array through its header's
entries_lba value.
Previously, we assume the primary entry array lies on third sector, and
the secondary array lies (1 + 32) sectors from disk end. This assumption
was fine, even Wikipedia assumed the same.
But in order for us to support writing boot code to the third sector (as
required by some Freescale board), the primary entry array must be moved
to another location. Therefore, we must use "entries_lba" to locate the
arrays from now on.
BRANCH=none
BUG=chromium:406432
TEST=unittest
TEST=`cgpt create -p` and then `cgpt show`. Make sure the table
header and entries are properly moved.
Change-Id: Ia9008b0bb204f290b1f6240df562ce7d3a9bbff2
Reviewed-on: https://chromium-review.googlesource.com/213861
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Rather than continuing to report different variants of PCH GPIO the same
way use the common name of PCH-LP.
BUG=chrome-os-partner:28234
BRANCH=None
TEST=boot on samus and ensure there are no (error) reported
Change-Id: I9321e7bd85b2b3b3ebadc22ac32be6759e85f822
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210393
Reviewed-by: Bill Richardson <wfrichar@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>
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>
Teach crossystem the tegra124 compatibility string so that it can identify the
platform for tegra124 based systems.
I called the platform Tegra5 to fit in with what seems to be the naming scheme
for the other Tegra SOCs.
BUG=chrome-os-partner:25355
TEST=Built and ran on nyan and saw the "platform_family" setting return Tegra5
instead of (error).
BRANCH=None
Change-Id: I1044f958ecdac37ad285fdc3d53e7bc36ca69315
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/184051
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
