As we build features into futility, the standalone executables disappear.
Tests that invoke those executables will need to invoke futility instead.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I75230f6901aab8d978fa5d12505c243e1c90c938
Reviewed-on: https://chromium-review.googlesource.com/207926
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Replacing a few duplicated items with a single definition, removing a couple
of unnecessary/redundant dependencies.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: I31e78ae1e3810865e26c9c4937eb44222cbfa9d6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207741
This checks some additional cases where the FMAP is a bit messed up.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: Ic2b16bd8afdd1247d1f24c9f976d967764cadb73
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207719
This cleans up the Makfile and test scripts a bit, and adds a new test for
the builtin commands.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: Ibf5aa867d4dcabc0e46daac6633036b035c99ac8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207718
The alignment rules were complicated and not always correct. This change
sorts pointers instead of structures, and aligns the pointer table better.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: I16c4e9b777fffe7537127aba15413b54e8e0f0a4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207717
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There are a few utilities that print the full path of any file they open.
This isn't necessary, and it just has to be ignored when running regression
tests from different directories.
This just removes that extra noise.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: I4291bca7952a0d7371f8682b7d57545361c6341c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207619
Reviewed-by: Randall Spangler <rspangler@chromium.org>
A lot of functions were added some time ago, nominally to support keeping
the firmware in an MTD device that wasn't formatted with the GPT headers.
That work was never completed, so these functions aren't used anywhere.
We may want to resurrect this work at some future point. Until then, this CL
just moves some of the functions into an "unused" file.
BUG=chromium:231567
BRANCH=ToT
TEST=manual
All tests pass, all firmware and external repos build.
Change-Id: I420dd52d1cea0418cedf2f8e834c61145915f20c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207037
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We've been creating and linking against a library called "libvboot_host.a"
for two different reasons. The main purpose is to build the vboot_reference
tools found in the utility/ directory. But there are some external userspace
programs that would also like to use some functions in this library.
This change establishes libvboot_host.a as the library for use by external
userspace programs only, and creates a new libvboot_util.a library that's
only used inside this source tree to build the vboot utilities.
BUG=chromium:231567
BRANCH=ToT
TEST=manual
Build and run the local tests:
make runalltests
make clean
Build Link firmware and all the utilities:
emerge-link chromeos-base/vboot_reference \
sys-boot/depthcharge \
sys-boot/coreboot \
chromeos-base/chromeos-ec \
chromeos-base/chromeos-firmware-link \
chromeos-base/chromeos-cryptohome \
chromeos-base/update_engine \
chromeos-base/chromeos-installer \
chromeos-base/chromeos-login \
chromeos-base/verity
Build Lumpy utilities, which include the 32-bit cros_installer:
emerge-lumpy chromeos-base/vboot_reference \
chromeos-base/chromeos-login \
chromeos-base/verity \
chromeos-base/update_engine \
chromeos-base/chromeos-installer \
chromeos-base/chromeos-cryptohome
Change-Id: Ie81ff1f74a6356cb8fab7d98471139d7758c4f19
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207016
Reviewed-by: Randall Spangler <rspangler@chromium.org>
libvboot_host.a is needed by metrics, compiled in platform's gyp/ninja system.
All platform executables need to be position independent so we need
libvboot_host.a to be position independent too.
BRANCH=None
BUG=chromium:389742
TEST=Unittests.
TEST=Build vboot_reference and metrics, metrics compiles.
TEST=Build coreboot on a rambi, the compilation succeeds.
TEST=trybot run on daisy, link, duck, rambi and x86-mario.
Change-Id: I4b761d9435c35e3d3fcae2efc72fcaed7fc746a6
Reviewed-on: https://chromium-review.googlesource.com/206055
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Bertrand Simonnet <bsimonnet@chromium.org>
Commit-Queue: Bertrand Simonnet <bsimonnet@chromium.org>
Three symbols used by the standalone cgpt executable were being referenced
in the files used to create the external libvboot_host.a needed by non-vboot
userspace applications.
This cleans things up so those symbols don't have to be explictly defined
by other repos just to link with that library.
BUG=chromium:318536
BRANCH=ToT
TEST=manual
No new functionality, just code cleanup. Tested with
make runtests runfutiltests runlongtests
Change-Id: Ibc77fb9800c89d7109ebf38d4d6729f52665722f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205667
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The functions TlclLog() and TlclSetLogLevel() are declared in tlcl.h, but do
not appear anywhere else in the source. Let's not declare nonexistant
functions.
BUG=chromium:231567
BRANCH=ToT
TEST=make runtests
These never existed or did anything. They still don't.
Change-Id: Id6f0216d70b7b62d91486aba7d6cd996dc5f7d8d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205708
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Bill and I both added meanings for byte 1 bit 0x10. His changed
(NV_BOOT_BACKUP_NVRAM) landed first, so move the vboot2 bit to byte 2.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 make runtests
Change-Id: Ib7ff8da47d03f91cbeb729ca517c6315dfb4e6ac
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205408
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Compiling in the GBB magic number as is causes any tools that search for the
number to fail. This patch allows firmware to embed XOR'ed signature.
TEST=Booted Nyan in normal mode. FAFT:firmware_DevMode passes.
BUG=none
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Id18905a9969af3db24151e7c51332d0e94405108
Reviewed-on: https://chromium-review.googlesource.com/205416
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
When porting vboot2 to a platform, it's common to copy 2stub.c and
then start implementing APIs. Adding explicit errors makes it clearer
when an unimplemented API is called.
BUG=chromium:370082
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I1f412b7ed4b431dbdbdee5e33b27bf7206186918
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204960
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This constructs a test firmware using the old vboot signing utilities,
and then verifies it using vboot2 libraries. This ensures vboot2 can
read files signed by the current signing process.
BUG=chromium:370082
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Icc113c982e5ed99382a4592f9ab688784e853c8e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204561
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I'm breaking the last chunk of vboot2 into smaller pieces as I add
tests. This has the api-level routines actually called by depthcharge.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: Ic7c082fc5faa0b874b2fa5a15ebda7135dcafe0b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200151
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I'm breaking the last chunk of vboot2 into smaller pieces as I add
tests. This has the higher-level routines for verifying keyblock and
preamble.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I82da9542c8857a3f89a85f206c9f5aecadf94a79
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203501
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I'm breaking the last chunk of vboot2 into smaller pieces as I add
tests. This has a bunch of misc routines like the dev switch logic
and GBB header parsing.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I0f67400d9b59ec21ed5cc155a9b774fd37eb559b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203374
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Rather than leave the default set of keys in the firmware untouched
(which are dev keys), insert the first loem keyset we find. This is
for people who extract the bios.bin by hand and then blindly burn it
into their flash. This way they'll still get some valid loem keys.
It's not a great solution, but it's better than nothing.
BUG=chromium:381862
TEST=signed recovery image by hand w/loemkeys and looked at packed bios.bin
TEST=signed recovery image by hand w/devkeys and looked at packed bios.bin
TEST=signed recovery image by hand w/custom loemkeys and looked at packed bios.bin
BRANCH=none
Change-Id: I8db1e34d9f4d85be6edf81fecf79a72031571b01
Reviewed-on: https://chromium-review.googlesource.com/204262
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
The common.sh file already defines these variables/funcs, so drop them.
BUG=chromium:381862
TEST=`./create_new_keys.sh` created new keys correctly
BRANCH=none
Change-Id: Ie7f0f683d4971c188d4629b520938b4b65bb0a9f
Reviewed-on: https://chromium-review.googlesource.com/203685
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
With an loem keyset in a recovery shellball, we don't want to write the
rootkeys & vblocks to the firmware image directly. Instead, we'll put
them into a keyset subdir that the firmware updater will process later.
bios.bin
keyset/
rootkey.LOEMID
vblock_A.LOEMID
vblock_B.LOEMID
We still write the recovery key to the firmware image though as that is
shared between all the keysets.
BUG=chromium:381862
TEST=Ran against a recovery image with devkeys & loemkeys and checked shellball
TEST=`cbuildbot daisy-release` works
BRANCH=none
Change-Id: I6fc99c71e6c7dee25f7f9a466a97314ff750fda9
Reviewed-on: https://chromium-review.googlesource.com/203682
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Make ensure_no_nonrelease_files.sh stop grepping
/etc/session_manager_use_flags.txt for USE flags. Instead,
look for non-comment lines in /etc/chrome_dev.conf.
BUG=chromium:377301
TEST=manual: ran against images both with and without
extra config directives
BRANCH=none
CQ-DEPEND=I86d01f4a551433527bb434dc62c30fb44082f774
CQ-DEPEND=Ic030207840b6be79b51486d1706573241a01c08d
Change-Id: Iefeefd936dc7706ed74340edb6521621885bbe25
Reviewed-on: https://chromium-review.googlesource.com/203463
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Daniel Erat <derat@chromium.org>
Tested-by: Daniel Erat <derat@chromium.org>
Error codes reported by 2common.c are now very specific, and tests
verify the proper errors are reported.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I9480bd22b60ae339196c92918a8a984a9f05ac1a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202938
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Error codes reported by the aligment checks in common.c are now very
specific, and tests verify the proper errors are reported.
Changed args to vb2_member_inside() so I can force wraparounds.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: Ib135674e82005b76bce7a83a1f4a65a9c5296cf4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202937
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Error codes reported by the crypto and storage APIs are now very
specific, and tests verify the proper errors are reported.
More specific error codes coming to other files next, but I don't want
this CL to get too long.
This also changes test_common.c so TEST_EQ() reports mismatched values
in both decimal and hex, and adds TEST_SUCC() to test for a successful
return value.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I255c8e5769284fbc286b9d94631b19677a71cdd0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202778
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We use a few bytes of battery-backed nvram to save some flags across
reboots. However if the battery discharges completely, these flags are lost.
There aren't any security issues with that since they reset to safe values,
but some of the flags are used to configure how the system boots in
dev-mode.
If a dev-mode user has completely replaced ChromeOS with some other OS, then
she often needs to set the dev_boot_usb and/or dev_boot_legacy flags as well
in order to boot it using Ctrl-U or Ctrl-L. If the battery dies, then those
flags are cleared, and the only way to make the Chromebook boot again is by
going through recovery, which wipes the disk.
This change uses a new NV space in the TPM to back up some of the nvram
flags. These nvram fields will be backed up:
block_devmode
dev_boot_legacy
dev_boot_signed_only
dev_boot_usb
fwupdate_tries
loc_idx
Because writing to the TPM space is slow and limited to an unspecified but
finite number of cycles, we only back up the fields when specifically
requested by the new backup_nvram_request flag. This flag will be set by
crossystem whenever it is used to change any of the fields listed above. The
backup will be attempted at the NEXT boot (because the TPM is locked after
booting), and the backup_nvram_request flag will be cleared if the backup
was successfull.
Note that this CL is for Top of Trunk only. The firmware will create the
required TPM spaces on systems that have never been booted, but we don't yet
have a secure or reliable method to update existing systems.
FYI, on Link, determining that the TPM's backup NV space doesn't exist adds
about 6ms to the boot time. If it does exist, the backup_nvram_request flag
is cleared automatically so it won't check until it's set again.
BUG=chromium:362105
BRANCH=ToT (only!)
TEST=manual
Testing this is a long and involved process. Read on...
First, there are host-side tests for it. In the chroot:
cd src/platform/ec
make runtests
Second, to test on a completely NEW system that was first booted with a BIOS
that contains this CL, do this:
Enter dev-mode
Use crossystem to set values for the fields listed above
Confirm that "backup_nvram_request" is set to 1
Reboot
Use crossystem to confirm that "backup_nvram_request" is now 0
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Use crossystem to confirm that the backed up fields are still good, while
the others have been reset to default values
Switch to normal mode
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Look at the bios info in chrome://system to see what crossystem says
Confirm that the dev_boot_* flags are all 0, while the others are restored
Third, to set things up to test this on an existing system (I used Link),
you have update the BIOS, delete both the Kernel and Firmware NV spaces in
the TPM, then reboot so that the BIOS will create the Backup, Kernel, and
Firmware spaces. It will only do that if they're all missing.
Open it up, disable write-protect, attach a servo, etc.
Switch to dev-mode, log in.
Run make_dev_firmware.sh
Reboot in recovery mode, and insert a USB stick with a test image on it.
NOTE: In order to fiddle with the TPM, we'll *always* have to boot in
recovery mode, since that's the only time the TPM is left unlocked. That's
NOT the same as pressing Ctrl-U at the scary boot screen. The rest of
these steps assume you've booted in recovery mode and are running from the
test image on the USB stick.
Run
make_dev_ssd.sh --remove_rootfs_verification --recovery_key
Reboot (recovery mode)
Run
mv /etc/init/tcsd.conf /etc/init/tcsd.conf.disabled
Reboot (recovery mode).
Run "tpmc getvf". It should say
deactivated 0
disableForceClear 0
physicalPresence 1
physicalPresenceLock 0
bGlobalLock 0
Run "tpmc geto". It should say
Owned: no
Now you'll need to build the "tpm-nvtool" utility. In the chroot:
cd src/third_party/tpm/nvtool
make
Copy that to the DUT, in /usr/local/bin.
Now run
tcsd
tpm-nvtool --list | grep Index
You may see a number of spaces, but you should at least see these:
# NV Index 0x00001007
# NV Index 0x00001008
Run
tpm_takeownership
It will prompt you for two passwords (and confirm each one). Respond with
something you can remember like "google".
Run
tpm-nvtool --release --index 0x1007 --owner_password "google"
tpm-nvtool --release --index 0x1008 --owner_password "google"
Verify that it worked with
tpm-nvtool --list | grep Index
Power off.
Using servo, flash the new BIOS that has this CL in it.
Power on, normally this time (not recovery mode). If all goes well, it
should create the correct NV spaces and boot into the SSD. Copy tpm-nvtool
into this image too, and run
tpm-nvtool --list | grep Index
You should now see at least these spaces:
# NV Index 0x00001007
# NV Index 0x00001008
# NV Index 0x00001009
Now you're ready to test the backup/recover feature.
Change-Id: I00031fa0774720147327e2ae0f37e26b34b86341
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202138
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
This is the third of several CLs adding a more memory- and
code-efficient firmware verification library.
BUG=chromium:370082
BRANCH=none
TEST=make clean && COV=1 make
Change-Id: I3a5daa5438afc5598d3dfcf5a597ffb16eda8749
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200140
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is the second of several CLs adding a more memory- and
code-efficient firmware verification library.
BUG=chromium:370082
BRANCH=none
TEST=make clean && COV=1 make
Change-Id: I1dd571e7511bff18469707d5a2e90068e68e0d6f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199841
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is the first of several CLs adding a more memory- and
code-efficient firmware verification library. This CL adds the crypto
library (modified from firmware/lib/cryptolib) and unit tests for it.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I4240eab227bb197cacc6c8e7a6397127d74414a2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199578
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We'll try breaking this up into smaller pieces. This one's pretty
small - just the work buffer utility functions.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I4c417438053c155d6f7f9725552066e9b059951c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201141
Two changes here.
First are some failing assertions in tlcl.c. These have always failed, but
only when DEBUG=1, so no one noticed. I've opened a bug to find out why, but
it's blocking something else. We're refactoring anyway, so for now we'll
just comment around it.
Second is a null-pointer dereference in VbSharedDataSetKernelKey(). Again,
only when DEBUG=1.
BUG=chromium:379255
BRANCH=ToT
TEST=manual
cd src/platform/ec
\rm -rf build
DEBUG=1 make runtests
Change-Id: Ia5e0a742f75057b449f3c19b778c5d2f0408d7cd
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202303
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
The return value of VbExDisplaySetDimension should be handled as VbError_t,
which means we should print error message when it's not zero.
Also add the return code to debug message.
BRANCH=none
BUG=none
TEST=emerge-nyan coreboot chromeos-bootimage, enter recovery screen.
Not seeing error messages anymore.
Change-Id: Icafdfd933d799e8496fedcf1633339065c6962a3
Reviewed-on: https://chromium-review.googlesource.com/200679
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
For displaying GBB images on panels with different dimension, X86 has VESA mode
and VBIOS to scale automatically but ARM does not have such mode settings. If we
install a larger panel on ARM platforms, current firmware will render the
screens in left-top corner and leave black borders in right-bottom corner.
To render images correctly, vboot library has to send out the expected dimension
(similar to the VESA mode) so display provider can scale or shift images.
BUG=chrome-os-partner:28494
TEST=emerge-nyan vboot_reference
CQ-DEPEND=CL:199051,CL:199045
BRANCH=none
Change-Id: I6d60f755ca2bcbd3135631d7624a8a4a4cff68b1
Reviewed-on: https://chromium-review.googlesource.com/199043
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Currently, this does nothing. It just sets a flag that nothing looks at.
Don't get all wound up - we haven't abandoned our principles. This will
eventually be used to allow enterprise-enrolled customers to prevent
unauthorized use of developer mode in the Chrome OS devices that THEY OWN.
This is not Google deciding to turn a feature off, it's allowing the OWNER
to control the use of the feature. In some situations, the owner can be held
liable for what others do with the owner's equipment. This will help the
owner avoid those situations while their device is out of their immediate
control.
BUG=none
BRANCH=ToT
TEST=manual
Set the flag with:
crossystem block_devmode=1
Clear it with:
crossystem block_devmode=0
Retrieve the value ("0" or "1") like so:
val=$(crossystem block_devmode)
echo "the flag is $val"
or just test it directly like so:
if crossystem 'block_devmode?1' ; then
echo "devmode is blocked"
else
echo "devmode is allowed"
fi
It should be persistent across reboots.
Change-Id: I097f15b307e1c3a2a9db595e9495028a2eea6309
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197771
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
make_dev_firmware.sh calls resign_firmwarefd.sh, which extracts rootkey from
input image for checking VBLOCK firmware body size. As a result, we should
resign firmware before changing rootkey / GBB.
BUG=chromium:365738
TEST=Install Nyan/Peppy PreMP-signed firmware, run make_dev_firmware.sh, and
then boot in normal mode.
BRANCH=none
Change-Id: I45dbcacb40b7b77bbf89f1ba244bf7fb25f9ae27
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196521
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Early proto devices (for testers and developers) may have hardware write
protection enabled and software disabled. They can still flash SPI ROM in that
case, and no need to disable hardware WP switch.
BRANCH=none
BUG=chromium:341242
TEST=./set_gbb_flags.sh 0x39 # see WP messages.
Change-Id: Id320410795a162a009b80360c2225c7510337591
Reviewed-on: https://chromium-review.googlesource.com/186336
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
People trying to override GBB flags and not having write protection disabled may
corrupt whole RW section of firmware.
To avoid that, we should check write protection before starting to invoke
flashrom commands.
BUG=chromium:341242
TEST=./set_gbb_flags.sh 0x39 # Aborted on a write-protected system, as expected.
BRANCH=none
Change-Id: I6b2dcc75b87dc5ceace0d7caec62ded787b2b534
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185653
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@google.com>
It's possible for the AP to get updated and remove the RO-normal flag
without needing to update EC-RW firmware - for example, if it only
needs to update the BIOS. In this case, the EC doesn't need update,
but does need to jump to its RW firmware. But if the EC is already
booted RO-normal with jump disabled, it will refuse that request and
go to recovery mode.
The fix is simply to check if the request to jump to RW requires the
EC to cold-boot first, and pass through that error code to the caller.
BUG=chrome-os-partner:22617
BRANCH=none (affects all platforms, but only in this odd case, and this
is a change to the RW portion of the code)
TEST=pass new unit test which triggers this condition
Change-Id: Ia8d64dff784a9135ef23f6eb26bbca4ad9df57c3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170168
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Teach crossystem the tegra124 compatibility string so that it can identify the
platform for tegra124 based systems.
I called the platform Tegra5 to fit in with what seems to be the naming scheme
for the other Tegra SOCs.
BUG=chrome-os-partner:25355
TEST=Built and ran on nyan and saw the "platform_family" setting return Tegra5
instead of (error).
BRANCH=None
Change-Id: I1044f958ecdac37ad285fdc3d53e7bc36ca69315
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/184051
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
We don't allow ENTER from a USB keyboard as the confirmation
in the switch from normal to developer mode.
For devices that have a physical recovery button, we require
a recovery button press instead. For other devices, we
require that ENTER be pressed on the internal keyboard.
This prevents an "evil keyboard" attack in which a USB keyboard
(or other USB device pretending to be a keyboard) sends a
control-D/ENTER sequence shortly after every boot (followed
by more evil keys). In that situation, when users power-on in
recovery mode, they will be forced to dev mode even if it
was not their intention. Further attacks are easy at
that point.
TESTING. On a panther device:
1. powered on with recovery button pressed -> booted in recovery mode
2. pressed control-D on external USB keyboard -> got to ToDev? screen
3. pressed ENTER -> system beeped
4. pressed recovery button -> system rebooted in DEV mode
... all as expected
Also:
1. powered on with recovery button pressed and HELD recovery button
2. pressed control-D -> system beeped
BUG=chrome-os-partner:21729
TEST=manual (see commit message)
BRANCH=none
CQ-DEPEND=CL:182420,CL:182946,CL:182357
Change-Id: Ib986d00d4567c2d447f8bbff0e5ccfec94596aa7
Reviewed-on: https://chromium-review.googlesource.com/182241
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
