This cleans up the vboot functions which handle display so they don't
need to pass it around. Eventually, it'll be absorbed by vb2_context.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build_packages --board=reef chromeos-firmware; boot reef
Change-Id: I58169dfd37abe657f9b9aa339cc72ffa398329e0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414288
Reviewed-by: Shelley Chen <shchen@chromium.org>
Passing the vb2 context around allows using more of the vb2 functions in
future changes, and prepares for a future where we directly use the
context as it was set up in firmware verification.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I8efa606dbdec5d195b66eb899e76fdc84337ad36
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404997
Reviewed-by: Shelley Chen <shchen@chromium.org>
This new recovery reason will instruct the calling firmware in
vboot_select_and_load_kernel to reboot the device (under the assumption
that training of memory has already been performed by the firmware). On
seeing the return code VBERROR_REBOOT_REQUESTED, calling firmware should
perform a reboot.
BUG=chrome-os-partner:59352
BRANCH=None
TEST=make -j runtests successful
Change-Id: I110a735e612665cb2378bd71ca01a111edaf58e3
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407656
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Originally, vboot1 code used VbExMalloc() and VbExFree() since it needed
to talk to EFI firmware that didn't have standard malloc() and free().
Now, coreboot and depthcharge implement them as wrappers around those
standard calls. vboot2 code already calls them directly, so let vboot1
code do that too.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I49ad0e32e38d278dc3589bfaf494bcf0e4b0a4bd
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400905
Originally, we didn't trust the firmware to provide these functions from
a standard library. Now, with coreboot, we do.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I4e624c40085f2b665275a38624340b2f6aabcf11
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/399120
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This adds RW firmware support for the optional firmware management
parameters TPM space.
System-level tests require CL:339262 to add cryptohome support.
BUG=chromium:601492
BRANCH=baytrail and newer platforms
TEST=make -j runtests
Or better, COV=1 make, and then make sure all new code is covered.
Change-Id: Ifaf644c80809552d5961615be6017c2a332a034b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/339234
In developer mode, this option will make the system try to boot into
a legacy OS first after the 30 second timeout. This removes the need to
press a key during boot to try legacy mode and the need to remove the
write protect screw to boot legacy as default.
BUG=chromium:310697
BRANCH=none
TEST=make runtests
Change-Id: I9a9f64c14ad015e21d08eec36e8fc187189cd2f2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304077
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In the new recovery process, a user will see 'broken' screen
instead of 'remove' screen, where usb stick presence is no longer
detected. A user instead has to hit esc+refresh+power to proceed
to recovery mode.
BUG=chromium:501060
BRANCH=tot
TEST=make runtests
Change-Id: Icd511c1ca892628b96befbb0a34c2c84b881c857
Reviewed-on: https://chromium-review.googlesource.com/304404
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch fixes what I think is an inconsistency in the existing legacy
boot behavior: when the GBB flag that defaults to legacy boot is set,
running out the 30 second timer would still boot legacy mode even if
dev_boot_legacy is not actually set (whereas pressing CTRL+L in the
same configuration would beep and refuse).
This patch makes both legacy boot trgiggers check the same condition
before boot. This does not restrict functionality since anyone who sets
the DEFAULT_DEV_BOOT_LEGACY GBB flag could simply set
FORCE_DEV_BOOT_LEGACY at the same time. It does however open up an
interesting new use case of using NVRAM to change back-and-forth between
legacy and normal developer mode (after GBB flags are changed once and
write-protection is enabled again).
If this is updated in the field it might lock existing devices out of
legacy mode... however, since by far the most common GBB flag
combination recommended on the internet seems to be 0x489 (including
FORCE_DEV_BOOT_LEGACY), I doubt this would be a problem in practice.
BRANCH=tbd
BUG=chrome-os-partner:39999
TEST=Booted with GBB flags 0x4b9 and 0x439, observed difference.
Change-Id: If6a6d99ab2cf116db2237fdc3df97fc22a68251c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270182
Reviewed-by: Duncan Laurie <dlaurie@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>
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>
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
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>
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>
