Now that vb2_shared_data / vb2_context provides all the same data to
lower-level kernel verification code that cparams did, stop passing
cparams down to those functions.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I86eb1801ee96d8b56404b74843a8d09e3122567f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852814
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The region API was a way for firmware and kernel verification to get
at various blocks of caller-provided data. In practice, we only used
it internally as a way to get at parts of the GBB. Prune it down to
access only the bits of GBB we still need, from the buffer we already
know we have.
In the long run we should use the same vb2ex_read_resource() API that
vb2 firmware verification does, but that should be done in a follow-up
CL since it'll need to be coordinated with support in depthcharge.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I5715cb8d88274164a1a73ed4a56bbd93af46f9bf
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852798
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Currently, firmware verification uses entirely vb2 structs, including
vb2_shared_data. This goes through an ugly translation to the old vb1
VbSharedData to pass it to depthcharge. The vboot kernel verification
maintains an equally ugly translation back to the vb2 struct
internally.
Eventually, we want to get rid of all that and use vb2 all the way
down to what crossystem picks up from the OS.
But before we can do that, we need to finish translating kernel
verification code to use the new vb2 structs. This is a step on that
path, using vb2_shared_data equivalents where present and hiding the
old vb1 shared data struct as a member of vb2_shared_data so at least
the vboot functions don't need to pass around cparams to get at it.
This will be followed by more CLs which convert more vboot internals
to use vb2 structs directly, and eventually coreboot/depthcharge CLs
which pass the vb2 structs from firmware verification directly to
kernel verification.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I5df8ce81ba3c3ac3f2cb4229db5461757cd89d8d
Reviewed-on: https://chromium-review.googlesource.com/852856
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Remove the old vboot1 vboot_nvstorage library (VbNv*() functions) and
use the vboot2 library (vb2_nv_*()) instead. This is needed in
preparation for moving to 64-byte records; no sense in implementing
that change twice...
Should be (better be) no change in system behavior.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
compare output of crossystem before/after change (should be identical)
Change-Id: I10f9975b0824263064b9a74a3c6daadcecc085d3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/794732
This just adds the kernel_max_rollforward field to the nvstorage
libraries and crossystem. The firmware does not use it yet; that's
coming in a subsequent CL.
16 of the fields's 32 bits are taken from unused bytes of the kernel
field. This has no effect on existing usage.
BUG=chromium:783997
BRANCH=none
TEST=make runtests
Also manual testing. In a root shell:
crossystem kernel_max_rollforward --> Should default to 0
crossystem kernel_max_rollforward=0xfffffffe
crossystem kernel_max_rollforward --> Should be 0xfffffffe
(Note that setting it to 0xffffffff is indistinguishable from the
-1 value that the crossystem library uses to indicate error, so
0xffffffff isn't actually usable as a max rollforward limit. But
0xfffffffe is, and if we ever get so close to the limit that we
need to use 0xffffffff, something has already gone horribly wrong
with our versioning strategy...)
Change-Id: I008f412e6ed3c0b59beb9881268585af69d1ff2e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/765572
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add tpm_lite library support for the IFX specific TPM_FieldUpgrade
subcommand "FieldUpgradeInfoRequest2". Expose this via tpmc so it can
be used from shell scripts.
BRANCH=none
BUG=chromium:728130
TEST=Builds and tpmc ifxfieldupgradeinfo prints plausible results.
Change-Id: Ie58ebccef7fe90f7fca65d7cd9c78e1f16f9f29a
Reviewed-on: https://chromium-review.googlesource.com/562772
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
The sw_wpsw_boot field only ever worked correctly on some platforms. It
also isn't used anywhere in the codebase (only other reference is a
comment about how it doesn't always work in factory_installer.sh), and
it's no longer clear what it was meant for in the first place
(b/35510092 hints at needing it for some planned feature that was never
implemented). Let's get rid of it to avoid confusing people.
If userspace tools need to know the software write-protect state, they
can instead run flashrom directly. For feedback reports, this output is
already included in the "verified boot" section.
BRANCH=none
BUG=chromium:508269,chromium:742685
TEST=none
Change-Id: I8975b1e2c8e604b4cb48d092c13b923b4db2d207
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/575389
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Replace commands using gbb_utility by the new 'gbb' futility command.
BRANCH=none
BUG=None
TEST=USE=test emerge-$BOARD vboot_reference
Change-Id: I8c1547d295a955373413482509a33964b0e0c06f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/538442
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This also adds the required tests (keys, testcases), and some
additional tests in vb2_rsa_utility_tests.c that were not
added when 2048-bit exponent 3 support was added.
BRANCH=none
BUG=chromium:684354
TEST=make runtests
Change-Id: I56d22302c2254ef500b9d2d290a79d8c8bc39942
Reviewed-on: https://chromium-review.googlesource.com/449060
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This cleans up the vboot functions which handle display so they don't
need to pass it around. Eventually, it'll be absorbed by vb2_context.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build_packages --board=reef chromeos-firmware; boot reef
Change-Id: I58169dfd37abe657f9b9aa339cc72ffa398329e0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414288
Reviewed-by: Shelley Chen <shchen@chromium.org>
Passing the vb2 context around allows using more of the vb2 functions in
future changes, and prepares for a future where we directly use the
context as it was set up in firmware verification.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I8efa606dbdec5d195b66eb899e76fdc84337ad36
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404997
Reviewed-by: Shelley Chen <shchen@chromium.org>
Provide 'phase_enforcement' field that indicates if a
system should have its full security features enabled while
in the factory. The backend implementation currently is only
for x86 using chromeos_acpi.
On reef:
$ grep ^ /sys/devices/platform/chromeos_acpi/GPIO.*/*
/sys/devices/platform/chromeos_acpi/GPIO.2/GPIO.0:4
/sys/devices/platform/chromeos_acpi/GPIO.2/GPIO.1:1
/sys/devices/platform/chromeos_acpi/GPIO.2/GPIO.2:10
/sys/devices/platform/chromeos_acpi/GPIO.2/GPIO.3:INT3452:00
BUG=chrome-os-partner:59951
BRANCH=None
TEST=Tested on reef with accompanying coreboot patches and flipping
internal pulls to see the correct setting.
Change-Id: Id5401d795cff8874a038f2456121549713a11237
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/418899
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
When some of the space re-creation procedure failed, chromeos-tpm-recovery
should exit with non-zero value and not saying TPM is successfully recovered.
However, there are few known issues:
- 0x1009 is not needed in TPM2.
- The space is not created in TPM2.
- tlcl does not support define spaces with policies yet (crosbug.com/p/59594).
As a result, we want to return failure only if writing any of the two
spaces (0x1007, 0x1008) fails.
This change also revised chromeos-tpm-recovery so it won't exit with unbound
variable error due to early exit without having daemon_was_running variable.
BRANCH=None
BUG=chrome-os-partner:60099
TEST=For boards with TPM and TPM2, do:
build_image --board $BOARD factory_install;
Boot factory install shim, select 'I' and get TPM recovered.
Change-Id: I3f79b02cdf77ac61cf1361033c489604dcd603f2
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/412543
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add command for printing TPM version: 1.2 or 2.0. The command works
even when trunksd/tcsd is running and /dev/tpm0 is busy, so it can
be used to first determine which TPM we are dealing with, and then
select the right name of the daemon to stop based on that.
BUG=none
BRANCH=none
TEST=run 'tpmc tpmver'
Change-Id: Ib8db81ff2af6dc6b0d5aecf30e2688a908b5c3d3
Reviewed-on: https://chromium-review.googlesource.com/410703
Commit-Ready: Andrey Pronin <apronin@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
LoadKernel() was a big function which did everything from looping over
partitions on a drive to loading the data within them to calling the
low-level verification functions on that data. Split it apart into more
manageable chunks. This also reduces indentation of the inner parts of
the code, whic increases readability.
No outwardly-visible functionality changes.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: Iea79e70163f5d9f1a9d0d897e4a9bacc925a742d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404919
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
When some of the space re-creation procedure failed,
chromeos-tpm-recovery should exit with non-zero value and not saying TPM
is successfully recovered.
BRANCH=None
BUG=None
TEST=manually: chromeos-tpm-recovery
Change-Id: Id898c11adacd0ab38de2481cace23ca37deaec9c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/410467
Reviewed-by: Julius Werner <jwerner@chromium.org>
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>
