This was deleted in the previous commit and breaks building
with MOCK_TPM=1
BUG=chrome-os-partner:32698
BRANCH=all
TEST=build with MOCK_TPM=1
Change-Id: Ie437f9fb4c60161a95ca1cf992035858f02e3f19
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227220
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When GptLoad() fails to validate a header, it will not load the
corresponding entry array, and hence will not allocate memory. The
"*_entries" pointer then stay NULL. This CL checks for NULL pointer in
CheckEntries() in the same way that CheckHeader() does.
BUG=none
BRANCH=none
TEST=unittest
Change-Id: I9f72e843590fbcbcf90d55640f86c782446e8755
Reviewed-on: https://chromium-review.googlesource.com/226778
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
GBB header v1.2 adds a digest of the HWID string to the blob (and
maintains it when updated with the current futility/gbb_utility).
This CL causes VbSelectFirmware() to extend PCR1 with that HWID
digest (only for GBB header v1.2 and later, of course).
Tests are updated.
This also adds a "pcr" command to futility to help determine that
the change is working on the hardware (adds 4K bytes or fewer to
the size of the executable).
BUG=chromium:415714
BRANCH=ToT (and maybe others?)
TEST=make runtests, manual install on HW
To test on hardware, build and update a system with this change
(both the disk image and the RO firmware).
NOTE: The BIOS image must be built in a chroot that is using the
current version of futility. You may need to update your chroot
if your BIOS image still produces v1.1 GBB headers. Check with:
futility show <firmware_image.bin> | grep -B1 'digest:'
Boot the new system with a new test image, then follow these steps:
Read the BIOS:
# flashrom -r /tmp/bios.bin
Make sure the GBB has a valid digest for the HWID.
# futility show /tmp/bios.bin | grep -B1 'digest:'
HWID: SAMUS TEST 8028
digest: 4172d24f40bf72cc0ab8... <valid>
#
Extract only the sha1sum-sized part of the HWID digest:
# futility show /tmp/bios.bin | awk '/digest:/ {print $2}' | colrm 41
4172d24f40bf72cc0ab878b4c589b8fe9cf4405e
#
Simulate extending that value in a PCR using the futility "pcr"
command:
# futility pcr 4172d24f40bf72cc0ab878b4c589b8fe9cf4405e
PCR: 0000000000000000000000000000000000000000
+ 4172d24f40bf72cc0ab878b4c589b8fe9cf4405e
PCR: b6e5ffd2d898a7b15236ad22ca25f53ac1f40776
#
Finally, look at the value of PCR1. It should match the last line
of the futility pcr output:
# head /sys/class/misc/tpm0/device/pcrs | grep PCR-01
PCR-01: B6 E5 FF D2 D8 98 A7 B1 52 36 AD 22 CA 25 F5 3A C1 F4 07 76
#
Change-Id: I09cf855f1a24616cc1a9ddb676670edbc76827d2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226408
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For kernel NAND support, some vboot/cgptlib functionality is
needed from depthcharge. This patch moves certain function
declarations to a new header in firmware/include and puts
their definitions in a common place.
TEST=make runalltests passes and packages build
BRANCH=none
BUG=chromium:403432
Change-Id: Idd42b1f9f531651d78bb4afb80ca90c24aae93d9
Reviewed-on: https://chromium-review.googlesource.com/224996
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Daniel Ehrenberg <dehrenberg@chromium.org>
In order to display the slow EC update screen on x86 devices
in normal mode it is necessary to request a reboot where the
VGA Option ROM is loaded.
This needs a bit of plumbing to pass the OPROM_MATTERS and
OPROM_LOADED flags into shared data so they can be consumed
in the VbEcSoftwareSync() function. It also needs the VbInit()
function to not immediately request a reboot if the VGA Option
ROM was loaded in normal mode and the SLOW_EC flag is set as it
will still need to be used during software sync.
A FIXME in VbEcSoftwareSync() is implemented and the comment is
removed, and two extra checks are done. First, if rebooting to
RO then also check if the VGA Option ROM is needed to save an
extra reboot, and second when exiting the software sync function
request a reboot without the VGA Option ROM if it was done in
normal mode and the option rom was needed+loaded.
The request for a reboot from VbEcSoftwareSync() is saved when
doing EC update in case there is an (optional) PD software sync
that may also need to display the screen.
BUG=chrome-os-partner:12257,chrome-os-partner:32379
BRANCH=samus
TEST=all tests pass, manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Change-Id: Id592181efd640f4cd37a986cd1dcc29f3ca45104
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223718
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is necessary to support reading the kernel from raw NAND flash,
where the driver may need to skip over bad sectors, and absolute
sector addressing is thus not practical.
The impact is relatively minor. Vboot only did two reads per kernel
anyway, one for the first 64KB of the partition and a second for the
rest of the kernel data.
Firmware which uses vboot will need to implement the streaming APIs.
Or, as a really easy workaround, just copy the implementation from
firmware/stub/vboot_api_stub_stream.c, which translates from the new
streaming API to the old sector-based disk API.
BUG=chromium:403432
BRANCH=none
TEST=make runtests; passes.
CQ-DEPEND=CL:221992, CL:222885, CL:222945
Change-Id: I7437b489650c95c09ac68b67d4d86f9e15c2fa73
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222410
Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
This gives recovery mode information on two boots back instead of one,
which may be handy for debugging.
It also allows determining whether a failure of the current boot
should try the other slot or go to recovery, using only information
stored in NV storage.
Added crossystem support for printing the fields, and unit tests.
BUG=chrome-os-partner:32585
BRANCH=none
TEST=make runtests; VBOOT2=1 make runtests
Change-Id: Ia9f4186210d30217b902db7c513ae4ab8851f8f4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221230
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
In AllocAndReadGptData() the code was changed to use the GPT header
to determine the LBA of the GPT entries. This change did not account
for devices that have an invalid header and it can attempt to read
from invalid block addresses on a device.
This commit happened here:
a2d72f7 vboot: cgpt: Refer to partition entries by entries_lba.
https://chromium-review.googlesource.com/213861
The subsequent steps in vboot, LoadKernel->GptInit->GptRepair will
fix a missing header and entries, so it is only necessary for one of
the headers to be valid.
This is commonly the case with a new USB stick that has an image
written to it as only the primary header will be valid in this case.
However it is also true if the primary header has been corrupted and
the secondary header is still valid.
The code has been changed to call CheckHeader() on the primary and
secondary headers before attempting to use the 'entries_lba' field
to read the entries from the device. AllocAndReadGptData() now only
fails if both headers are invalid.
A number of new unit tests are created to check for these failure
conditions. In order to support this I had to extend the vboot_kernel
test infrastructure to have a buffer for the mocked disk data instead
of just ignoring reads and writes. This is because many of the existing
tests assumed they could have an invalid GPT header and still pass.
Now that the header is checked it is necessary for a valid header to
be created before the tests can pass.
BUG=chrome-os-partner:32386
BRANCH=samus,auron
TEST=All unit tests pass when running 'make runtests'
In addition real-world testing was done by corrupting the primary
and/or secondary headers of USB stick to ensure that it will
successfully boot if one of the headers is valid.
Change-Id: I7f840a44742fa3ba9a124df29ab5749e4c5a40c1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220757
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Nam Nguyen <namnguyen@chromium.org>
This CL renames GPT_PMBR_SECTOR to GPT_PMBR_SECTORS and GPT_HEADER_SECTOR to
GPT_HEADER_SECTORS to better indicate that these are constants for sizes, not
location.
BRANCH=None
BUG=None
TEST=unittest
Change-Id: I26ed6d45d77dcb1eb714135edbb9e4124b54e953
Reviewed-on: https://chromium-review.googlesource.com/214830
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
This CL accesses the partition entry array through its header's
entries_lba value.
Previously, we assume the primary entry array lies on third sector, and
the secondary array lies (1 + 32) sectors from disk end. This assumption
was fine, even Wikipedia assumed the same.
But in order for us to support writing boot code to the third sector (as
required by some Freescale board), the primary entry array must be moved
to another location. Therefore, we must use "entries_lba" to locate the
arrays from now on.
BRANCH=none
BUG=chromium:406432
TEST=unittest
TEST=`cgpt create -p` and then `cgpt show`. Make sure the table
header and entries are properly moved.
Change-Id: Ia9008b0bb204f290b1f6240df562ce7d3a9bbff2
Reviewed-on: https://chromium-review.googlesource.com/213861
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
In order to disable PD software sync but still do EC software sync
it is useful to have a separate GBB flag for it.
This will allow me to release a Samus P2B firmware image that will
update the EC but not the PD, since the PD FW that comes on P2B
devices cannot be updated with software sync.
BUG=chrome-os-partner:30079
BRANCH=None
TEST=flash BIOS with updated EC+PD:
1) no GBB flags to override behavior updates both EC and PD
2) GBB flag to disable EC software sync disables both EC and PD update
3) GBB flag to disable PD software sync disables only PD update
Change-Id: I49ffb59238bee4a2dd66b24f2516e3ce46ea06cd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211910
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a device has both an EC and a separate PD chip, call software sync
for each chip.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=Flash image.bin with new AP+EC+PD firmware, reboot.
See EC and PD both update and jump to RW.
On next cold boot, they jump to RW without again updating.
CQ-DEPEND=CL:210520
Change-Id: Ie445336ade46f0009c040afc14b3f40452caf27b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210536
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This will be used in subsequent CLs to support PD software sync. For
now, only devidx=0 is used.
This changes the external vboot API, so must be checked in at the same
time as changes to the u-boot and depthcharge implementations. For
now, those implementations should simply check if devidx=0 and fail if
it's not.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=make runtests
CQ-DEPEND=CL:208195,CL:208196
Change-Id: Iad3be9d676ac224c4582669bcd67176b39f75c73
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208210
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I don't think these utilities are needed any longer, so mark them as
deprecated. They will still be built and can be run via futility, but
invoking them directly will fail with a warning message.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: Ie704f2cecc3c37c91e4a0ffbcbcf94e2bf3ba05b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208775
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>
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>
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>
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>
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>
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>
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>
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
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>
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
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>
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>
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>
SetupTPM no longer uses recovery_mode parameter for anything other than
a debug print. This change moves the debug print to a caller function,
then removes recovery_mode from SetupTPM and some caller functions that
no longer have a use for it.
BUG=chrome-os-partner:20913.
TEST=Manual. Boot factory install shim in recovery mode and verify TPM
clear operations succeed. Boot in dev mode and verify "Lock physical
presence" print on UART.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I2f671f6680a6e67cf722855e659e99752bc0783c
Reviewed-on: https://gerrit.chromium.org/gerrit/62916
Reviewed-by: Randall Spangler <rspangler@chromium.org>
RollbackKernelLock previously checked a global to determine recovery
mode state. Since we have two copies of vboot_reference in firmware
(in coreboot and depthcharge), this creates a problem with
synchronization. Remove the global entirely and instead pass the
recovery state to RollbackKernelLock.
BUG=chrome-os-partner:20913.
TEST=Manual. Boot factory install shim in recovery mode and verify TPM
clear operations succeed. Boot in dev mode and verify "Lock physical
presence" print on UART.
BRANCH=FalcoPeppy.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I4e751d4a9ca60cd57c5c662ce86eba595fb22ba2
Reviewed-on: https://gerrit.chromium.org/gerrit/62874
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
As per the discussion on issue 221745 we will be using 64-bit byte offsets
for the MTD partition table and converting to/from sectors internally in cgpt.
Existing interfaces do not change, eg sizes are still reported in sectors, only
the on-disk representation is affected.
BRANCH=none
BUG=chromium:221745
TEST=unit tests pass
Change-Id: Id312d42783acfdabe6eb8aea11dcbd298e00a100
Reviewed-on: https://gerrit.chromium.org/gerrit/60919
Commit-Queue: Albert Chaulk <achaulk@chromium.org>
Reviewed-by: Albert Chaulk <achaulk@chromium.org>
Tested-by: Albert Chaulk <achaulk@chromium.org>
If FW hash is invalid, it is possible for boot to continue as normal
because the shared recovery reason is not updated. Update the shared
recovery reason to ensure the bootloader knows to do a recovery boot.
This change affects only systems that do not support RO_NORMAL (ex.
Haswell systems).
BUG=chrome-os-partner:20518.
TEST=Run firmware_CorruptBothFwSigAB on Peppy, verify PASS.
BRANCH=None.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I3b311416bf8c504deb4154e5850d967253c9dc17
Reviewed-on: https://gerrit.chromium.org/gerrit/60148
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
1) GBB flag to skip EC software sync, so EC will be untouched. Needed
for EC development.
2) GBB flag to default to booting legacy at end of dev screen timeout.
Very handy for booting Ubuntu (or other OS).
Also added unit tests for the new flags.
BUG=chrome-os-partner:20111
BRANCH=none
TEST=make runtests
Change-Id: I9da87d87014881a1b1393b0b4a5acb921d080066
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58270
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This means that in normal mode the system will boot all the way to the
OS before shutting down.
In developer or recovery modes, the BIOS screens will still check for
shutdown requested and shut down if so. This is necessary in
developer mode for security reasons, and because there's no guarantee
that a dev OS will still pay attention to the lid switch.
BUG=chrome-os-partner:17521
BRANCH=spring
TEST=make runtests; unit tests pass
Change-Id: I0698b659ad0febcf73043f1e8c5b98681c1bc5ba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58109
Integrates the FTS driver into cgpt. This driver is binary-format compatible
with the linux driver for interoperabiilty. The cgpt changes load & store a
hex-encoded mtd partition table in the FTS; we need some sort of encoding
because FTS only stores NUL-terminated strings.
Currently, the mtd code paths aren't executed in cgpt, only in the tests. It's
also not hooked up to the vboot code yet, we will need to do that eventually.
BUG=chromium:221745
TEST=new unit test added
BRANCH=none
Change-Id: I94eb0389d29aca0beb9d9a644465c7d86161b3c2
Original-Change-Id: I9fe2fa91b666572563426adb8fa9d426f9b60bbf
Reviewed-on: https://gerrit.chromium.org/gerrit/46796
Commit-Queue: Albert Chaulk <achaulk@chromium.org>
Reviewed-by: Albert Chaulk <achaulk@chromium.org>
Tested-by: Albert Chaulk <achaulk@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49789
The tpmc utility is failing to build with:
MOCK_TPM=1 emerge vboot_reference
Because some functions are not exported by the
mocked_tlcl library. This commit adds mocked
functions for TlclPacketSize() and TlclSendReceive()
BUG=chrome-os-partner:19263
BRANCH=none
TEST=manual: MOCK_TPM=1 emerge-fox_wtm2 vboot_reference
Change-Id: Iaf4c2dff78272c41572e3b89444346a03be35fbe
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50225
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Defines MTD on-disk structures & API in mtdlib.h/c that closely mirrors
the existing cgpt implementation. Currently, the disk structures do not
contain guids or labels, and the number of available partition types and
quantities are limited, exactly what we want to support should be decided
before we ship this.
Adds appropriate test coverage to the unit test library - either by modifying
existing tests, or copying them and changing them accordingly.
BUG=chromium:221745
TEST=added appropriate tests to the unittests
BRANCH=none
Change-Id: Iee19864498024c72229bc3c7811594fe762f52de
Original-Change-Id: I031eca69d6c8e825b02bd0522d57e92b05eb191a
Reviewed-on: https://gerrit.chromium.org/gerrit/46082
Tested-by: Albert Chaulk <achaulk@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Albert Chaulk <achaulk@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48793
Reviewed-by: Albert Chaulk <achaulk@chromium.org>
In recovery mode we ignore all TPM errors.
Just a comment change; no code change.
BUG=none
BRANCH=none
TEST=build vboot
Change-Id: I43ed89d0d38347b55e1f6e17b712814f9b972156
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47747
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
