Age | Commit message (Collapse) | Author |
|
This renames the VB_SOURCE variable to VBOOT_SOURCE in the build system,
providing increased clarity about what it represents.
Since the submodule itself is called "vboot", it makes sense to use that
name in full instead of a very shortened (and confusing) version of it.
Change-Id: Ib343b6642363665ec1205134832498a59b7c4a26
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15824
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
On some x86 platforms (skylake, apollolake), we observe reboots at
different steps during the FSP initialization. These additional reboots
result in loss of recovery request because vboot_reference library
clears recovery request on vbnv once verification is complete and it has
made a decision about which boot path to take(normal/dev, slot-a/slot-b,
recovery).
Provide a way to allow mainboards/chipsets to inform recovery module in
vboot2 to save recovery reason to survive unexpected reboots. The
recovery reason is set in vbnv after vboot_reference library completes
its verification and clears the reason in vbnv while jumping to
payload.
BUG=chrome-os-partner:55431
Change-Id: Ie96be9aeb42c8209d8215943409e6327d6a8bf98
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15802
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add recovery module in vboot2 that checks if a recovery request is
pending and returns appropriate reason code:
1. Checks if recovery mode is initiated by EC.
2. Checks if recovery request is present in VBNV.
3. Checks if recovery request is present in handoff for post-cbmem
stages.
4. Checks if vboot verification is complete and looks up selected region
to identify if recovery is requested by vboot library.
BUG=chrome-os-partner:55431
Change-Id: I31e332a4d014a185df2434c3730954e08dc27281
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15800
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
1. Remove unused functions/structures.
2. Add checks for NULL return values.
3. Change prefixes to vb2 instead of vboot for functions used internally
within vboot2/
4. Get rid of vboot_handoff.h file and move the structure definition to
vboot_common.h
5. Rename all functions using handoff structure to have prefix
vboot_handoff_*. All the handoff functions can be run _only_ after cbmem
is online.
6. Organize vboot_common.h content according to different
functionalities.
BUG=chrome-os-partner:55431
Change-Id: I4c07d50327d88cddbdfbb0b6f82c264e2b8620eb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
TPM1.2 is using the somewhat misnamed tlcl_set_global_lock() command
function to lock the hardware rollback counter. For TPM2 let's
implement and use the TPM2 command to lock an NV Ram location
(TPM2_NV_WriteLock).
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM2_NV_WriteLock command is invoked before RO
firmware starts RW, and succeeds.
Change-Id: I52aa8db95b908488ec4cf0843afeb6310dc7f38b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 2f859335dfccfeea900f15bbb8c6cb3fd5ec8c77
Original-Change-Id: I62f22b9991522d4309cccc44180a5ebd4dca488d
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358097
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15638
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
tlcl_force_clear() needs to be issued each time when the device mode
switches between normal/development/recovery.
This patch adds command implementation using TPM_Clear TPM2 command,
and also invokes it before factory initialization.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM_Clear command succeeds at factory startup and
the boot proceeds normally.
Change-Id: Ia431390870cbe448bc1b6f1755ed17953be9bdf1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 347ff17b97da45fa4df547ff32f9dd2c8972cefd
Original-Change-Id: I2a0e62527ad46f9dd060afe5e75c7e4d56752849
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358095
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15636
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
The TPM2 specification allows defining NV ram spaces in a manner
that makes it impossible to remove the space until a certain PCR is in
a certain state.
This comes in handy when defining spaces for rollback counters: make
their removal depend on PCR0 being in the default state. Then extend
PCR0 to any value. This guarantees that the spaces can not be deleted.
Also, there is no need t create firmware and kernel rollback spaces
with different privileges: they both can be created with the same set of
properties, the firmware space could be locked by the RO firmware, and
the kernel space could be locked by the RW firmware thus providing
necessary privilege levels.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:55063
TEST=with the rest of the patches applied it is possible to boot into
Chrome OS maintaining two rollback counter spaces in the TPM NV
ram locked at different phases of the boot process.
Change-Id: I889b2c4c4831ae01c093f33c09b4d98a11d758da
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 36317f5e85107b1b2e732a5bb2a38295120560cd
Original-Change-Id: I69e5ada65a5f15a8c04be9def92a8e1f4b753d9a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358094
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15635
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
This patch adds a TPM2 specific path in the vboot2 initialization
sequence when the device is turned on in the factory for the first
time, namely two secure NVRAM spaces are created, with different
access privileges.
The higher privilege space can be modified only be the RO firmware,
and the lower privilege space can be modified by both RO and RW
firmware.
The API is being modified to hide the TPM implementation details from
the caller.
Some functions previously exported as global are in fact not used
anywhere else, they are being defined static.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=when this code is enabled the two secure spaces are successfully
created during factory initialization.
Original-Commit-Id: 5f082d6a9b095c3efc283b7a49eac9b4f2bcb6ec
Original-Change-Id: I917b2f74dfdbd214d7f651ce3d4b80f4a18def20
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353916
Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
squashed:
mock tpm: drop unused functions
safe_write() and safe_define_space() functions are defined in
secdata_mock.c, but not used in mocked TPM mode.
The actual functions have been redefined as static recently and their
declarations were removed from src/include/antirollback.h, which now
causes compilation problems when CONFIG_VBOOT2_MOCK_SECDATA is
defined.
Dropping the functions from secdata_mock.c solves the problem.
BRANCH=none
BUG=none
TEST=compilation in mock secdata mode does not fail any more.
Original-Commit-Id: c6d7824f52534ecd3b02172cb9078f03e318cb2b
Original-Change-Id: Ia781ce99630d759469d2bded40952ed21830e611
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/356291
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Icb686c5f9129067eb4bb3ea10bbb85a075b29955
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15571
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
If read_vbnv finds that the vbnv_copy is not valid, it initializes it
with the correct HEADER_SIGNATURE and other attributes. However, the
vbnv copy is checked for validity and initialized at the vboot layer as
well. Since, vboot is the owner of this data, it should be the one
initializing it. Thus, if read_vbnv sees that the data is not valid,
simply reset it to all 0s and let vboot layer take care of it. This also
removes the need for additional checks to ensure that the dirty vbnv
copy is properly updated on storage.
Change-Id: I6101ac41f31f720a6e357c9c56e571d62e0f2f47
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Currently, read_vbnv performs a reset of the vbnv cache if it is not
valid. However, this information is not passed up to the vboot layer,
thus resulting in missed write-back of vbnv cache to storage if vboot
does not update the cache itself.
Update read_vbnv to return a value depending upon whether it wants a
write-back to be performed when save is called.
Return value:
0 = No write-back required
1 = Write-back of VBNV cache is required.
Change-Id: I239939d5f9731d89a9d53fe662321b93fc1ab113
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15457
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
When the vboot cbfs selection runs in postcar stage it should be
utilizing cbmem to locate the vboot selected region.
Change-Id: I027ba19438468bd690d74ae55007393f051fde42
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14959
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Using a dedicated variable is slightly less readable and makes the code
less consistent, given that other test functions are called directly in
the if statements.
Change-Id: If52b2a4268acb1e2187574d15cc73a0c1d5fe9bb
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14817
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
On modern x86 platforms like apollolake, pre-RAM stages verstage and
romstage run within the cache-as-ram region. Thus, we do not need to
pass in the --xip parameter to cbfstool while adding these
stages. Introduce a new Kconfig variable NO_XIP_EARLY_STAGES which is
default false for all x86 platforms. Apollolake selects this option
since it supports code execution with CAR.
Change-Id: I2848046472f40f09ce7fc230c258b0389851b2ea
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14623
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: Ide3202fca75c77ccebf17d61d93945ba7834a13b
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14398
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
When doing verification of memory init code in verstage vboot
should issue a TPM_Startup(ST_STATE) instead of TPM_Startup(ST_CLEAR)
in order to preserve the flags in TPM_STCLEAR_FLAGS which include
things like physical presence. In doing so we can also skip the rest
of the TPM init work in this function in the S3 resume path.
BUG=chrome-os-partner:50633
BRANCH=glados
TEST=S3 resume on chell and ensure TPM is resumed instead of being
cleared and that 'tpmc getvf|getpf|getf' does not show any difference
in flags between boot and resume.
Change-Id: I7a48eaf7f57d2bc6ebc182178cbe60ceb2ad8863
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f059f39a0f5c2f21e564b9554efacf26a41ad794
Original-Change-Id: I647869202d2f04328764155d3de4cad9edf10ae4
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Previous-Reviewed-on: https://chromium-review.googlesource.com/332434
Original-(cherry picked from commit 5fc7792e4104523569140cd84ce313da721ec34b)
Original-Reviewed-on: https://chromium-review.googlesource.com/332542
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
If a platform does verification of the memory init step, and it must
resume with the same slot that it booted from then it needs to set
the vboot context flag when resuming instead of booting. This will
affect the slot that is selected to verify and resume from.
BUG=chromium:577269
BRANCH=glados
TEST=manually tested on chell:
1) ensure that booting from slot A resumes from slot A.
2) ensure that booting from slot B resumes from slot B.
3) do RW update while booted from slot A (so the flags are set to try
slot B) and ensure that suspend/resume still functions properly using
current slot A.
4) do RW update while booted from slot B (so the flags are set to try
slot A) and ensure that suspend/resume still functions properly using
current slot B.
Change-Id: I77e6320e36b4d2cbc308cfb39f0d4999e3497be3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 4c84af7eae7b2a52a28cc3ef8a80649301215a68
Original-Change-Id: I395e5abaccd6f578111f242d1e85e28dced469ea
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/328775
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch ports the LZ4 decompression code that debuted in libpayload
last year to coreboot for use in CBFS stages (upgrading the base
algorithm to LZ4's dev branch to access the new in-place decompression
checks). This is especially useful for pre-RAM stages in constrained
SRAM-based systems, which previously could not be compressed due to
the size requirements of the LZMA scratchpad and bounce buffer. The
LZ4 algorithm offers a very lean decompressor function and in-place
decompression support to achieve roughly the same boot speed gains
(trading compression ratio for decompression time) with nearly no
memory overhead.
For now we only activate it for the stages that had previously not been
compressed at all on non-XIP (read: non-x86) boards. In the future we
may also consider replacing LZMA completely for certain boards, since
which algorithm wins out on boot speed depends on board-specific
parameters (architecture, processor speed, SPI transfer rate, etc.).
BRANCH=None
BUG=None
TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on
Oak to be about ~20ms faster (cutting load times for affected stages
almost in half).
Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13638
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
These files aren't updated (or updatable), and as such don't need to be
copied to the RW sections.
Change-Id: Ie78936792ad651fbf8500fc7e34f0899e33a904c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13633
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Certain platforms query the recovery mode switch more than just within
vboot during the boot flow. Therefore, it's important that the first call to
get_recovery_mode_switch() is consistent through memory training because
certain platforms use the recovery mode switch to take different action
for memory training. Therefore, defer the clearing of the rec mode
switch to a place when it's known that memory is up and online.
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Three finger salute is honored on chell by retraining memory.
Change-Id: I26ea51de7ffa2fe75b9ef1401fe92f9aec2b4567
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6b0de9369242e50c7ff3b164cf1ced0642c7b087
Original-Change-Id: Ia7709c7346d1222e314bf3ac7e4335a63e9a5144
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/325120
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13604
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Vboot keeps track of the size of the hashed region in each
RW slot. While that size was being used to calculate the hash
it wasn't being honored in restricting the access within the
FMAP region for that RW slot. To alleviate that create a sub
region that covers the hashed data for the region in which
we boot from while performing CBFS accesses.
BUG=chrome-os-partner:49764
BUG=chromium:445938
BRANCH=glados
TEST=Built and booted chell with cbfstool and dev-util patches.
Change-Id: I1a4f45573a6eb8d53a63bc4b2453592664c4f78b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ac9e84af5b632e5735736d505bb2ca6dba4ce28
Original-Change-Id: Idca946926f5cfd2c87c4a740ad2108010b6b6973
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324093
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13586
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
For x86 systems which resume through the reset vector one needs to
ensure the the RW slot taken at resume time matches the one at
boot time. The reason is that any assets pulled out of the boot
media need to match how the platform previously booted. To do
that one needs obtain the hash digest of the chosen slot, and it
needs to be saved in a secure place on the normal boot path. On
resume one needs to retrieve the hash digest back to compare it
with the chosen slot. If they don't match resuming won't be
possible.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
CQ-DEPEND=CL:323460
Change-Id: I90ce26813b67f46913aa4026b42d9490a564bb6c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 01a42c0ecfc6d60d1d2e5e36a86781d91d5c47a9
Original-Change-Id: I6c6bdce7e06712bc06cc620a3d7a6a6250c59c95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323500
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13574
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add flag handling for CONFIG_VBOOT_EC_SLOW_UPDATE to indicate
to vboot that it should show the "critical update" screen during
software sync for EC+PD.
In order to make this work on x86 where we do not run graphics
init in the normal path add handling for CONFIG_VBOOT_OPROM_MATTERS
and indicate to vboot when the option rom has been loaded.
BUG=chrome-os-partner:49560
BRANCH=glados
TEST=Build and boot on chell in normal mode with an EC update payload
and ensure that it reboots to enable graphics, shows the "critical
update" screen, and then reboots to disable graphics init again.
Change-Id: I5ca46457798a22e9b08aa2febfec05b01aa788f9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6a1bb8572c3485f64b9f3e759288321b44184e66
Original-Change-Id: I9f66caaac57bb9f05bc6c405814469ef7ddf4d0a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322781
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13073
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Setup an initial rule to make use of the updatable CBFS regions in fmap.
Change-Id: I1fe1c6e7574854b735760c85590da6e297f6e687
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13060
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Now that only CBFS access is supported for finding resources
within the boot media the assets infrastructure can be removed.
Remove it.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12690
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Chrome OS verified boot path supported multiple CBFS
instances in the boot media as well as stand-alone assets
sitting in each vboot RW slot. Remove the support for the
stand-alone assets and always use CBFS accesses as the
way to retrieve data.
This is implemented by adding a cbfs_locator object which
is queried for locating the current CBFS. Additionally, it
is also signalled prior to when a program is about to be
loaded by coreboot for the subsequent stage/payload. This
provides the same opportunity as previous for vboot to
hook in and perform its logic.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
CQ-DEPEND=CL:307121,CL:31691,CL:31690
Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12689
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
verstage, romstage, and payload can be added through infrastructure now.
Change-Id: Ib9e612ae35fb8c0230175f5b8bca1b129f366f4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12549
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
While migrating from vboot1 to vboot2, the tpm_init was moved out of
vboot library and implemented in coreboot. However, while doing this,
the initial factory flow was missed.
We need to ensure following flow for tpm_init:
1. Perform tpm_init
2. If tpm_init fails, set secdata_context flag to indicate to vboot
that tpm needs reboot.
3. Call vb2_api_phase1
4. If vb2_api_phase1 returns error code saying boot into recovery,
continue booting into recovery. For all other error codes, save
context if required and reboot.
[pg: everything but step 2 was already done, so this upstream commit is
quite minimal]
CQ-DEPEND=CL:300572
BUG=chrome-os-partner:45462
BRANCH=None
TEST=Verified behavior on smaug. Steps to test:
1. Reboot into recovery
2. tpmc clear
3. Reboot device
Expected Behavior: Device should reboot after Enabling TPM. Should not
enter recovery
Confirmed that the device behaves as expected.
Change-Id: I72f08d583b744bd77accadd06958c61ade298dfb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85ac93137f3cfb28668dcfa18dfc773bf910d44e
Original-Change-Id: I38ab9b9d6c2a718ccc8641377508ffc93fef2ba1
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/300570
Original-Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12205
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
vboot handoff should look at flags in struct vb2_shared_data when
translating flags to VBSD_BOOT_REC_SWITCH_ON because
VBSD_BOOT_REC_SWITCH_ON is supposed to indicate whether manual recovery was
triggered or not while vb2_sd->recovery_reason will be able to provide
that information only in some cases after CL:307586 is checked in.
For example, this fixes a recovery loop problem: Without this fix,
vb2_sd->recovery_reason won't be set to VB2_RECOVERY_RO_MANUAL when user
hits esc+refresh+power at 'broken' screen. In the next boot,
recovery_reason will be set to whatever reason which caused 'broken'
screen. So, if we check recovery_reason == VB2_RECOVERY_RO_MANUAL, we
won't set vb_sd->flags to VBSD_BOOT_REC_SWITCH_ON. That'll cause a
recovery loop because VbBootRecovery traps us again in the 'broken'
screen after not seeing VBSD_BOOT_REC_SWITCH_ON.
BUG=chromium:501060
BRANCH=tot
TEST=test_that -b veyron_jerry suite:faft_bios
Change-Id: I69a50c71d93ab311c1f7d4cfcd7d454ca1189586
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d9679b02f6d21ed903bb02e107badb0fbf7da46c
Original-Change-Id: I3da642ff2d05c097d10db303fc8ab3358e10a5c7
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/307946
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/12199
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We need to special-case filling out the vboot structures when
we use CBFS instead of vboot's custom indexed format, otherwise
(due to the way the CBFS header looks), it will try to write several
million entries.
Change-Id: Ie1289d4a19060bac48089ff70e5cfc04a2de373f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11914
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
When a separate verstage is employed the verstage file
was just being added through the cbfs-files mechanism.
However, that doesn't allow one to specify other flags
that aren't supported that an architecture may require.
The x86 architecture is one of those entities in that
it needs its verstage to be XIP. To that end provide
a mechanism for adding verstage with options.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using his mechansim on x86.
Change-Id: Iaba053a55a4d84d8455026e7d6fa548744edaa28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11819
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In order to support x86 verstage proper the work buffer
needs to live in cache-as-ram. However, after cache-as-ram
is torn down one still needs the verification results to
know which slot was selected. Though the platforms with
a dedicated SRAM can just use the work buffer in SRAM, the
x86 cache-as-ram platforms need a place to stash the
results. For that situation cbmem is employed. This works
because when cbmem is initialized cache-as-ram is still
enabled. The VBOOT_DYNAMIC_WORK_BUFFER case assumes
verified boot doesn't start until after cbmem is up. That
doesn't change, but it's a goal to get rid of that option
entirely once all other x86 platforms are moved over to
pre-romstage vboot.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados with pre-romstage verification
as well as VBOOT_DYNAMIC_WORK_BUFFER case.
Change-Id: I7eacd0edb2b6ca52b59b74075d17c00b50676d4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11821
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
For the purpose of isolating the work buffer logic
the surface area of the API was slimmed down. The
vb2_working_data structure is no longer exposed,
and the function signatures are updated accordingly.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: If64184a79e9571ee8ef9822cfce1eda20fceee00
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11818
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Now that cbfs is adding more metadata in the cbfs file
header one needs to access that metadata. Therefore,
add struct cbfsf which tracks the metadata and data
of the file separately. Note that stage and payload
metadata specific to itself is still contained within
the 'data' portion of a cbfs file. Update the cbfs
API to use struct cbfsf. Additionally, remove struct
cbfsd as there's nothing else associated with a cbfs
region aside from offset and size which tracked
by a region_device (thanks, CBFS_ALIGNMENT!).
BUG=None
BRANCH=None
TEST=Built and booted through end of ramstage on qemu armv7.
Built and booted glados using Chrome OS.
Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11679
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Up to now, the multi-CBFS code path merely looked up files in the "boot
ro" image (ie. the default), disregarding the specified fmap region to
use for CBFS.
The code still relies on the master header being around, which on the
upside allows it to skip an offset at the beginning of the region (eg.
for ARM bootblocks).
This will change later (both the reliance on the master header and the
presence of the bootblock like this).
Change-Id: Ib2fc03eac8add59fc90b4e601f6dfa488257b326
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11805
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Certain chipsets provide their own main symbol for verstage.
Therefore, it's necessary to know this so that those chipsets
can leverage the common verstage flow.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built nyan using this option.
Change-Id: If80784aa47b27f0ad286babcf0f42ce198b929e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11777
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The vboot verification in a stage proper is unified
replacing duplicate code in the tegra SoC code. The
original verstage.c file is renamed to reflect its
real purpose. The support for a single verstage flow
is added to the vboot2 directory proper.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados.
Change-Id: I14593e1fc69a1654fa27b512eb4b612395b94ce5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11744
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This removes the dependency on chromeos and vboot for the sw write protect state
function: vboot_get_sw_write_protect, renamed to get_sw_write_protect_state to
both reflect this change and become consistent with the definition of
get_write_protect_state that is already in use.
Change-Id: I47ce31530a03f6749e0f370e5d868466318b3bb6
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11496
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
$(obj) might be defined either as a relative or an absolute path. Thus, it has
to be filtered out before adding $(top) to it (in case of an absolute path) when
building vboot. It is then provided separately in CFLAGS (as an absolute path).
In addition, VB2_LIB inherits $(obj), so it might also already be an absolute
path, and prefixing $(top) to it doesn't apply. Thus, the absolute path to it
should be passed to the vboot make command.
Change-Id: I13e893ebdf22c4513ee40d9331a30ac7de8f9788
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11120
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
TEST=built for samus and veyron_jerry
Change-Id: I7173f46d2ed2e323bff227a484c32c4bb6f6c828
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: http://review.coreboot.org/11028
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Assume that it's 64 byte.
Change-Id: I168facd92f64c2cf99c26c350c60317807a4aed4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10919
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This can be a problem with freshly updated devices that are periodically
powered on while closed (as explained in the bug report).
In this case, just don't count down. In case of actual errors (where we
want the system to fall back to the old code), this now means that the
retries have to happen with the lid open.
Bump vboot's submodule revision for the vboot-side support of this.
BUG=chromium:446945
TEST=to test the OS update side, follow the test protocol in
https://code.google.com/p/chromium/issues/detail?id=446945#c43
With a servo, it can be sped up using the EC console interface to start
the closed system - no need to wait 60min and plugging in power to get
to that state.
Change-Id: I0e39aadc52195fe53ee4a29a828ed9a40d28f5e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10851
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Iaadbd52d948000d1ed46865b83bdb0f4926ca429
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10677
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of calling the init function to clear out vboot2 data structures in
multiple places, move the function and call close to verstage_main().
Change-Id: If42e18a8e4581f22f7a7aced70ccbe3188bb0cd5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10701
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Otherwise it'll determine some offsets from uninitialized data and hilarity
ensues.
Change-Id: I6a671987857cfd3f3cd6078aebd13dd09fc79020
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10660
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some patches landed that didn't introduce the Kconfig
options for additional firmware components. Add them.
Change-Id: I0a0b7f0291389d126a7c491f710618a278cfb5d7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Now that vboot is using offsets for everything remove the
pass through vboot_get_region() and use region_devices
as first class citizens.
Change-Id: I1a86f3725e5bce38e6ca31e9641b1a8f4ac50e96
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10225
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of being pointer based use the region infrastrucutre.
Additionally, this removes the need for arch-specific compilation
paths. The users of the new API can use the region APIs to memory
map or read the region provided by the new fmap API.
Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9170
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Because of the fmap API returning pointers to represent
regions within the boot device a vboot_region structure
was used to track the case where offsets could be pointers
on x86 but not on !x86. Normalize this tracking to use
offsets only as it provides consistency in the code.
Change-Id: I63c08b31ace3bd0e66ebc17e308f87eb5f857c86
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10221
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
When we are taking the recovery path there is no slot or
components to fill out.
Change-Id: Ic97a247629365ef54a340c4398cb7491935edc11
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10198
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
There was no indication of verstage being loaded. Provide this
output so that one can follow the flow from console messages.
Change-Id: I67ae6bb334608fe10a4a12fe690498afaf6b8366
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10195
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The support for RELOCATABLE_RAMSTAGE was accidentally omitted in
the vboot loader. Add said support.
Change-Id: I569918823253c33f698acefd6a619133543c7aef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10184
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The vboot library currently relies on link-time known
address and sizes of the work buffer. Not all platforms
can provide such semantics. Therefore, add an option
to use cbmem for the work buffer. This implies such platforms
can only do verification of the firmware after main memory
has been initialized.
Change-Id: If0b0f6b2a187b5c1fb56af08b6cb384a935be096
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10157
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of using the symbols directly provide a size
function to provide symmetry between getting the work
data and size. It also allows for an abstraction where
the linker symbols may not be the only source of this
information.
Change-Id: I4568064a0050d118c3544ab1ea59a08eb0bad8e4
Signed-off-by: Aaron Durbi <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10156
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As previously done the vboot loader can be optionally
inserted in the stage loading logic in order to
decide the source of each stage. This current patch
allows for verstage to be loaded and interrogated
for the source of all subsequent stages. Additionally,
it's also possible to build this logic directly into
one of the additional stages.
Note that this patch does not allow x86 to work.
Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10154
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This make it pass through -fno-stack-protector, and also uses
libverstage fields consistently.
verstage is for 'stage' stuff, libverstage for all the vboot logic.
Change-Id: I3032e072414bed52effd2dc5057896781ad562c6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/10174
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
In order to allow easier setting of variables without
changing mainboards and/or chipset Kconfig files allow
the vboot options to be selected by the user.
Change-Id: I6e995eb209b4cd63c73ef679d0c5699759d129f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10153
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The VB_FIRMWARE_ARCH variable was not being set correctly,
and the VBOOT_STARTS_IN_BOOTBLOCK Kconfig option was not properly
prefixed with CONFIG_. Correct both of these oversights.
Change-Id: Id27974c285d2629bd47b90b6a93aca1ec8a76512
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10152
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I9cbdf06f4d0956b5374915f8af7501c6f75b4687
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10113
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
verstage still needs to be built with its flags.
Change-Id: I125e4be283d3838fc7ce6587bf9996731540d517
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10098
Tested-by: build bot (Jenkins)
|
|
The name is more consistent with what we have elsewhere,
and the callsite didn't build at all (with vboot enabled)
Change-Id: I3576f3b8f737d360f68b67b6ce1683199948776d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10096
Tested-by: build bot (Jenkins)
|
|
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The ChromeOS machines employing vboot verfication require
different combinations of support:
1. When vboot verification starts.
2. Is the vboot code a separate stage or program?
3. If a separate stage, does the that vboot program (verstage) return
to the stage that loaded the verstage?
For the above, #1 is dependent on when to load/run vboot logic which
is orthogonal to #2. However, #3 is dependent on #2. The logic
to act on the combinations follows in subsequent patches.
Change-Id: I39ef7a7c2858e7de43aa99c38121e85a57f1f2f6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10024
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
With vboot1 out of the way place all the associated Kconfig
options in vboot2's Kconfig file (excluding main vboot verify
option). More options will be added to accomodate vboot's various
combinations of use cases.
Change-Id: I17b06d741a36a5e2fefb2757651a61bfed61ae1e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10023
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
There's no need to have the VBOOT2_VERIFY_FIRMWARE
distinction because it's the only game in town.
Change-Id: I82aab665934c27829e1a04115bf499ae527a91aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9958
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In preparation for moving to vboot2 for all verified
boot paths bring over Kconfig options to the common
area from vboot1. Also remove vboot1 directory entirely.
Change-Id: Iccc4b570216f834886618f0ba5f2e1dd6c01db4b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9957
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I31cd7f84db8b7176c8854f33421aab5c176cd5ce
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10007
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The vboot2 code requires them.
Change-Id: I9afaf9b373297b0eebce9ffd7cc05766dee7d6fd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10006
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Iaf6d6a8857451fb16916aaae97a6fd5c51bc8cc4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10005
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This slightly streamlines integrating the vboot2 library and
prepares for merging verstage and bootblock on selected devices.
Change-Id: I2163d1411d0c0c6bf80bce64796e1b6a5a02b802
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10004
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The preprocessor flags that are manipulated in that line are
managed exclusively in CPPFLAGS since commit 58f73a69.
Change-Id: I2263401a292b4f7435659b24cf4f695a927015ef
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9948
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It is necessary to trigger console buffer contents dump on reset.
Let's make sure all vboot resets are routed through the same function.
BRANCH=none
BUG=chromium:475347
TEST=built and booted storm
Change-Id: I0d8580fb65417ba4b06dfae763dd6455afc8fc26
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9788e2043cb1bd5df7e30574f7df4de4f25caa0d
Original-Change-Id: Iafca416700c51a0546249438ca583a415a1ca944
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265292
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9931
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch allows a board without a secdata storage (typically TPM) to pass
the verification stage if recovery path is taken. It's useful for bringup
when the actual board is not ready.
BUG=none
BRANCH=none
TEST=booted the kernel from a usb stick on a cygnus reference board
Change-Id: I5ab97d1198057d102a1708338d71c606fe106c75
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5d45acee31fd5b7bfe7444f12e3622bae49fc329
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chrome-internal-review.googlesource.com/212418
Original-Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Original-Tested-by: Daisuke Nojiri <dnojiri@google.com>
Original-Change-Id: Iddd9af19a2b6428704254af0c17b642e7a976fb8
Original-Reviewed-on: https://chromium-review.googlesource.com/265046
Reviewed-on: http://review.coreboot.org/9919
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
On embedded devices with limited input capabilities it is necessary to
clear the developer mode condition when entering recovery. The new
configuration option will enable such behavior using the new vboot2
flag.
CQ-DEPEND=CL:261630
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=with the rest of the patches applies observed desired behavior on
SP5
Change-Id: I99c3d1330bea9980a2af3b9fd99e29ab96f2cf07
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4c0a6315d6b4ede8d43e736ee6c82f1023f4716d
Original-Change-Id: I8e4a521e574b53a670daf692f7b45dc21635f272
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261620
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9878
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It is better to explicitly disable the call to read the physical
switch setting than to leave it up to implementation. In fact no
implementation would be even required.
BRANCH=none
BUG=none
TEST=verified that storm works as expected
Change-Id: I4b39827dba34ec0124960d0634e45d4554252d9b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c9fd014f1bfec6570b20ed8fed16d14d7e4e11b9
Original-Change-Id: I5d6d223f0c684e105a5e3d0b407e0fb181c7a7df
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261588
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9876
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It has become necessary to be able to "factory reset" certain devices
on firmware request.
The vboot package has been modified to provide the necessary API, this
patch introduces a configuration option and uses the API when
enabled.
CQ-DEPEND=CL:259857
BRANCH=storm
BUG=chrome-os-partner:37219
TEST=with all the patches applied, on storm, holding the recovery
button at startup for 10 seconds, causes 'crossystem
wipeout_request' to report '1'.
Change-Id: I5e57bc05af3753f451626021ba30c7726badb7b4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f70e03e9a8c55bf3c45b075ae4fecfd25da4f446
Original-Change-Id: I4c2192da4fabfdef34d527e5b80d137634eb6987
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/259843
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9862
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
ChromeOS/vboot devices expect the TPM PCRs 0 and 1 to be extended with
digests that attest the chosen boot mode (developer/recovery) and the
HWID in a secure way. This patch uses the newly added vboot2 support
functions to fetch these digests and store them in the TPM.
CQ-DEPEND=CL:244542
BRANCH=veyron
BUG=chromium:451609
TEST=Booted Jerry. Confirmed that PCR0 contains the same value as on my
vboot1 Blaze and Falco (and PCR1 contains some non-zero hash).
Original-Change-Id: I7037b8198c09fccee5440c4c85f0821166784cec
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/245119
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 8b44e13098cb7493091f2ce6c4ab423f2cbf0177)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I549de8c07353683633fbf73e4ee62ba0ed72ff89
Reviewed-on: http://review.coreboot.org/9706
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
BUG=chromium:452179
BRANCH=ToT
CQ-DEPEND=CL:243362
TEST=manual
emerge-veyron_pinky coreboot
Original-Change-Id: Ibcbaea2990e5e06ea7cfaaa5412ef7c1477f5fcc
Original-Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/243380
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 8e5c18eeb21944bdcb064b4491c6781d16ef5608)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I26f6fb67655cb1dfbdcdc48530ef6bfeb1aa692a
Reviewed-on: http://review.coreboot.org/9705
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
When CONFIG_MULTIPLE_CBFS_INSTANCES is enabled, the image is expected
to have CBFS instances in rw-a and rw-b sections of the bootrom.
This patch adds code which makes sure that CBFS header points at the
proper bootrpom section as determined by vboot, and the RW stages load
from that section.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=with the rest of the patches in, STORM boots all the way into
Linux login prompt.
Original-Change-Id: I187e3d3e65d548c672fdf3b42419544d3bd11ea1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237662
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 71ad0bb41b183374a84a5b9fb92c3afd813ceace)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia05cb713981c44da8cb379b72dfbe17fe1f6c5ff
Reviewed-on: http://review.coreboot.org/9704
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch aligns our verstage code to the new API addition in vboot2.
The hardware crypto functions are stubbed out by default and just
pretend that all algorithms are unsupported, causing vboot to fall back
to the normal software hashing code. These weak symbols can be
overridden by individual platform code to provide actual hardware
crypto engine support.
CQ-DEPEND=CL:236453
BRANCH=None
BUG=chrome-os-partner:32987
TEST=Booted Pinky, confirmed vboot falls back to software crypto.
Original-Change-Id: Idf6a38febd163aa2bff6e9a0e207213f01ca8324
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236435
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 9b5ee7f575f1aa3b0eb6ef78947ca93a4818f57b)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I6f0e19255a9bc5c5cd1767db76f1e47897ef0798
Reviewed-on: http://review.coreboot.org/9703
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
this allows each board to decide what to do after firmware verification is
done. some board needs to return back to the previous stage and let the
previous stage kick off the verified stage.
this also makes it more visible what is going to happen in the verstage since
stage_exit now resides in main().
BUG=none
BRANCH=tot
TEST=booted cosmos dev board. booted blaze in normal and recovery mode.
built for all current boards.
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I3cb466cedf2a9c2b0d48fc4b0f73f76d0714c0c7
Original-Reviewed-on: https://chromium-review.googlesource.com/232517
(cherry picked from commit 495704f36aa54ba12231d396376f01289d083f58)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ic20dfd3fa93849befc2b37012a5e0907fe83e8e2
Reviewed-on: http://review.coreboot.org/9702
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Turns out there are uses for memlayout regions not specific to vboot2.
Rather than add yet another set of headers for a single region, let's
make the vboot2 one common for chromeos.
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm.
Change-Id: I228e0ffce1ccc792e7f5f5be6facaaca2650d818
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b
Original-Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242630
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9748
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa
Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234063
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9608
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Since we can now reduce our vboot2 work buffer by 4K, we can use all
that hard-earned space for the CBMEM console instead (and 4K are
unfortunately barely enough for all the stuff we dump with vboot2).
Also add console_init() and exception_init() to the verstage for
CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model
requires those functions to be called again at the beginning of every
stage... even though some consoles like UARTs might not need it, others
like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is
expected to be done by the platform-specific verstage entry wrapper, and
already in place for the only implementation we have for now (tegra124).
(Technically, there is still a bug in the case where EARLY_CONSOLE is
set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would
run init_console_ptr() as if they were there first, so the romstage
overwrites the verstage's output. I don't think it's worth fixing that
now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless
use-case and I think we should probably just get rid of the
CONFIG_BOOTBLOCK_CONSOLE option eventually.)
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I87914df3c72f0262eb89f337454009377a985497
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c
Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232614
Reviewed-on: http://review.coreboot.org/9607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
sd->fw_version represents the version of the *current* firmware, which
is not necessarily the same as the one stored in the TPM (and may be 0
in recovery mode). Use the newly added sd->fw_version_secdata instead
which contains a more correct value.
CQ-DEPEND=CL:244601
BRANCH=veyron
BUG=chrome-os-partner:35941
TEST=Booted Jerry in recovery mode, confirmed crossystem tpm_fwver was
corrent (and not 0).
Change-Id: I30f5998da5ac518d6fcb7a651eba4e1fabc14478
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: eb8142f69cea34e11f9081caafcaae7a15cc3801
Original-Change-Id: Id95bd8c6412f2e8b2ae643c3b5a3dee13d0d47be
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/244591
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9565
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
There are multiple vboot APIs (1.0, 2.0, 2.1). We have to be
explicit about which library we want to link with.
When building firmware, the vboot_reference Makefile should be
invoked in one of three ways:
TARGET OUTPUT VERSION
fwlib vboot_fw.a 1.0
fwlib20 vboot_fw20.a 2.0
fwlib21 vboot_fw21.a 2.1
BUG=chromium:228932
BRANCH=ToT
CQ-DEPEND=CL:243980
TEST=manual
emerge-veyron_pinky vboot_reference coreboot
emerge-samus vboot_reference coreboot
emerge-daisy_spring vboot_reference chromeos-u-boot
Change-Id: I7dde513c49b8148bf46e8768ae438e1a85af4243
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 5e339cadad4815f061d4e5e20a9c9733f64cc90b
Original-Change-Id: I850646117211930d9215693c48f2c30d55a984d3
Original-Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/243981
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9564
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
this change makes vb2_working_data struct point to the vboot work buffer by
the offset instead of by the absolute address, which can be different
depending on the context (e.g. subprocessor v.s. main cpu).
BUG=none
BRANCH=tot
TEST=booted veyron pinky
Change-Id: I2191ca756c4f49441b3a357338f9c84564b58918
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 93f8b1da2b2c81aa3a33892987a71e9e1e7a8eff
Original-Change-Id: I4e4c12613304586b7395c5173cf08b8093f59521
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236583
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9588
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This will allow vboot2 to continue refactoring without breaking
coreboot, since there's now only a single file which needs to stay in
sync.
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
CQ-DEPEND=CL:233050
Original-Change-Id: I74cae5f0badfb2d795eb5420354b9e6d0b4710f7
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233051
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit df55e0365de8da85844f7e7b057ca5d2a9694a8b)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I999af95ccf8c326f2fd2de0f7da50515e02ad904
Reviewed-on: http://review.coreboot.org/9446
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Apparently our initial submission of 16K was a little too generous for
the vboot2 work buffer, and I hear that we should also be well within
bounds for 12K. This patch reduces the minimum asserted by memlayout so
some of our low-mem boards can get a few more kilobytes back for
discretionary spending. Also changes the required minimum alignment to 8
since that's what the current vboot code aligns it to anyway, and add a
warning comment to make it clearer that this is a dangerous number
people should not be playing with lightly.
BRANCH=None
BUG=None
TEST=Built and booted on Pinky.
Original-Change-Id: Iae9c74050500a315c90f5d5517427d755ac1dfea
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232613
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 64e972f10363451cd544fdf8642bd484463703bc)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I362b8c33cf79534bb76bd7acda44d467563fe133
Reviewed-on: http://review.coreboot.org/9445
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
PHYSICAL_REC_SWITCH is set n by default and y for panther and stumpy.
BUG=none
BRANCH=ToT
TEST=Built nyan_blaze using vboot1/2. Built falco, lumpy, nyan,
blaze, parrot, rambi, samus, storm, pinky with default configuration.
panther and stumpy are not tested because they currently don't build on ToT.
Original-Change-Id: Ic45f78708aaa7e485d2ab459fd1948524edb412f
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227940
Original-Reviewed-on: https://chromium-review.googlesource.com/229602
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit edb2ba347b48887ffe450586af0351e384faad59)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I277f665cd4f3e1c21745cdc5c7a2cfe148661abe
Reviewed-on: http://review.coreboot.org/9444
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This changes copies firmware version from vboot2 shared data to vboot1
shared data. This fixes FAFT firmware_TPMVersionCheck test.
BUG=none
BRANCH=ToT
TEST=firmware_TPMVersionCheck passed on Nyan Kitty.
Original-Change-Id: Idfd282931421dc16cd1aa82c7ccb6c6790a4d0d7
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/230186
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Tested-by: Yen Lin <yelin@nvidia.com>
(cherry picked from commit 1f590741893bee75d872184eba01c62e92455816)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I205b651976d047923815efcd45b114cc7bf866e4
Reviewed-on: http://review.coreboot.org/9443
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
this change also allows vboot1 code to use flash as nvram device.
BUG=none
BRANCH=ToT
TEST=Built nyan_blazw using vboot1/2. Built falco, lumpy, nyan, blaze,
parrot, rambi, samus, storm, pinky with default configuration.
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Ie97a4436d4fc10851a535adfdb45c4d499e45b5d
Original-Reviewed-on: https://chromium-review.googlesource.com/229598
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 8ac8ff28bab1337782e8694275bb2c644b86f38a)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ief087fedbf29b4b82c1668ad5603c121323dcbf2
Reviewed-on: http://review.coreboot.org/9440
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
BUG=chrome-os-partner:33395
BRANCH=none
TEST=emerge and test using crossystem
Original-Change-Id: I0d49f85219d45c837a7100e0195bef86da2c6cdd
Original-Signed-off-by: Gediminas Ramanauskas <gedis@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227546
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 5a2868e04140973691136adfd7d9e6d1aa1f6dae)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I93c1ea9ce1270c2c143fd44ead2291dfbc114c00
Reviewed-on: http://review.coreboot.org/9437
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This moves vboot1 and vboot2 files to their designated directory. Common
code stays in vendorcode/google/chromeos.
BUG=none
BRANCH=none
TEST=built cosmos, veyron_pinky, rush_ryu, nyan_blaze, samus, parrot,
lumpy, daisy_spring, and storm.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Ia9fb41ba30930b79b222269acfade7ef44b23626
Original-Reviewed-on: https://chromium-review.googlesource.com/222874
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit cbfef9ad40776d890e2149b9db788fe0b387d210)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia73696accfd93cc14ca83516fa77f87331faef51
Reviewed-on: http://review.coreboot.org/9433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|