| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes stdlib.h since otherwise size_t might not be defined.
BUG=none
BRANCH=none
TEST=fixed a compilation issue with coreboot
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I83e2b761d2d8e0d4899c9bdebf40190f1444cd8a
Reviewed-on: https://chromium-review.googlesource.com/199840
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium:327749
TEST=emerge vboot_reference
BRANCH=none
Change-Id: I627636d8433c0a8cdbd2c7b24cc405a41173658f
Reviewed-on: https://chromium-review.googlesource.com/199993
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Queue: Gaurav Shah <gauravsh@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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium:358418
TEST=emerge-mipsel-o32-generic vboot_reference now builds.
BRANCH=none
Change-Id: Ia1414dfdef00c5b22ed0971fad814ef761b32b86
Reviewed-on: https://chromium-review.googlesource.com/193050
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Queue: Gaurav Shah <gauravsh@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This complicates things in a number of ways, including making GDB not work
properly because it assumes the standard ABI in some places. Measurements
show that it doesn't really make much difference performance wise.
BUG=None
TEST=Built and booted with coreboot and depthcharge on link.
BRANCH=None
Change-Id: I7f004f8cf83b7c1a78ab12f814477504a5a5c28c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180874
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is some inherent latency between the time the USB root hub is
initialized and the time USB devices are detected. This can lead to a
situation where USB media is attached, yet not found when we do our
initial device poll. The device may be detected in subsequent polls, so
the media can be booted and no 'remove' screen will be displayed.
With this change, if no media to remove is initially found, a second
poll will be made after a 500ms delay. This will be enough time for USB
devices to be correctly detected in our test cases.
Also, it is necessary to change the unit test due to the fact that we
now call VbExDiskGetInfo twice before actually displaying any screen.
TEST=Manual on Monroe. Insert USB media and trigger recovery boot.
Verify 'remove' screen is seen, 'insert' screen is seen after removing
media, and system boots after re-inserting media. Also passes
vboot_reference unit tests.
BUG=chrome-os-partner:23840
BRANCH=Panther, Monroe
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia902c3a126588cd7ea618f2dbbca6b38d35d6ea0
Reviewed-on: https://chromium-review.googlesource.com/179757
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BayTrail systems have 3 banks of gpios. Therefore,
the Linux kernel exposes these 3 banks as 3 gpiochip
entries. The kernel driver expects the 3 banks to be
exposed with specific UIDs associated with a specific
banks. ChromeOS firmware maps gpios within a given
bank using the bank's MMIO offset. In summary:
Bank Type | UID | Offset
----------+-----+-------
SCORE | 1 | 0x0000
NCORE | 2 | 0x1000
SUS | 3 | 0x2000
BUG=chrome-os-partner:24408
BUG=chrome-os-partner:24324
BRANCH=None
TEST=Built. 'crossystem wpsw_cur' works correctly.
Change-Id: I251f86285ce9733f7ca90ed1ebef536f4fe5c07c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179513
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up until recently the x86 systems had a single contiguous
set of gpio numbers exported through /sys/class/gpio
as /sys/class/gpiochip<X> values. BayTrail systems have
3 sets of gpio numbers. Therefore, there needs to be a
translation/look-up function based on chipset. The existing
chipsets have a 1:1 mapping, but this patch lays the ground-
work for chipset-specific translation.
BUG=chrome-os-partner:24324
BUG=chrome-os-partner:24440
BUG=chrome-os-partner:24408
BRANCH=None
TEST=Built. Ran on Rambi.
Change-Id: I32bcd975aea421f86a0220ee30332f48fe727656
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179512
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BayTrail is a valid chromeos platform. Therefore, allow
it to be returned for 'platform_family'.
BUG=chrome-os-partner:24324
BUG=chrome-os-partner:24440
BRANCH=None
TEST=Built. 'crossystem platform_family' reports 'BayTrail'.
Change-Id: I8d0b835f5f40e7f34adb4f91bd974c428bbaf6da
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179511
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TEST=Built and booted Peppy. Ran flashrom from user space and
verified the EC firmware was updated after reboot.
CQ-DEPEND=CL:172651, CL:172652, CL:178324
BRANCH=none
BUG=chromium:325286
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ia73da70dbf3abb5ced48666e86715c8d24a431a0
Reviewed-on: https://chromium-review.googlesource.com/172635
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a VB_MAX_STRING_PROPERTY for callers that don't
want to guess at how big to make their buffers.
Additionally, it changes the size parameter to VbGetPropertyString()
from int to size_t.
BUG=None
TEST=compile the code
BRANCH=none
Change-Id: I22809d48e13b535593cb22a56444e2dcb27791a5
Reviewed-on: https://chromium-review.googlesource.com/175039
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=None
TEST=build update_engine with a change that uses the header.
BRANCH=none
Change-Id: Icbfe9be615a4f7f4078a0a0cde64324908dea2a7
Reviewed-on: https://chromium-review.googlesource.com/174428
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Querying "debug_build" allows the caller to determine whether the
image has requested debug, independent of the setting of the
dev_mode switch.
BUG=chromium:308678
BRANCH=none
TEST=use the new command option on both base and dev images
Change-Id: I369f26d75156f2e88d9f6f467efbf8f633e78bda
Reviewed-on: https://chromium-review.googlesource.com/174107
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In coreboot the architecture for our ARM platforms
is armv7. In order to have vboot_reference pick up the
right build parameters, map armv7 to arm.
BUG=none
BRANCH=none
TEST=lots more changes on coreboot needed for a reasonable
test. Right now coreboot compiles fine with ramstage
verification and this patch.
Change-Id: I64dad9be663b7bd7d80d138b3c49ae8f4699f01d
Reviewed-on: https://chromium-review.googlesource.com/170071
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add checks that the vboot library does not leak memory. This works by
tracking VbExMalloc() calls and making sure that they have an associated
VbExFree().
Adjust host_signature to use VbExFree() instead of free(), so that this
scheme works correctly for existing code.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=FEATURES=test emerge-peach_pit vboot_reference
Change-Id: I6ccccfbcc162fc43fb75862cd0eddad78ce8b18a
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of memset(pointer, 0, sizeof(pointer)), we should use
"memset(pointer, 0, sizeof(*pointer))".
BRANCH=none
TEST=Built successfully
BUG=None
Change-Id: I72e224188ccede1a1f83efa7fa3138e4a0ecd3b3
Reviewed-on: https://chromium-review.googlesource.com/167880
Reviewed-by: Luis Lozano <llozano@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Han Shen <shenhan@google.com>
Commit-Queue: Han Shen <shenhan@google.com>
Tested-by: Han Shen <shenhan@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.
Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.
Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.
The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.
The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.
The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.
BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference
Change-Id: If2b8bbe467fdbd643239d8d9b5d7aa98df4d286f
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167361
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 1d3c804b6b9d2ffb6953a7ee98fabfd548915ad7.
This patch breaks cbuildbot on internal paladins bots.
Change-Id: Icf7f9d9bbb56b092035888eaa3e249ffd23fac16
(cherry picked from commit 3a60335ebb1530e5fd9d5da3bc6214949bc59caf)
Reviewed-on: https://chromium-review.googlesource.com/167451
Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org>
Commit-Queue: Yoshiki Iguchi <yoshiki@chromium.org>
Tested-by: Yoshiki Iguchi <yoshiki@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.
Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.
Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.
The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.
The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.
The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.
BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference
Change-Id: I2c19e9dc2ed602d0642bbf4f7d27f79fe9fad873
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case of a TPM error, tpmc returns the TPM error code, which can
be greater than 255. In that case the error code is truncated.
Some error codes, such as TPM_E_RETRY, end with a zero byte,
resulting in a successful exit code. This is despicable.
BUG=chromium:234357
TEST=tested with exit codes < 255. Too hard to generate the others.
BRANCH=none
Change-Id: I891a5c0659c06aac778449e2a0a935c5f82ccdb8
Reviewed-on: https://chromium-review.googlesource.com/66885
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e4759b782dff166600dbbfac884462babb433fac.
The DEBUG flags changed something in futility's section layout and caused its
command searching mechanism to fail (we can verify that by running "dump_fmap"
command).
BUG=chromium:279645
TEST=emerge-link vboot_reference; /build/link/usr/bin/dump_fmap # success
BRANCH=none
Change-Id: Ie42a33aed3fdc0443f2a758e1216d86aea5c326d
Reviewed-on: https://chromium-review.googlesource.com/67015
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few places in the code through up warnings when building with strict
compiler flags. Correct these.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
Build with:
FEATURES=test emerge-peach_pit vboot_reference
and see that iot now succeeds. Warnings include:
host/arch/arm/lib/crossystem_arch.c: In function 'ReadFdtValue':
host/arch/arm/lib/crossystem_arch.c:93:8: error: ignoring return value of 'fread', declared with attribute warn_unused_result [-Werror=unused-result]
Change-Id: I765723636e5f8979b794925c7b610081b2849026
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At present the kernel tests produce valgrind errors since the GPT data is
sometimes accessed before it is read. This is unnecessary, so update the
code to avoid this.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
valgrind --leak-check=full ./build/tests/vboot_kernel_tests
See that we no longer get valgrind errors.
Change-Id: I9e9660e38a62a735cf01a37c2d81ddb5ab8b1528
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is still useful to build natively with debugging, particularly when
improving test code, so add this to the compiler flags in this case.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
'make DEBUG=1' in the vboot directory within the chroot. See that the test
executables are now build with debugging info and gdb has line number
information.
Change-Id: Icaedae67151883673525930e25cf8b1f30654339
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66172
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some functions of vboot are disabled for sandbox because sandbox could not
support them. This has changed, so remove the sandbox #ifdefs in the code.
Some printf() strings cause warnings on sandbox - mostly that uin64_t is
not 'long long' on a 64-bit machine. The existing format strings in U-Boot
do not seem to take account of this, so add casts to remove the warnings.
Also add a few more debug strings to make it easier to see what is happening
in the vboot flow.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
crosfw -b sandbox -V
See there are no warnings.
Change-Id: I86f90a693e4bd23fcacf6d48297dd32229348dd4
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65621
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "-p internal:bus=*" is now deprecated by "-p {host,ec}" because we may have
EC on SPI bus.
BUG=none
TEST=manually executed dev_debug_vboot and see correct output.
BRANCH=none
Change-Id: I6363c09c2ebf57812bf35b7db220303a2786db20
Reviewed-on: https://gerrit.chromium.org/gerrit/66321
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This tells the boot loader the number of firmware types that are supported,
so that it can declare arrays of that size.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
Build for pit, link, daisy
Change-Id: Ib10e559af29b8dfe78268eb6e0465a245427313e
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66095
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In many cases format strings in vboot_reference do not match their
parameters, which causes all kind of ugly results when examining debug
output.
Enforce proper format verification.
CQ-DEPEND=CL:65396
BRANCH=pit
BUG=none
TEST=manual
. compiled cleanly in vboot_reference, observed debug printouts
making sense.
Change-Id: I58d5ba1f9097ef9922fbaeb7a9946aadf5eb8617
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These function prototypes changed recently and the mocked driver is not
building any longer.
BUG=none
BRANCH=none
TEST=successful build with MOCK_TPM=1
Change-Id: Iaaf2d2c2883add7a478d7ee887b06e45c65e1bb2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65338
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a helper script intended for the signing servers to use to strip
out the /boot directory from images just before signing.
BUG=chromium:210352
TEST=Manually used to strip and image and validated the results.
BRANCH=None
Change-Id: I814522284143d8f90651e13000d428718aeca1e4
Reviewed-on: https://gerrit.chromium.org/gerrit/60828
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Don Garrett <dgarrett@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In several places the existing code assumes LBA, but was improperly converted
to use byte offsets, so multiply by the sector size to correct it and maintain
the same interface between MTD & GPT.
Also, since we will need to cgpt create on /dev/fts, which isn't a stat()able
device, allow providing the disk size on the commandline.
BRANCH=none
BUG=chromium:221745
TEST=make runtests; cgpt create -s 12345 on MTD image
Change-Id: Icc89a4505aba9a3dfc39b176a372f6e12d106aed
Reviewed-on: https://gerrit.chromium.org/gerrit/62675
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Albert Chaulk <achaulk@chromium.org>
Commit-Queue: Albert Chaulk <achaulk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add labels to MTD partitions and clean up some of the show code, adding more
info on the MTD prints and eliminating duplicated code.
BRANCH=none
TEST=make runtests & manual cgpt add -l "label"; cgpt show to verify labels
BUG=none
Change-Id: I59736128f394c2aca937a3a0bb5fc5d42b0149a9
Reviewed-on: https://gerrit.chromium.org/gerrit/63367
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Albert Chaulk <achaulk@chromium.org>
Tested-by: Albert Chaulk <achaulk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
firmware/lib/flash_ts.c: In function 'flash_ts_find_writeable_spot':
firmware/lib/flash_ts.c:180:5: error:
implicit declaration of function 'VbExDebug' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
BUG=None
TEST=`make` works
TEST=`make DEBUG=1` works
BRANCH=none
Change-Id: Id529ca885828ca38d5230f41f81d4b87395c5e65
Reviewed-on: https://gerrit.chromium.org/gerrit/59654
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's extremely helpful to know what a device's gbb flags are when
running vboot. It aids in debugging issues by providing more
information and context.
BUG=None
BRANCH=None
TEST=Built and booted. Checked log.
Change-Id: I663de6f617f0e8c74e2b2f3b7a2be63f4a9c020a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63489
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On MTD devices, don't always enable MTD mode - the installer needs to
be able to access both the GPT disk and the MTD disk, so only
enable it if we install to /dev/fts
BRANCH=none
BUG=chromium:221745
TEST=make runtests
Change-Id: I7688e6bc758ef47cfb9d468c1224ef43b2043d02
Reviewed-on: https://gerrit.chromium.org/gerrit/62662
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Albert Chaulk <achaulk@chromium.org>
Tested-by: Albert Chaulk <achaulk@chromium.org>
|