This new recovery reason will instruct the calling firmware in
vboot_select_and_load_kernel to reboot the device (under the assumption
that training of memory has already been performed by the firmware). On
seeing the return code VBERROR_REBOOT_REQUESTED, calling firmware should
perform a reboot.
BUG=chrome-os-partner:59352
BRANCH=None
TEST=make -j runtests successful
Change-Id: I110a735e612665cb2378bd71ca01a111edaf58e3
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407656
Reviewed-by: Randall Spangler <rspangler@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
Bit 2 in the GPT partition attributes has been allocated as the legacy
bios boot (equivalent to the "active" or "boot" flag in MBR). If we
try to boot images on newer x86 systems, syslinux dies because it can't
find any GPT partition marked bootable.
Update the various parts of cgpt add & show to manage this bit. Now we
can run:
cgpt add -i 12 -B 1 chromiumos_image.bin
And the EFI partition will be marked bootable.
BUG=chromium:644845
TEST=vboot_reference unittests pass
TEST=booted an amd64-generic disk image via USB on a generic laptop
BRANCH=None
Change-Id: I78e17b8df5b0c61e9e2d8a3c703e6d5ad230fe92
Reviewed-on: https://chromium-review.googlesource.com/382411
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
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
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>
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>
The marshaling code is a port of the coreboot patch
https://chromium-review.googlesource.com/353915. The only supported
commands at this time are NV_read and NV_write.
The tlcl layer includes functions necessary to satisfy compilation
requirements of rollback_index.c, functions to lock spaces and clear
TPM are not yet implemented, they just report being invoked.
The missing functions implementation is coming, but even without it it
is possible to boot Chrome OS with firmware and kernel rollback
counters maintained in the TPM NVRAM.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with depthcharge patches applied kevin/gru boards boot into
chrome OS with rollback counters read from/written to TPM2
Change-Id: I29fe9069d7c37c33d354f36c93bda15d439bf74f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356753
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The latest TPM specification uses different command codes, command
structures and return codes.
Let's put definitions for different TPM versions into different
include files.
CQ-DEPEND=CL:357831
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied kevin/gru boards boot into
chrome OS with rollback counters read from/written to TPM2
Change-Id: Ie13696d4e5098a4ea5e338e84334d257e5c704a7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356751
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds RW firmware support for the optional firmware management
parameters TPM space.
System-level tests require CL:339262 to add cryptohome support.
BUG=chromium:601492
BRANCH=baytrail and newer platforms
TEST=make -j runtests
Or better, COV=1 make, and then make sure all new code is covered.
Change-Id: Ifaf644c80809552d5961615be6017c2a332a034b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/339234
This patch makes cgpt aware of a special "IGNOREME" GPT header signature
string that may appear in either the primary or the secondary GPT and
cause cgpt (and other cgptlib clients) to completely ignore that GPT. It
will continue to function correctly for all other purposes (using the
data from the non-ignored GPT), but never write any data back to the
ignored GPT.
BRANCH=None
BUG=chrome-os-partner:52595
TEST=unit tests
Change-Id: I7e53542385ae9d8d24dc25b75e91f4ff4917f66f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/340072
Reviewed-by: Nam Nguyen <namnguyen@google.com>
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>
In order to support slots, we need to update behavior of
GptUpdateKernelWithEntry so that:
1. Invalid - Marks kernel entry as invalid
2. Active - Marks kernel entry as active
CQ-DEPEND=CL:336906
BUG=chrome-os-partner:51807
BRANCH=None
TEST=Compiles successfully "sudo emerge vboot_reference" "emerge-smaug
vboot_reference". "make -j runtests" successful.
Change-Id: If248b3c6bdd23d03cb1dd24f4e21cacef5cc3f26
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/335942
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Allow the AP to sync and verify the EC read only image after updating
the rewritable image.
BUG=chrome-os-partner:48703
BRANCH=none
TEST=manual
1. Update EC to a new version
2. rebuild EC code
3. Update AP firmware
4. Reboot and check that the RO image is updated after the RW image is
updated.
CQ-DEPEND=CL:319213
Change-Id: I774ef25320103f20d8c7d1c180a220dd0819c04d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/320614
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change will be used to support EC-RO software sync by allowing for
access to the readonly region of firmware. Currently only the writable
section is accessed by vboot using VB_SELECT_FIRMWARE_A and B.
BUG=chrome-os-partner:48703
BRANCH=none
TEST=built on jerry and check that the RO hash can be read and the image
can be updated.
CQ-DEPEND=CL:319185,CL:320425,CL:320598
Change-Id: Ic3942d86b65da3123798cfd11a78056f5dab6699
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/319213
Reviewed-by: Randall Spangler <rspangler@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>
Add a new post-EC software sync API VbExEcVbootDone() to take actions
which normally need to happen after EC verification / sysjump.
BUG=chromium:537269
TEST=Manual on Glados. Set CHG_MW thresh to 20000, BAT_PCT to 50. Verify
that LIMIT_POWER host event is set until Zinger negotiates to 20V. Also
verify that we do not proceed with boot when Donette is plugged.
BRANCH=None
CQ-DEPEND=CL:307885,CL:309523
Change-Id: I77e6000aa8a44e3aca4fb5982e5b5f5191774989
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307952
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
VbExGetLocalizationCount is a callback function which is supposed to
return the number of screen locales supported by VbExDisplayScreen.
After this change, we still try to get the number of locales from GBB
first but when it fails, VbExGetLocalizationCount is called. The error
code from VbGbbReadBmpHeader will be masked, similarly to the error from
VbDislayScreenFromGBB.
BUG=chromium:502066
BRANCH=tot
TEST=Tested on Samus. make runtests
Change-Id: I04ef8bf1ea02b1aaa05e65673b57bcea1932d8b0
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304376
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change makes VbDisplayScreen read the last saved locale from nvram
and pass it to VbExDisplayScreen so that it can draw locale dependent
screens.
BUG=chromium:502066
BRANCH=tot
TEST=Tested on Samus. make runtests.
CQ-DEPEND=CL:304382,CL:306100,CL:306110
Change-Id: I9782ec5a8a9f8393998aa8a0d64e88ad1809233b
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304375
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>
In the new recovery process, a user will see 'broken' screen
instead of 'remove' screen, where usb stick presence is no longer
detected. A user instead has to hit esc+refresh+power to proceed
to recovery mode.
BUG=chromium:501060
BRANCH=tot
TEST=make runtests
Change-Id: Icd511c1ca892628b96befbb0a34c2c84b881c857
Reviewed-on: https://chromium-review.googlesource.com/304404
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
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>
1. Change offset 8 to hold all misc settings (fastboot, boot_on_ac
detect) instead of only fastboot settings.
2. Add flag to hold state of boot_on_ac_detect (If set to 1, AP should
start booting as soon as AC is connected in off-state).
BUG=chrome-os-partner:41680
BRANCH=None
TEST=Compiles successfully. make runtests successful.
Change-Id: I64b3fc69bd52cbcaf5899c953ccafa2e81b5b8a5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/289900
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
When one of GPT headers is invalid the corresponding partition table
is not loaded and corresponding pointers in GptData are NULL.
GptRepair will try to memcpy one entries table to another which
results in SIGSEGV.
This change fixes it by freeing and then reallocating bad copy of
partition table. This potentially fixes problems which would occur
if two tables have different size.
Change that initially introduced this problem by not always allocating
secondary_entries:
https://chromium-review.googlesource.com/223800
TEST="cgpt repair" works where it previously didn't
TEST=make runtests
BUG=brillo:1203
BRANCH=none
Change-Id: Ibb2fcf33faa5ba157b0865d04c90ee3f26eee113
Reviewed-on: https://chromium-review.googlesource.com/276766
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Andrey Ulanov <andreyu@google.com>
Tested-by: Andrey Ulanov <andreyu@google.com>
When linking vboot_api_kernel4_tests, there are two VbBootNormal()
available, the gcc chooses the one in vboot_api_kernel4_tests.c and
the test passes, the clang chooses the one in vboot_api_kernel.c and
make the unittest fail. This CL makes the one in vboot_api_kernel.c
a weak symbol so that clang can choose the one in
vboot_api_kernel4_tests.c
BUG=chromium:498469
BRANCH=none
TEST=CC=x86_64-cros-linux-gnu-clang FEATURES='test'
emerge-amd64-generic vboot_reference
Change-Id: Ibcb78ee055fc9485dbc2bcc1d1cf98144a1a3b64
Reviewed-on: https://chromium-review.googlesource.com/276504
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Yunlian Jiang <yunlian@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
This can be used by implementations that want to request vboot to
favor a particular kernel entry for booting without affecting the
checks for rollback protection and image verification.
CQ-DEPEND=CL:274716, CL:274932, CL:275171
BUG=None
BRANCH=None
TEST=Compiles successfully. make -j runtests successful.
Change-Id: I6a4600020354f5d4118c17f083c353c2585c4181
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/274558
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
Trybot-Ready: Nicolas Boichat <drinkcat@chromium.org>
Add support for functions to request unlock and lock of devices in
response to fastboot oem unlock/lock commands. Unlock operation is
equivalent to enabling dev mode and lock operation is equivalent to
leaving dev mode. It is the responsibility of the caller to ensure
that user confirmation is obtained before unlock/lock operations.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully and fastboot lock/unlock operations work as
expected on smaug. Added tests to ensure lock/unlock operations are
covered. Verified using make -j runtests.
Change-Id: Ibafe75abdd1202473009208a414f3996d537db4f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/273182
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
When the lid is closed and external power is applied
the system may boot and shut down faster than required
for the OS to determine that things were alright.
In timed charging setups this led to systems ending up
to consider the current version broken because it "failed"
repeatedly.
Remain generic about the reason for not counting boots
since there may be more situations in which we want to
handle the situation optimistically.
BRANCH=none
BUG=chromium:446945
TEST=none
Change-Id: Iea350e3c98d5c00156da682e52c90a882ba017c0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249150
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This API allows fastboot boot from memory command to verify that the
image loaded in memory is signed properly using recovery keys. Thus,
only officially signed recovery images can be booted using fastboot
boot command in recovery mode.
However, if GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP is set, then
this routine will not perform any check and return okay for any image
sent by fastboot boot.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully. With GBB override for FASTBOOT_FULL_CAP
set any signed image is allowed to boot. With FASTBOOT_FULL_CAP not
set, then only officially signed image is allowed to boot. (make -j
runtests successful)
Change-Id: I78028853bd1ad09d3c610a687f327560557d5681
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/272696
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Add a new flag to nvstorage for controlling fastboot capabilities
offered in firmware in dev-mode. By default, value of this flag would
be ignored in normal mode. Thus, when fastboot-based recovery is
entered from normal mode, only limited capability would be available
in firmware.
After switching to dev-mode, this flag can be set automatically by
user script after performing the wipe or it can be set manually using
crossystem. When fastboot-based recovery is entered from dev mode and
this flag is set, it will provide full fastboot capability in the
firmware.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully for smaug. make runalltests successful.
Change-Id: I761a9ab304dd90f0b73081acc9ce1f8d9052325f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/271369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
And add a vb2_digest_buffer() call which produces the hash of a buffer
all in a single function call. That function actually already
existed, but was in a unit test file rather than in the library
itself. It's a small function, so adding it won't increase the size
of the library significantly - or at all, on platforms which compile
with -ffunction-sections.
This allows coreboot to reuse this SHA library for hashing CBFS
entries and file data. All it has to do is #define
NEED_VB2_SHA_LIBRARY and then #include "vb2_api.h".
BUG=chromium:482652
BRANCH=none
TEST=make -j runtests
Change-Id: Ice2d0929324b58b2665f3989b5b887225f6ef61e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/269523
Reviewed-by: Julius Werner <jwerner@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>
Some Chrome OS devices do not allow to login even in developer mode,
as they do not have display/keyboard and sshd is not part of the
Chrome OS image. Even enabling developer mode on those devices is very
involved (requires taking the device apart and is guaranteed to take
long time).
We still want to allow the end user to control those devices in dev
mode. The solution is enabling the ability to boot from the USB stick
when the device transitions from normal to developer mode.
A simple way to do it is to set the NVRAM flag, which allows USB boot.
The flag is set on normal=>dev transition only, and only on those
devices where it is configured (as discovered by invoking
VbExGetSwitches with the appropriate parameters).
BRANCH=storm
BUG=chrome-os-partner:38303
TEST=tested with the corresponding depthcharge patches
Change-Id: I5fa58963256598cde3b534f5250101fba6042f8c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264187
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@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>
Kernel preamble flags are set by the signer for passing hints about
the image. Read these flags from the preamble and pass it back to the
caller in kparams structure.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=Compiles and boots to kernel prompt for both CrOS image and bootimg.
Change-Id: I07a8b974dcf3ab5cd93d26a752c989d268c8da99
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/245951
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
