The documentation claims the -A option shows the raw 64-bit attributes
field when in reality it only shows the high reserved 16-bits. Change
the docs to match the code.
BUG=chromium:644845
TEST=vboot_reference unittests pass
BRANCH=None
Change-Id: If163896ddbca0dc27ac8205db313031e73a68fd7
Reviewed-on: https://chromium-review.googlesource.com/382431
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Most of the cmd funcs had the same logic copied & pasted multiple times
over. Unify them into a common header.
BUG=chromium:644845
TEST=precq passes
TEST=passing invalid args to some funcs is caught
BRANCH=None
Change-Id: Ib7212bcbb17da1135b2508a52910aac37ee8e6cd
Reviewed-on: https://chromium-review.googlesource.com/382691
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In CL:378661 we removed dev_firmware* from tests/devkey but that also makes
futility unit tests to fail.
This changes signing test scripts to first check if dev_firmware* keys exist,
and only use it (and test ZGB signing results) if available.
BRANCH=none
BUG=chrome-os-partner:52568,chrome-os-partner:56917
TEST=make runfutiltests; make runtests;
add dev_firmware* back; run tests again and success.
Change-Id: If42c8404baf183edf5c8dbeadf537efa8ad571ec
Reviewed-on: https://chromium-review.googlesource.com/381151
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Another in a long series of refactoring changes to replace old vboot1
code with its vboot2 equivalent. Futility changes only; no change to
firmware.
BUG=chromium:611535
BRANCH=none
TEST=make runtests
Change-Id: I7be813b82820674e975db13d5e540e49bdea028d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366057
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
These have been superseded by their vboot2 equivalents. No firmware
changes; host-only.
BUG=chromium:611535
BRANCH=none
TEST=make runtests
Change-Id: I36b5d3357767f32489efb7e480049620dcc0fce4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363970
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
If given a malformed file with an invalid algorithm, futility could
dereference null when looking up the algorithm names.
BUG=chromium:643769
BRANCH=none
TEST=make runtests
Change-Id: I26d1312b8bf2eec8d806664708676daa9f36fa58
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380522
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The dev_firmware* was created for legacy devices having different RW
firmware - A for devmode and B for normal, like Alex and ZGB.
All other Chromebooks, including the CR48, were not doing that.
Signer scripts relied on checking if RW A/B are equivalent to decide if
they should select <dev_firmware* for A, firmware* for B> or <firmware*
(normal) for both A and B>. This worked for a long time until Skylake
family joined.
Skylake FSP has some limitation that we have to execute code in-place,
which leads to making RW A != B (due to addresses and offsets), and
triggers signer to incorrectly use dev_firmware*.
The production images are using keyset folders on signerbot, which only
Alex/ZGB keyset folders have dev_firmware*; so the images for Skylake
boards are signed correctly. But for people running firmware related
tests using tests/devkey keyset, for example
platform/dev/fm_and_key_version_test_prep.sh, having dev_firmware* in
devkey may produce incorrect output.
There is currently no easy way for signer scripts to figure out if the
image should use dev_firmware or not except looking into keyset folder.
Since Alex and ZGB are pretty old and no one plans to run key change
tests anymore on them, the recommended solution is to remove
dev_firmware.* from devkeys folder.
BRANCH=none
BUG=chrome-os-partner:52568
TEST=platform/dev/fm_and_key_version_test_prep.sh -b sentry -i \
/tmp/chromiumos_test_image.bin -f 8530.69.0 -s /tmp/image.bin -v \
Google_Sentry.7820.156.0
Change-Id: Ief37dd482875efc8e808460f3ad00041b5f3b3a2
Reviewed-on: https://chromium-review.googlesource.com/378661
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
mount-encrypted needs to be aware of TPM ownership status, and
will also want to issue a read lock for the early access NVRAM
index.
BRANCH=none
BUG=chromium:625037
TEST=mount-encrypted shows ownership at boot with kevin
Change-Id: I42f43f91d892137e1c46c7cacd88e3b749ce7f04
Reviewed-on: https://chromium-review.googlesource.com/366443
Commit-Ready: Andrey Pronin <apronin@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Several files were changed to own by root instead of the original owner
in the squashfs image. This has caused problem to boot Android.
TEST=./sign_official_image with local keys, extract system.raw.img and
override device copy. Able to launch ARC.
BUG=b:29915721,b:30919855
Change-Id: Ic2595c99cbb7f7c2a2c543612a368681220cb3d9
Reviewed-on: https://chromium-review.googlesource.com/372312
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Victor Hsieh <victorhsieh@chromium.org>
When we return early from the release check, we leaked the mount point.
This could in turn cause issues with data syncing and hash calculation.
BUG=b:30891460
TEST=None
BRANCH=None
Change-Id: I7a40007e371b8e64ca7e8210ad9121dc1a4bcf9f
Reviewed-on: https://chromium-review.googlesource.com/370739
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
sign_android_image.sh is the main script that signs the image. It makes
similar changes to an image like the Android official signing tool
(sign_target_files_apks.py) does, but more Chrome OS specific.
TEST=./sign_official_build.sh recovery recovery_image.bin \
../../tests/devkeys/ out_img
TEST=Same above but with a recovery image without Android image.
Android signing was skipping.
TEST=Same above but with a M53 image. Android signing was skipped.
TEST=Unpack the image and diff the before and after. Looks correct.
BUG=b:29915721
Change-Id: I0ae5f0ad8d2b05e485d60262558517ea563bf527
Reviewed-on: https://chromium-review.googlesource.com/366794
Commit-Ready: Victor Hsieh <victorhsieh@chromium.org>
Tested-by: Victor Hsieh <victorhsieh@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
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. Make the detection
architecture-independent.
BUG=chromium:632303
TEST=emerge-cyan vboot_reference and test binary on QEMU and HW
TEST=emerge-veyron_minnie vboot_reference and test binary on HW
BRANCH=none
Change-Id: I076eb9838a3b724ded0cfded9fb8d8a5392631c8
Reviewed-on: https://chromium-review.googlesource.com/368650
Commit-Ready: Nicolas Norvez <norvez@chromium.org>
Tested-by: Nicolas Norvez <norvez@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
This refactors futility and the host library to use only vboot 2.0 APIs
to create and verify keyblocks.
BUG=chromium:611535
BRANCH=none
TEST=make runtests
Change-Id: Ia3cc1e24971b94f01bcb4890c8666a3af6f84841
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356129
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Some of the vboot 2.0 and 2.1 functions call common code that currently
lives inside the vb2.1 host library. To be able to use vboot 2.0 code
in futility, we always need to include the 2.1 sources.
BUG=chromium:611535
BRANCH=none
TEST=make runtests
Change-Id: Ib01622fa462d0bceda1e6041b5e3395ee7c2f94f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356127
Reviewed-by: Daisuke Nojiri <dnojiri@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>
This replaces all calls to vboot1 VerifyFirmwarePreamble() with
equivalent vb2.0 functions. No effect on ToT firmware, which already
uses the vboot2.0 functions.
BUG=chromium:611535
BRANCH=none
TEST=make runtests
Change-Id: I5c84e9ed0e0c75e2ea8dbd9bfcde0597bc457f24
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/349322
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Before the fix, unmarshal_u32 returned only 16 bits of the value.
BRANCH=none
BUG=chrome-os-partner:55210
TEST=boot on keving, verify that 'tpmc getvf' correctly returns
the 'orderly' flag (bit 31 of a 32-bit flags value)
Change-Id: I182abdd78a6bdcbc21fe631492559099caeb934f
Reviewed-on: https://chromium-review.googlesource.com/362994
Commit-Ready: Andrey Pronin <apronin@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Futility needs to link against both vboot1/vboot2.0 and vboot2.1
functions. This was easy in the past because it did (vboot1 +
vboot2.1) and there's no overlap.
In replacing vboot1 function calls and structs with vboot2.0, now there
are symbol collisions between vboot2.0 and vboot2.1. For example, both
of them use a struct called vb2_signature, but the structs are defined
differently. Functions which operate on those structs also overload.
Rename the vb2.1 structs to start with vb21_ instead of vb2_. Do the
same for vb2.1 functions which operate on vb2.1 data.
BUG=chromium:611535
BRANCH=none
TEST=make runtests
Change-Id: I24defd87cbd9ef64239faf1a8e98ab2372d27539
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347458
Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
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>
I see warnings like this when building with USE=minimal (the default):
Package yaml-0.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `yaml-0.1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'yaml-0.1' found
That's because we don't have a yaml dependency for the USE=minimal
build, yet we still unconditionally call `pkg-config --libs yaml-0.1`.
Let's move the pkg-config calls into 'ifeq' block where they're actually
used.
BRANCH=none
BUG=none
TEST=`emerge-${BOARD} vboot_reference` both with and without USE=minimal
Change-Id: I96a59848ee970abacbe4cc3c56bb35c7cf552f63
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362620
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>
RollbackFwmpRead() assumed that a uint8[] array on the stack would be
aligned sufficiently for typecasting to struct RollbackSpaceFwmp and
accessing its members.
This was true on x86 (where unaligned accesses work fine) and probably
harmless on other platforms (since RollbackSpaceFwmp is
__attribute__(packed). But it's cleaner to switch to using a union of
the buffer and struct, since that will provide the proper alignment.
BUG=chromium:601492
BRANCH=baytrail and newer platforms
TEST=make -j runtests
Change-Id: I97077923ab5809c68510cbd382541bf2827aba6b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362087
Commit-Ready: Dan Shi <dshi@google.com>
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>
In TPM2 case, NVRAM must be read with empty password
authorization in tpmc, since platform hierarchy is
disabled by firmware or trunksd for rollback prevention.
Since all NVRAM indices are now defined with
AUTHREAD, switch to empty password authorization from
platform authorization for all NVRAM reads in Tlcl.
BRANCH=none
BUG=chrome-os-partner:55210
BUG=chrome-os-partner:55251
TEST=Run 'initctl stop trunksd; tpmc read 0x1008 0xd" on
kevin, verify that it returns the right output.
Change-Id: Ifb72ff5080a4ac5f8d63b5c0713e5bb184f176ca
Reviewed-on: https://chromium-review.googlesource.com/360944
Commit-Ready: Dan Shi <dshi@google.com>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This allows properly detecting an armv7l host architecture and setting
the right ARCH value so that e.g. crossystem can build fine.
BRANCH=none
BUG=none
TEST=Build host_stuff on an armv7l machine
Change-Id: I6a6ac74477eff41e73eca671d9dac229888c4e77
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://chromium-review.googlesource.com/360160
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Julius Werner <jwerner@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>
The firmware needs to lock the kernel rollback index before starting
up the kernel. The TPM2_NV_WriteLock command is used for that.
We also want to limit the amount of control the user space apps have
over TPM. With TPM1.2 it was achieved by deasserting physical
presence. TPM2 specification allows to achieve the same goal by
disabling Platform Hierarchy, which is active out of reset.
BRANCH=none
BUG=chrome-os-partner:50465
TEST=verified that all commands succeed and chrome OS boots up fine.
Change-Id: Ia5893460e0b29f1945cb2aae45a5f10b08fe1ed1
Reviewed-on: https://chromium-review.googlesource.com/358351
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
