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>
If a platform does verification of memory init then it must be careful
to use the same slot for resume that it booted from. This is
accomplished by adding a context flag to indicate this is an S3 resume
and that vboot should treat it differently than a normal boot.
When this flag is set then the same slot that was booted is read from
VBNV and re-used for the resume path, without adjusting any try flags.
If this slot is B then the related context flag is set.
This will allow the firmware updater to update the other (non-booted)
slot and set flags indicating that on the next boot the updated slot
should be tried, while still allowing suspend/resume to work with the
existing firmware slot.
This assumes that the last tried slot was successfully booted, which
should be a safe assumption since the system was able to boot and then
suspend. It isn't reliable to check last_fw_result for "success"
status because that status is only set some time after boot when
chromeos-setgoodkernel calls chromeos-firmwareupdate --mode=bootok
and so it may still report a status of "trying" on resume depending
on how soon after boot the suspend happened.
It also avoids setting the vboot flag indicating that a slot choice
was made in order to avoid altering the try counter on failure since
this is explicitly not attempting to boot the new slot.
BUG=chromium:577269
BRANCH=glados
TEST=manually tested on chell:
1) ensure that booting from slot A resumes from slot A.
2) ensure that booting from slot B resumes from slot B.
3) do RW update while booted from slot A (so the flags are set to try
slot B) and ensure that suspend/resume still functions properly using
current slot A.
4) do RW update while booted from slot B (so the flags are set to try
slot A) and ensure that suspend/resume still functions properly using
current slot B.
Change-Id: I500faef2b5d19a02f32839976354abf6d551c9f6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/328812
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vboot needs to track the currently displayed screen so when it needs to
change the locale or display the debug overlay it knows which screen to
redraw. Currently only the legacy path is doing this so change the new
path to update the current screen if it is successfully drawn.
BUG=chrome-os-partner:49766
BRANCH=glados
TEST=boot on glados in dev mode, hit tab and ensure screen does not go black
Change-Id: I4a2bf028275db57b2d0469fc1cb574e871820713
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/324549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For x86 systems, which resume through the boot reset vector, to
implement vboot verification of the memory init code one needs
check that the slot chosen on the resume path is the same as
the original boot path. That check is done by storing the
resulting hash of the slot. However, vb2api doesn't export
the resulting hash from vb2api_check_hash(). Thus, provide
a variant which saves the resulting digest in the supplied
buffer.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
Change-Id: Ic20be2024afedabc2d8bc767f1b794376348523c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/323460
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The VBOOT_OPROM_NEEDED flag is used for EC software sync when the
VBSD_EC_SLOW_UPDATE flag is set.
After a successful EC software sync vboot requests a reboot to disable
graphics but it is not clearing the VBNV flag first. With vboot1 this
was getting cleared as a side effect of calling VbInit in normal mode.
BUG=chrome-os-partner:49560
BRANCH=glados
TEST=Enable EC_SLOW_UPDATE on chell and test EC software sync in normal
mode and ensure that it reboots and does not do graphics init if the
update is successful.
Change-Id: I2aa0c4c3b1ad357a5b8ddc14539e264a1f5b76b2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/322731
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>
New devices have Depthcharge render vboot screens by calling
vboot_draw_screen. Thus, display initialization and backlight control should
not be duplicated. This patch prevents VbDisplayScreen from initializing
display and controlling backlight when vboot is rendering screens using GBB.
BUG=chrome-os-partner:43706,chromium:502066
BRANCH=tot
TEST=Tested on Glados
Change-Id: I50cd2decb7065af96779601b12f0fbf2554ff6ed
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312749
Reviewed-by: Aaron Durbin <adurbin@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>
FASTBOOT_FULL_CAP set
This change allows developers to boot dev-signed boot images in
unlocked mode if DEV_BOOT_FASTBOOT_FULL_CAP is set in VbNvStorage or
GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP is set.
BUG=chrome-os-partner:47002
BRANCH=None
TEST=Compiles successfully. make -j runtests
Change-Id: I56e3879594da1b57051dfe242ff347ac970c96bb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/309606
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When a user hits esc+refresh+power to start recovery, the true recovery
reason will be lost after reboot. (It would always look like
VB2_RECOVERY_RO_MANUAL.) This patch makes VbBootRecovery save
the reason in the subcode area before entering the new 'broken' loop.
BUG=chromium:501060
BRANCH=tot
TEST=test_that -b veyron_jerry suite:faft_bios
Change-Id: Ib536daa0633721bfc975381782d348f122b3d337
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307586
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>
In recovery mode, the TPM may be bad / corrupt. This prevents access to
the soft developer switch stored in secdata. But it should not prevent
setting dev mode via GBB or context flags. Those flags may be set
during manufacturing or testing, and override the contents of secdata
anyway.
BUG=chrome-os-partner:45511
BRANCH=ryu
TEST=make runtests
Change-Id: I242714528203cc7cf78a714c660b7f8bbd0e04d0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/300621
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@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>
Ryu will store a hash of the GBB root key in a struct inside its boot
block. Add a vb2_ryu_root_key_hash struct for that.
If 'futility gbb_utility' is used to set the root key, also look for a
root key hash struct and fill it in. No error if not found, because
this needs to work on other platforms where the struct is not present.
This way, we don't need to change the signing scripts.
Added a --roothash option which can be used to check if the root key
hash is found, and if so, whether it's empty, valid, or invalid.
BUG=chromium:511405
BRANCH=ryu
TEST=manual
Take any existing image.bin.
cp image.bin image.orig
gbb_utility --roothash image.bin
- ryu root hash not found
Extract the root key
gbb_utility -k rootkey.bin image.bin
- exported root_key to file: rootkey.bin
Now, append a blank ryu root hash struct to it
echo '0000000: 5274 4b79 4861 7368 0100 0000 3000 0000' | xxd -r >> image.bin
echo '0000000: 0000 0000 0000 0000 0000 0000 0000 0000' | xxd -r >> image.bin
echo '0000000: 0000 0000 0000 0000 0000 0000 0000 0000' | xxd -r >> image.bin
Nothing is set yet
gbb_utility --roothash image.bin
- ryu root hash is unset
Setting the root key also sets the root hash
gbb_utility -s -k rootkey.bin image.bin
- import root_key from rootkey.bin: success
- calculate ryu root hash: success
successfully saved new image to: image.bin
See, it verifies
gbb_utility --roothash image.bin
- ryu root hash verified
Now, append a bad ryu root hash struct to it
cp image.orig image.bin
echo '0000000: 5274 4b79 4861 7368 0100 0000 3000 0000' | xxd -r >> image.bin
echo '0000000: 0001 0000 0000 0000 0000 0000 0000 0000' | xxd -r >> image.bin
echo '0000000: 0000 0000 0000 0000 0000 0000 0000 0000' | xxd -r >> image.bin
See, it fails
gbb_utility --roothash image.bin
- ryu root hash does not verify
Make sure the library doesn't contain the magic string
strings `which futility` | grep RtKyHash
(should be no output)
Change-Id: Ib46f93cac0f2b532bada4b187ae48efcf4926702
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/286237
Reviewed-by: 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 allows the caller to load the kernel partition and then pass it
to vboot for verification, rather than having vboot assume the kernel
partitions are all on a block storage device.
Next up, APIs for the caller to parse partition information from a GPT
(yes, that's cgptlib, but we'll make it more easily callable by
depthcharge).
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I388085c7023f4c76d416f37df0607019bea844ac
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/275646
Reviewed-by: Daisuke Nojiri <dnojiri@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>
VbVerifyMemoryBootImage
Do not use values from the header or preamble until it is known to be
good.
BUG=None
BRANCH=None
TEST=Compiles successfully and VbVerifyMemoryBootImage returns early
for images with bad values in header.
Change-Id: Ic026f49292a139e0a04c2556ca9fa62ff277b18f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/274141
Trybot-Ready: 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>
This patch reintroduces a vb2_secdata->struct_version check similar to
the one that was removed in CL:244846. The CRC is not a reliable way to
detect zeroed buffers, so this check helps vboot fail earlier and more
clearly in certain situations.
BRANCH=kitty,smaug,storm,veyron
BUG=chrome-os-partner:40778
TEST=make runtests. Rebooted Jerry with 'mem w 0xff7601b0 0xfdb9', saw
that recovery reason was now 0x2b (VBNV_RECOVERY_VB2_SECDATA_INIT).
Change-Id: Ic4376d127e6d14d4ef9c2f53c83090040ca4cb68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274138
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@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>
These are slightly more complex than the firmware versions, because
they need to deal with developer-signed keyblocks and keyblock flags.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I682c14ddfe729984f2629dfbe66750e5cd5ab75e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272541
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This is necessary for the next change, which adds keyblock hash checking.
Also clean up some other assorted comments, and move the diagnostic
check of root key to see if it's the checked-in one earlier in
firmware preamble validation so it's closer to where the root key is
loaded.
No functional or higher-level API changes; just shuffling around code
under the covers.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: Ibc3960a4d882dc2ad8684e235db4b9d066eac080
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272223
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This also checks that the bootloader and vmlinuz headers, if present,
are within the signed part of the kernel blob; the vboot1 routines
didn't do that. That wasn't harmful at firmware boot time because the
vboot1 routines would only load as much data as was signed, but in
vboot2 loading the kernel data is the responsibility of the caller so
we need to check.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I73eb4831e5d3d7a642b6cb85cb55857d87fcc0af
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270797
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>
Looks like the DISABLE_FW_ROLLBACK_CHECK GBB flag (0x200) was forgotten
in the vboot2 implementation. It's too late for Veyron now, but let's at
least fix it for future devices.
BRANCH=none
BUG=None
TEST=make runtests
Change-Id: I867f7aada28be3897efda73a6bdc3b0848c23dca
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271419
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
