This script runs when the target is booted in recovery mode. It
reinitializes the TPM and sets the predefined NVRAM spaces to the
default values.
The precence of the /etc/init/trunksd.init file is used to derermine
if the target is runnig TPM 1.x or 2.x.
The major difference between TPM 1.2 and TPM 2.0 modes is that the TPM
2.0 supporting routines do not yet allow to define NVRAM spaces. This
capability will be added later.
BRANCH=none
BUG=chrome-os-partner:59361, chrome-os-partner:55210
TEST=verified that running chromeos-TPM-recovery on a device booted in
recovery mode properly reinitializes TPM on both reef (TPM2.0)
and kevin (TPM1.2). The previously failing on reef autotest
firmware_UpdateFirmwareDataKeyVersion is now passing.
Change-Id: I58e4ceeb1ba27544b7ebfb045d2d2fc5477ecf43
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407796
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Previously, vb2_unpack_key() actually unpacked a key buffer. Callers
that had a vb2_packed_key had to typecast it back to a uint8_t buffer to
unpack it. Rename vb2_unpack_key() to vb2_unpack_key_buffer(), and make
vb2_unpack_key() unpack a vb2_packed_key.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge;
emerge-samus and boot it
Change-Id: I9ee38a819c59cc58a72ead78cf5ddf3d0f301ae7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400906
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Originally, vboot1 code used VbExMalloc() and VbExFree() since it needed
to talk to EFI firmware that didn't have standard malloc() and free().
Now, coreboot and depthcharge implement them as wrappers around those
standard calls. vboot2 code already calls them directly, so let vboot1
code do that too.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I49ad0e32e38d278dc3589bfaf494bcf0e4b0a4bd
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400905
At this point, all that's left are a few constants in the cryptolib
header files, and they're only used by host-side code. So move them to
a host-side header file and get rid of cryptolib.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I2235f0e84e13fef313afe54e749b73744b157884
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400903
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The old vboot1 cryptolib hard-coded many of its padding arrays in a
padding.c file. Use the equivalent vboot2 apis instead.
This change is almost exclusively on the host and test side; the only
firmware impact is on a single line of debug output.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: If689ffd92f0255847bea2424950da4547b2c0df3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400902
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Another in a continued stream of refactoring. This change removes more
of the vb1 rsa library code and associated tests, in favor of their vb2
equivalents. This change touches only host-side code and its tests, not
firmware.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I1973bc2f03c60da62232e30bab0fa5fe791b6b34
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400901
The usage string wasn't appending a newline to the end which caused
weird output when shown. Add a proper usage() helper and extend the
output a bit to be more human friendly.
BUG=chromium:660209
TEST=`pad_digest_utility` is nice
BRANCH=None
Change-Id: I01c3c5372a4202bc6f5a9b2c5fe0e2a59c3ca5cf
Reviewed-on: https://chromium-review.googlesource.com/404768
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Originally, we didn't trust the firmware to provide these functions from
a standard library. Now, with coreboot, we do.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I4e624c40085f2b665275a38624340b2f6aabcf11
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/399120
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
find: A p is added betwen device name and partition whenever the last
character of a device is a number, as written in disk_name() in kernel
block/partition-generic.c file.
debug_vboot: Add regex for nvme device.
BUG=chromium:655192
BRANCH=none
TEST=Check that when a machine boots from NVMe, chromeos-setgoodkernel
set "successful" field properly.
Run " dev_debug_vboot --cleanup", check the NVMe device kernel
partitions are verified.
Change-Id: I6a9342c95500fa582f51f06e48c1ff90684c2a27
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/398338
Reviewed-by: Mike Frysinger <vapier@chromium.org>
bdb_extend prints out secrets derived from the given BDS based on
the given BDB.
BUG=chromium:649555
BRANCH=none
TEST=make runtests. Ran bdb_extend -s bds.bin -b bdb.bin (with/without -m)
Change-Id: I8d9f73468992dad4cb93a422c0eae0977be9a16f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/385539
Add "inside_vm" command to crossystem.
x86: If there is no HWID and mainfw_type is "nonchrome", report that the
host is a VM. If HWID is present, it's not a VM.
ARM: Detection not implemented and so far no ARM VMs exist, always
report that the system is not a VM
BUG=chromium:632303
TEST=emerge-cyan vboot_reference and test binary on cyan QEMU and HW
BRANCH=none
Change-Id: I18f5cb24b68e51f3097d9aafd9f0db0e610d322a
Reviewed-on: https://chromium-review.googlesource.com/367240
Commit-Ready: Nicolas Norvez <norvez@chromium.org>
Tested-by: Nicolas Norvez <norvez@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Implement macros to handle differences between TPM1.2 and TPM2.0.
For all original tpmc commands define if they are to
(1) be implemented, (2) do nothing, or (3) return a "not implemented"
error.
Print TPM mode (1.2 or 2.0) for tpmc in 'tpmc help' output.
BRANCH=none
BUG=chrome-os-partner:55210
BUG=chrome-os-partner:55250
TEST=boot on kevin; verify that the following tpmc commands do
nothing and return success: ppon, enable, activate; verify
that 'help' prnts the right mode and command descriptions.
Change-Id: Ifec4e8e5bd4afb45f76f9c2b3249c844ea1b670a
Reviewed-on: https://chromium-review.googlesource.com/363000
Commit-Ready: Andrey Pronin <apronin@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
As discussed in https://chromium-review.googlesource.com/#/c/361381/,
instead of being a synonym to 'tpmc pplock', the 'tpmc block' command
should protect just the FW index using WriteLock.
Additionally, both TlclSetGlobalLock and TlclLockPhysicalPresence in
tlcl (which are used by 'tpmc block' and 'tpmc pplock') are updated
to first check if the platform hierarchy is already disabled and
return success, if so. That's needed to prevent command failures
when rollback protection is already on.
BRANCH=none
BUG=chrome-os-partner:55210
BUG=chrome-os-partner:55250
TEST=boot on kevin, verify that 'tpmc block' and 'tpmc pplock'
work as expected:
- pplock is possible after block
- pplock and block succeed both for enabled and disabled PH
- block locks FW index
- pplock disables PH
Change-Id: I32bff2b590a51315b11da361b97c684dcce8ab36
Reviewed-on: https://chromium-review.googlesource.com/362772
Commit-Ready: Andrey Pronin <apronin@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
And nuke all the underlying code that is unused once those APIs are
gone. These APIs are not used by any project in ToT, having been
superseded last year by the vboot2 APIs.
No functional changes to live code, just lots of deletes.
CQ-DEPEND=CL:347414
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build samus
Change-Id: I05ac752d74d1343dd03600b1c5e6ed22822e2802
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347257
Warning like this:
utility/bmpblk_utility.cc: In member function 'void vboot_reference::BmpBlockUtil::load_yaml_config(const char*)':
utility/bmpblk_utility.cc:104:61: error: format '%ld' expects argument of type 'long int', but argument 2 has type 'std::vector<std::basic_string<char> >::size_type {aka unsigned int}' [-Werror=format=]
printf("%ld image_names\n", config_.image_names.size());
^
utility/bmpblk_utility.cc:108:59: error: format '%ld' expects argument of type 'long int', but argument 2 has type 'std::map<std::basic_string<char>, vboot_reference::ImageConfig>::size_type {aka unsigned int}' [-Werror=format=]
printf("%ld images_map\n", config_.images_map.size());
^
utility/bmpblk_utility.cc:119:61: error: format '%ld' expects argument of type 'long int', but argument 2 has type 'std::map<std::basic_string<char>, vboot_reference::ScreenConfig>::size_type {aka unsigned int}' [-Werror=format=]
printf("%ld screens_map\n", config_.screens_map.size());
^
utility/bmpblk_utility.cc: In member function 'void vboot_reference::BmpBlockUtil::pack_bmpblock()':
utility/bmpblk_utility.cc:597:70: error: format '%ld' expects argument of type 'long int', but argument 3 has type 'std::basic_string<char>::size_type {aka unsigned int}' [-Werror=format=]
current_offset, it->second.compressed_content.length());
^
utility/bmpblk_utility.cc:609:59: error: format '%ld' expects argument of type 'long int', but argument 3 has type 'std::basic_string<char>::size_type {aka unsigned int}' [-Werror=format=]
current_offset, config_.locale_names.size());
^
Technically, C++ container::size_type is slightly different than size_t, but I
think %zd should work fine.
BRANCH=none
BUG=none
TEST=`USE="-minimal" emerge-kevin vboot_reference`
Change-Id: I9d0b22818714cad2ad7e95557df7837c91c2b0f7
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362621
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change replaces all calls to the old vboot1 SHA library with their
vboot2 equivalents.
This is the first in a long series of changes to move the core vboot kernel
verification into vb2, and the control/display loop out to depthcharge.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build samus firmware and boot it
Change-Id: I31986eb766176c0e39a192c5ce15730471c3cf94
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/344342
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Let's use an earlier version of CL 360944 that relies on the
global flag to decide if the platform authorization is to
be used.
As it turned out, we can't read NVRAM with empty
password authorization if platform hierarchy is still enabled
(as it is in firmware), so we keep platform authorization for
firmware, and use empty password only for userland utilities,
like tpmc.
BRANCH=none
BUG=chrome-os-partner:55531
TEST=Run 'initctl stop trunksd; tpmc read 0x1008 0xd" on
kevin, verify that it returns the right output.
Change-Id: Ic878ebde9086e803d2487d90c55c0f19001cf94b
Signed-off-by: Andrey Pronin <apronin@google.com>
Reviewed-on: https://chromium-review.googlesource.com/362520
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Some scripts call 'tpmc setbgloballock' or 'tpmc block'. For tpm2
it should be equivalent to pplock, i.e. perform rollback protection
actions: writelock for NVRAM firmware index and disable platform
hierarchy.
BRANCH=none
BUG=chrome-os-partner:55210
TEST=run 'tpmc block' on kevin, check that it attempts pplock
Change-Id: I51fae6bd111cf3ff3c1dfbed7441868abad8fc15
Reviewed-on: https://chromium-review.googlesource.com/361381
Commit-Ready: Dan Shi <dshi@google.com>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Build a special version of TPM Lightweight Command Library in
libvboot_host for TPM2. Create the framework for implementation, stub
functions for now. libvboot_host is used by tpmc and other user-space
utilities that talk directly to tpm bypassing trunks/trousers.
BRANCH=none
BUG=chrome-os-partner:54981
BUG=chrome-os-partner:55210
TEST=Boot on kevin, verify that 'tpmc read' works.
Change-Id: I4cc41028041193041defc319687697eb9edb1f3e
Reviewed-on: https://chromium-review.googlesource.com/358623
Commit-Ready: Andrey Pronin <apronin@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Add a new crossystem value "battery_cutoff_request" to indicate that
next reboot should cut-off battery and shutdown during firmware stage.
This request is primarily for factories to ship devices in an safe
state. Previously we have done same thing by running "ectool battery-cutoff"
but that creates a problem which "ectool" (and the one to request for
cut-off) must live in developer mode while the device must be shipped
in normal mode. The mode transition was solved by setting
"disable_dev_request=1", but that flag is may get lost on x86 systems
(having NV storage in CMOS) when the battery is cut-off .
From the experience from Ryu, such settings (dev mode transition and
battery cut-off) should be done together inside firmware execution so we
can create a new flag, battery_cutoff_request, to finalize device
properly.
BRANCH=none
BUG=chromium:601705
TEST=emerge-chell depthcharge vboot_reference chromeos-bootimage
crossystem battery_cutoff_request=1
# Unplug AC adapter
reboot
# See device rebooted and then shutdown immediately.
# Press power button and system won't boot.
# Attach AC adapter and now system boots.
CQ-DEPEND=CL:337596,CL:338193
Change-Id: I73ccae15b337cd65786106646546c67c155b8fa6
Reviewed-on: https://chromium-review.googlesource.com/337602
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Kernel TPM patches from 4.x moved /sys/class/misc/tpm0 to /sys/class/tpm/tpm0.
Support both paths in this utility.
BUG=chromium:573368
BRANCH=none
TEST=untested, not sure if this utility is still used.
Change-Id: Ib81476eee4c9de921502a3a47f6990b9e6b1968b
Reviewed-on: https://chromium-review.googlesource.com/320892
Commit-Ready: Bryan Freed <bfreed@chromium.org>
Tested-by: Bryan Freed <bfreed@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This flag will be used by the firmware updater to indicate that RO
software sync should be attempted.
BUG=chrome-os-partner:48703
BRANCH=None
TEST=make runtests
Change-Id: I42090ac47da45c724e66334648ab447ad3c21178
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/320621
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I don't even know what this is. It seems to have marked some kind of
debug buffer provided by H2C BIOS on pre-Daisy Chromebooks and has not
been touched since it was copied in here when crossystem was first
added. I can't find any references in our codebase so I doubt anybody
would miss it. Let's remove it so the '(error)' fields returned there on
any modern Chromebook stop confusing our vendors.
BRANCH=None
BUG=chromium:551715
TEST=Built for Falco and Jerry.
Change-Id: Ie2baec536b50bb192eb4cd3e48df212cce53561a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311346
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
This field doesn't seem to be used for anyone and it keeps adding work
for people trying to bring up new platforms. If we ever needed something
like this again, we'd probably prefer to have it in mosys now anyway.
Let's get rid of it.
BRANCH=None
BUG=chromium:551715
TEST=Built for Falco and Jerry.
Change-Id: I6b96e255968fdd22a345d4a75bfdc1e79d3f5896
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311345
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
In developer mode, this option will make the system try to boot into
a legacy OS first after the 30 second timeout. This removes the need to
press a key during boot to try legacy mode and the need to remove the
write protect screw to boot legacy as default.
BUG=chromium:310697
BRANCH=none
TEST=make runtests
Change-Id: I9a9f64c14ad015e21d08eec36e8fc187189cd2f2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304077
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When a TPM goes from the disabled state to the enabled state, it must
reboot after being enabled, before it can be initialized. In vboot1,
TLCL was part of vboot and this was handled internally. In vboot2, the
caller must set a context flag, so that vboot can decide whether to
allow the reboot, or whether to go directly to recovery mode. This
check is necessary to handle the following cases:
1) The device is booting normally, but the TPM needs a reboot. This
should simply reboot, without going to recovery mode.
2) The device is booting in recovery mode, but the TPM needs a reboot.
If this is the first time it asked us, allow the reboot.
3) The TPM asked for a reboot last time, so we did. And it's still
asking. Don't reboot, because that runs the risk that whatever is wrong
won't be fixed next boot either, and we'll get stuck in a reboot loop
that will prevent recovery. Boot into recovery mode.
Add a new NvStorage bit to track whether the TPM requested a reboot on
the previous boot. That's better than what we did in vboot1, where we
used a special recovery request. Vboot1 couldn't track getting stuck in
a reboot loop in normal mode, only in recovery mode. The new code can
catch both.
BUG=chrome-os-partner:45462
BRANCH=ryu
TEST=make runtests
Change-Id: I2ee54af107275ccf64a6cb41132b7a0fc02bb983
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/300572
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is useful for testing different configurations without repeatedly
reflashing the firmware, e.g.
# stop tcsd
# tpmc pcr 0
0000000000000000000000000000000000000000
# tpmc pcrextend 0 c42ac1c46f1d4e211c735cc7dfad4ff8391110e9
# tpmc pcr 0
865aedd337518e56f648440b81b4cbd9359fdff3
<reboot and try another value>
BUG=none
BRANCH=none
TEST=manual
Change-Id: Ie5814ca2a3a5cf5a0eaf0ffee0385315db09bf25
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289009
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
The sw_wpsw_boot was made for some feature that was almost never completed, and
only makes sense on Baytrail platforms. To prevent confusion we should address
that in the crossystem description.
BRANCH=none
BUG=chromium:508269
TEST=make test
Change-Id: I1fbc7a0e9e8c1f8503ae8ae9dfb6e80c8da892e3
Reviewed-on: https://chromium-review.googlesource.com/284425
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
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>
