We are not zeroing the free space properly before signing official images. This
patch fixes it by using fstrim instead of dd. More info can be found in
CL:751809.
BRANCH=none
BUG=chromium:780291
TEST=used sign_official_build.sh to sign two recovery images (these images produced <zero-space> file) with dev keys. Then generated delta update between the two new images. This time there was no <zero-space> file between the two images.
Change-Id: Ib97fb206f5c8bcfd97c43d075990c7fcdaad6f7e
Reviewed-on: https://chromium-review.googlesource.com/848237
Commit-Ready: Amin Hassani <ahassani@chromium.org>
Tested-by: Amin Hassani <ahassani@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
introduce get_gbb_flags.sh command to make automatic annotation
of power measurements easier.
Also, fix issue where declaring local variables on same line
as executing a command would obfuscate error code, thus not
triggering set -c and continuing execution.
https://github.com/koalaman/shellcheck/wiki/SC2155
Usage:
$ /usr/share/vboot/bin/get_gbb_flags.sh
[...]
ChromeOS GBB set flags: 0x00000329.
$ /usr/share/vboot/bin/get_gbb_flags.sh -e
[...]
ChromeOS GBB set flags: 0x00000329.
ChromeOS GBB set flags listed:
GBB_FLAG_DEV_SCREEN_SHORT_DELAY
GBB_FLAG_FORCE_DEV_SWITCH_ON
GBB_FLAG_DISABLE_FW_ROLLBACK_CHECK
GBB_FLAG_FAFT_KEY_OVERIDE
GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC
BUG=chromium:760267
BRANCH=none
TEST=manual
emerge-soraka vboot_reference
cros deploy <IP> vboot_reference
(on DUT)
/usr/share/vboot/bin/get_gbb_flags.sh -e
<same output as above>
Change-Id: Idb3b993706c03e7f2831eed2cef12a04b9469fea
Initial unit tests for detachable menu UI. With these tests, the
coverage is at 81.2% for lines for code and 87.5% for function
coverage. I will improve this to closer to 100%, but wanted to get
this in as it's still significantly better than before, which was 0%.
There are still a lot of tests in the code that are #if 0'd out
currently. I still need to go through an enabled/delete those.
BUG=b:65025540
BRANCH=None
TEST=run COV=1 make and make sure passes without errors
Change-Id: If17bfc24fb7f65deb3d2286cc39cdc311d8a6d93
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/830680
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Creating a unit test for testing the detachable UI menus. It'll
need access to some previously static variables that we will move
into this new file.
BUG=b:65025540
BRANCH=None
TEST=emerge-fizz vboot_reference with no errors
Change-Id: I249b152380dd55160e151506e00efd23bbbd1a5b
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/830679
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This removes utillib from the futility build and adds only the required
files from utillib to its build. Utillib includes arch-specific
components (required for crossystem) that only have a limited number of
supported architectures, which is undesirable for futility.
The number of archs that futility can run on is no longer restricted.
BUG=None
BRACH=None
TEST=Build futility and futility_s
Change-Id: Ia9ad2a72b374b5cc3d6004d36c0b7090dbcc97a2
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://chromium-review.googlesource.com/666625
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
This handles the aarch64 machine returned by uname as arm to allow
crossystem to build.
BUG=None
BRACH=None
TEST=Build futility and futility_s on ARMv8
Change-Id: I1d847568a36f47d084e7572b28e2603b9b6ec673
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://chromium-review.googlesource.com/785911
Reviewed-by: Julius Werner <jwerner@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
In Recovery Mode, when an USB key is inserted where valid OS is not
present, it shows "VB_SCREEN_RECOVERY_NO_GOOD" screen. But, once
removing that USB key, the screen should go back to INSERT screen
again.
This functionality was not working after the below Commit -
I2bab22fcbb0bb3cdfffe585eb633231ba8015fc3
This patch fixes this issue by assigning the current_menu as
"VB_MENU_RECOVERY_INSERT" every time when there is No Disk found.
BUG=none
BRANCH=none
TEST=Tested on Soraka to check that INSERT screen comes back once
Non-Valid OS Pendrive is removed from board.
Change-Id: I74efff562ba00a3e96b82ee158f9613f53c059b5
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/810824
Commit-Ready: Rizwan Qureshi <rizwan.qureshi@intel.corp-partner.google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
This patch allows a power button on a keyboard to shut down the system
when waiting for a user interaction at a firmware screen. The firmware
menu, which is implemented by vboot_ui_menu, shouldn't be affected.
BUG=b:70244028
BRANCH=none
TEST=Verify power button on Fizz can shut down the system at recovery
screen, broken screen, todev scree, and user confirmation screen using
a USB keyboard and a servo. Verify recovery button can confirm dev mode
transition. Run 'make runmisctests' successfully.
Change-Id: Icc7d7a774da19acac3d2938d5748ad2323ba4856
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/811444
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Depthcharge currently includes vboot_nvstorage.h directly, instead of
including only the API header files directly. Add 2nvstorage.h to the
list of headers which can be requested impolitely.
Also fix the definition of ARRAY_SIZE to match exactly what
depthcharge and coreboot provide, so that the compiler does not get
sad when it's included from both libpayload.h and 2common.h.
BUG=chromium:789276
BRANCH=none
TEST=make runtests; emerge-reef depthcharge coreboot
Change-Id: Idc0390eaf813c3079df1676781e8bf5bc9b46450
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/802176
Reviewed-by: Shelley Chen <shchen@chromium.org>
Previously, we didn't require any action on these legacy screens, so
didn't update current_screen when displaying these. Now, will be
adding language switching and debug display for these screens, so need
to keep track of them.
BUG=b:65470853, b:67371896, b:64400036
BRANCH=None
TEST=None
Change-Id: I2bab22fcbb0bb3cdfffe585eb633231ba8015fc3
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/676269
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=none
BRANCH=none
TEST=Upstream builder does not fail with uninitialized variable anymore like this:
firmware/lib/vboot_ui_menu.c: In function 'vb2_get_current_menu_size':
firmware/lib/vboot_ui_menu.c:255:15: error: 'temp_menu' may be used uninitialized in this function [-Werror=maybe-uninitialized]
*menu_array = temp_menu;
~~~~~~~~~~~~^~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Change-Id: Idb1690c7b0becf3556cad379160fe152707ae843
Reviewed-on: https://chromium-review.googlesource.com/777805
Commit-Ready: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
Kernel verification will now roll forward the minimum allowable
version in the TPM no farther than the kernel_max_rollforward setting.
Note that CL:765573 changes chromeos-setgoodkernel so it always sets
kernel_max_rollforward to 0xfffffffe when marking a kernel as good.
That ensures that firmware with this setting will behave the same for
now as existing firmware.
BUG=chromium:783997
BRANCH=none
CQ-DEPEND=CL:765573
TEST=make runtests
Manual testing:
crossystem tpm_kernvel --> print current kernel version in TPM
- Resign the kernel with a higher version
- Reboot
- Wait a minute for chromeos-setgoodkernel to run
crossystem kernel_max_rollforward=0
- Reboot
crossystem tpm_kernvel --> has not changed
- Wait a minute for chromeos-setgoodkernel to run
crossystem kernel_max_rollforward -> 0xfffffffe
- Reboot
crossystem tpm_kernvel --> has changed to the higher version
Change-Id: Ia32ecb7fa4078548cd311541ccbe120570cf1bc5
Reviewed-on: https://chromium-review.googlesource.com/765574
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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>
Previously, we were able to exit the initial recovery graphic with
either the volume up or volume down button. However, we would only
like the user to exit the screen when they know what they are doing,
we are making it so that they can only intentionally exit (with volup
+ voldown simultaneously pressed).
BUG=b:67371896
BRANCH=None
TEST=reboot into recovery and press volume up + volume down keys.
Make sure we exit to the recovery menu screen.
Change-Id: I7dfb4a0e42c8b88e9b075e886cea1adfe248246c
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/766847
Reviewed-by: Julius Werner <jwerner@chromium.org>
When develper mode is disabled (through FWMP), don't allow user to see
the dev warning screen. Boot straight to TO_NORM and disable the
cancel option. Basically, the user will only be able to enable OS
verification, power off, or change the language. There is also no 30
second timeout during bootup.
BUG=b:65595945
BRANCH=None
TEST=Force disable_dev_boot flag to 1 and ensure the TO_NORM menu is
displayed w/o a cancel option. Scroll through options to make
sure they work as expected. Make sure debug message is displayed
indicating dev mode is disabled. Wait > 30 secs to ensure
timeout doesn't occur.
Change-Id: I7d2bcd369694e886866f9dedff05d81a40f8270a
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/757115
Reviewed-by: Julius Werner <jwerner@chromium.org>
When futility replaces the old signature in the input file with a
new one, it assumes the signature is at the end of RW region. This
assumption is wrong for EC-EFS binaries because they place a
signature at each end of two EC_RW areas.
This patch fixes the issue by specifying the signature address via
'old_sig', which points to the (first) signature address regardless
of the input file format (EFS v.s. non-EFS, FMAP v.s. no FMAP).
BUG=b:66956286
BRANCH=none
TEST=Run
'futility sign --type rwsig --prikey key_ec_efs.vbprik2 ec.bin'.
Then run 'futility show --type rwsig ec.bin', which prints
'Signature verification succeeded.'
make runtests
Change-Id: I730fd31be640de3e9381f156d084162dd4093ba6
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/767596
The vboot1 library VbNvGet() / VbNvSet() functions use enum VbNvParam
(VBNV_*) constants.
The vboot2 library vb2_nv_get() / vb2_nv_set() functions use enum
vb2_nv_param constants.
Do not mix the two. In the one instance where this happens in the
current code, we get lucky, because VBNV_DEV_BOOT_FASTBOOT_FULL_CAP
and VB2_NV_DEV_BOOT_FASTBOOT_FULL_CAP evaluate to the same value, so
this was harmless. But fix that now so nobody else copy/pastes that
pattern for a param where this isn't true.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: I1facbe1d97591dc8b1e6b38717924b884949da57
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/764970
Reviewed-by: Julius Werner <jwerner@chromium.org>
1. Differentiate button codes for short press and long press of volume
up and volume down.
2. Add a new code for volume up-down combo press since it is expected
to be used for one of the firmware screens.
3. Treat volume down long press as Ctrl-D on developer screen.
4. Treat volume up long press as Ctrl-U on developer screen.
CQ-DEPEND=CL:756254
BUG=b:64992445,b:65013794
BRANCH=None
TEST=Verified that buttons work as expected on Soraka.
Change-Id: I5d443f43f785b973f3ff4aeaac52b152ed2fe0bd
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/757123
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch makes sign_official_build.sh resign ec.bin and store
signed RW copies in bios.bin if the original ec.bin contains
signed RW copies.
BUG=b:66956286
BRANCH=none
CQ-DEPEND=CL:738794,CL:*490792
TEST=sign_official_build.sh recovery recovery_image.bin \
~/trunk/src/platform/vboot_reference/tests/devkeys /tmp/out.bin
Change-Id: I73c7d8da7d8e2f770e5952d0124f8d43bb13e592
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/734295
CL:693008 changed check_ac_active so that we ask CR50 to verify EC
is in RO. While this is the right decision, on some platforms ECs
can't reset EC_IN_RW. This causes check_ec_active to set IN_RW
wrongly when EC is in RO after reboot.
This patch replaces VbExTrustEC with VbExEcRunningRW. If RW is
owned it may say it's in RO. Then, the software sync will proceed
and flash RW while the EC is running RW copy.
It also removes redundant checks for VbExTrustEC() when deciding
whether to allow developer mode to be enabled from the INSERT
screen. The INSERT screen can only be reached by manual recovery,
which resets the EC, we don't need to check again before going to
TODEV.
BUG=b:67976359
BRANCH=none
TEST=make runtests
Change-Id: Ide722146ca8683411dd9072a39387aa9531f6cfc
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/740878
This is not necessary anymore and rendering is taken
care of in depthcharge.
BUG=b:35585623
BRANCH=None
TEST=reboot and scroll through menus and make sure that
rendering is still good.
Change-Id: I078751014c8f84fb2ee403b6895e9dfa58e758d6
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/731114
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Let's use the actual command/path used to call make_dev_ssd.sh,
instead of hard-coding './'.
BRANCH=none
BUG=none
TEST=/usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
outputs a command that can just be copy-pasted:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 4
(instead of:
sudo ./make_dev_ssd.sh --remove_rootfs_verification --partitions 4
)
Change-Id: I903f94acc1fb310926b149c1e79e4017bf513e27
Reviewed-on: https://chromium-review.googlesource.com/737810
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Print a debug error and beep when user tries to enable normal mode
when FORCE_DEV gbb flag is enabled.
BUG=b:67828898
BRANCH=None
TEST=Boot up with gbb flag 0x8 enabled. Select "Enabled OS
Verification" and select confirm. Should see error message
printed and a beep. Confirm switching to normal mode
screen will not appear.
Change-Id: Ic02558eb4a86555cebc9c1cd6972d0f0600b4ff1
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/730415
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Depthcharge currently asks EC whether recovery was requested manually
or not without verifying EC is in RO or not. If EC-RW is compromised,
recovery switch state can be spoofed.
This patch makes Depthcharge check EC_IN_RW to determine whether EC
is in RO or not. Only if it's in RO and it says recovery button was
pressed at boot, we proceed to the recovery process.
All other recovery requests including manual recovery requested by a
(compromised) host will end up with 'broken' screen.
BUG=b:66516882
BRANCH=none
TEST=Boot Fizz. make runtests.
Change-Id: I01d2df05fe22e79bbc949f5cb83db605147667b3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/693008
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Staff decided to leverage the key format of Hammer therefore this
script calls Hammer's one to generate a key pair and renames them to
key_staff*.
BUG=b:66889892
TEST=Run this script in the chroot and verify the generated key pair.
BRANCH=None
Change-Id: I73162efaba47a8c08336805130ced0be25ab262a
Reviewed-on: https://chromium-review.googlesource.com/688522
Commit-Ready: Marco Chen <marcochen@chromium.org>
Tested-by: Marco Chen <marcochen@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Android master puts that file at a different location, so use similar
logic to official signing script.
TEST="sign_android_image.sh passed locally for both caroline (NYC) &
caroline-bertha (master)."
BUG=b:65610114
BRANCH=none
Change-Id: If33bfbcaa7e6cff95f26ff26a91735c87880f3db
Reviewed-on: https://chromium-review.googlesource.com/686046
Commit-Ready: Garfield Tan <xutan@chromium.org>
Tested-by: Garfield Tan <xutan@chromium.org>
Reviewed-by: Victor Hsieh <victorhsieh@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
If the channel is missing or has whitespace, the test triggers
errors in the script because the test command has bad quoting.
BUG=None
TEST=script no longer fails on an empty lsb-release
BRANCH=None
Change-Id: Ic2e6ab91ca4ec10c298d122aee1f7f7236b52bf2
Reviewed-on: https://chromium-review.googlesource.com/680059
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
Nothing needs this, just something I noticed while debugging.
BUG=None
TEST=`ensure_sane_lsb-release.sh` no longer complains about comment lines
BRANCH=None
Change-Id: Ia39e6461db79a387cc59e5f88ec1216984bb4d28
Reviewed-on: https://chromium-review.googlesource.com/680058
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Selecting cancel from DEV_MENU should not set the selected_idx
to loc. It should be set to power off.
BUG=b:35585623
BRANCH=None
TEST=go to DEV_MENU, hit cancel and make sure that power off is
selected item
Change-Id: I8cae397c7174b5bd52a3a27736cd3d5a57412e63
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/667933
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=b:65546569
BRANCH=None
TEST=Boot into recovery, selection Disabled OS Verification.
Ensure that in next menu, Cancel is selected.
Also, setting default for TO_NORM menu to Confirm.
Change-Id: Ibf72ec15aa38b1b815be97a08cfe7c9ee2615390
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/665356
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add in check at TO_DEV menu screen to make sure that the navigation
keys (up/down, volup/voldown) are trusted. Beep when user tries to
use unstrusted keys (usb keyboard) in the TO_DEV menu so that the user
knows they're doing something wrong. USB keyboard return key will
still work in the TO_DEV menu.
BUG=b:65546569
BRANCH=None
TEST=test out using up/down keys in TO_DEV menu and make sure that
they are disabled and hear beeps.
Change-Id: Ifc7183c7ca35efaf079abb196a90ab7305380642
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/665355
Reviewed-by: Julius Werner <jwerner@chromium.org>
The auto update process (especially firmware updater) needs static vboot
utilitys but normal OS images, including recovery images, don't need
that. We should build both dynamic and static binaries at the same time
for images to choose what they need.
Currently only `crossystem` will build static version. And after this
change is merged:
(cd /build/reef/usr/bin; file crossystem*)
crossystem: ELF 64-bit LSB shared object
crossystem_s: ELF 64-bit LSB executable
(cd /build/reef/usr/bin; du -sh crossystem*)
40K crossystem
808K crossystem_s
BUG=chromium:764753,chromium:765499
TEST=emerge-reef vboot_reference
BRANCH=None
Change-Id: Ibd66c87bb44c5593767aeb710240e0165103f016
Reviewed-on: https://chromium-review.googlesource.com/668274
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
