Age | Commit message (Collapse) | Author |
|
Error codes are renamed as follows:
VBERROR_SHUTDOWN_REQUESTED
--> VB2_REQUEST_SHUTDOWN
VBERROR_REBOOT_REQUIRED
--> VB2_REQUEST_REBOOT
VBERROR_EC_REBOOT_TO_SWITCH_RW
--> VB2_REQUEST_REBOOT_EC_SWITCH_RW
VBERROR_EC_REBOOT_TO_RO_REQUIRED
--> VB2_REQUEST_REBOOT_EC_TO_RO
BRANCH=none
BUG=b:124141368, chromium:988410
TEST=emerge-nami coreboot
Cq-Depend: chromium:2143030
Change-Id: Id82cf85f49dfb63a9c3d41aacd3969786bffcac7
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40749
Reviewed-by: Joel Kitching <kitching@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since CB:40389, all platforms with CONFIG_VBOOT_EARLY_EC_SYNC need to
write back secdata in romstage. Those platforms currently all happen to
have CONFIG_VBOOT_SEPARATE_VERSTAGE set as well, but there's no official
dependency between those options. Change the Makefile to unconditionally
build the secdata access routines for romstage so that this would work
on other platforms as well.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0b3c79e9bb8af9d09ef91f5749953ca109dd2a40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Allow to write protect only the WP_RO region in case of enabled VBOOT.
One can either lock the boot device in VERSTAGE early if VBOOT is enabled,
or late in RAMSTAGE. Both options have their downsides as explained below.
Lock early if you don't trust the code that's stored in the writeable
flash partition. This prevents write-protecting the MRC cache, which
is written in ramstage. In case the contents of the MRC cache are
corrupted this can lead to system instability or trigger unwanted code
flows inside the firmware.
Lock late if you trust the code that's stored in the writeable
flash partition. This allows write-protecting the MRC cache, but
if a vulnerability is found in the code of the writeable partition
an attacker might be able to overwrite the whole flash as it hasn't
been locked yet.
Change-Id: I72c3e1a0720514b9b85b0433944ab5fb7109b2a2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
|
|
When CONFIG_SEPARATE_VERSTAGE=n, all verstage code gets linked into the
appropriate calling stage (bootblock or romstage). This means that
ENV_VERSTAGE is actually 0, and instead ENV_BOOTBLOCK or ENV_ROMSTAGE
are 1. This keeps tripping up people who are just trying to write a
simple "are we in verstage (i.e. wherever the vboot init logic runs)"
check, e.g. for TPM init functions which may run in "verstage" or
ramstage depending on whether vboot is enabled. Those checks will not
work as intended for CONFIG_SEPARATE_VERSTAGE=n.
This patch renames ENV_VERSTAGE to ENV_SEPARATE_VERSTAGE to try to
clarify that this macro can really only be used to check whether code is
running in a *separate* verstage, and clue people in that they may need
to cover the linked-in verstage case as well.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2ff3a3c3513b3db44b3cff3d93398330cd3632ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch restores the permission check for the kernel space which
was dropped when read_space_kernel was moved from Depthcharge by
CL:2155429.
BUG=chromium:1045217, chromium:1020578
BRANCH=none
TEST=none
Signed-off-by: dnojiri <dnojiri@chromium.org>
Change-Id: If6d487940f39865cadc0ca9d5de6e055ad3e017d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40579
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There have been two cases of incompatibilities between overlapping
changes, and they need to be resolved in a single commit to unbreak the
tree:
1. CB:40389 introduced a new use of write_secdata while CB:40359 removed
that function in favor of safe_write.
Follow the refactor of the latter in the code introduced by the former.
2. CB:39849 changed google_chromeec_get_usb_pd_power_info()'s interface
and adapted all its users. Except for duffy and kaisa which were only
added in CB:40223 and CB:40393 respectively, so reapply the patch to
puff's mainboard.c to their mainboard.c files.
Change-Id: Ib8dfcd61bb79e0a487eaa60e719bd93561f2d97a
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Depthcharge trusts that our TPM driver is working reliably,
and so should we. Also remove CRC check -- the value returned
by antirollback_read_space_firmware() is dropped in vboot_logic.c
verstage_main(), and vboot handles this check internally.
BUG=b:124141368, chromium:972956
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I5d3f3823fca8507fd58087bb0f7b78cfa49417ab
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40359
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
These constants were left behind after the code using them
was relocated in CB:34510.
BUG=b:124141368, chromium:972956
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I6ce7c969a9e9bdf6cdce3343ba666a08b3521f27
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
EFS2 allows EC RO to enable PD for special cases. When doing so, it sets
NO_BOOT flag to avoid booting the OS. AP needs to get NO_BOOT flag from
Cr50 and enforce that.
This patch makes verstage get a boot mode and a mirrored hash stored
in kernel secdata from Cr50.
This patch also makes romstage write an expected EC hash (a.k.a. Hexp) to
Cr50 (if there is an update).
BUG=b:147298634, chromium:1045217, b:148259137
BRANCH=none
TEST=Verify software sync succeeds on Puff.
Signed-off-by: dnojiri <dnojiri@chromium.org>
Change-Id: I1f387b6e920205b9cc4c8536561f2a279c36413d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
It turns out the linker's error message already includes the line
number of the dead_code() invocation. If we don't include the line
number in the identifier for our undefined reference, we don't need
individual identifiers at all and can work with a single, global
declaration.
Change-Id: Ib63868ce3114c3f839867a3bfb1b03bdb6facf16
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40240
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
When dead_code() is used in inline functions in a header file, the
generated function names (based on the line number) may collide with
a dead_code() in the code file. Now that we are hit by such a case,
we need a quick solution: Add a tag argument for all invocations in
header files.
Change-Id: I0c548ce998cf8e28ae9f76b5c0ea5630b4e91ae2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Done with sed and God Lines. Only done for C-like code for now.
Change-Id: I51f5764b57fb8b62e3a4b3d41bd32e5330a2983c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40057
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
After measured boot is decoupled from verified boot in CB:35077,
vboot_platform_is_resuming() is never vboot-specific, thus it is
renamed to platform_is_resuming() and declared in bootmode.h.
Change-Id: I29b5b88af0576c34c10cfbd99659a5cdc0c75842
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Currently, those who want to use measured boot implemented within
vboot should enable verified boot first, along with sections such
as GBB and RW slots defined with manually written fmd files, even
if they do not actually want to verify anything.
As discussed in CB:34977, measured boot should be decoupled from
verified boot and make them two fully independent options. Crypto
routines necessary for measurement could be reused, and TPM and CRTM
init should be done somewhere other than vboot_logic_executed() if
verified boot is not enabled.
In this revision, only TCPA log is initialized during bootblock.
Before TPM gets set up, digests are not measured into tpm immediately,
but cached in TCPA log, and measured into determined PCRs right after
TPM is up.
This change allows those who do not want to use the verified boot
scheme implemented by vboot as well as its requirement of a more
complex partition scheme designed for chromeos to make use of the
measured boot functionality implemented within vboot library to
measure the boot process.
TODO: Measure MRC Cache somewhere, as MRC Cache has never resided in
CBFS any more, so it cannot be covered by tspi_measure_cbfs_hook().
Change-Id: I1fb376b4a8b98baffaee4d574937797bba1f8aee
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35077
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
They're listed in AUTHORS and often incorrect anyway, for example:
- What's a "Copyright $year-present"?
- Which incarnation of Google (Inc, LLC, ...) is the current
copyright holder?
- People sometimes have their editor auto-add themselves to files even
though they only deleted stuff
- Or they let the editor automatically update the copyright year,
because why not?
- Who is the copyright holder "The coreboot project Authors"?
- Or "Generated Code"?
Sidestep all these issues by simply not putting these notices in
individual files, let's list all copyright holders in AUTHORS instead
and use the git history to deal with the rest.
Change-Id: I89b10076e0f4a4b3acd59160fb7abe349b228321
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39611
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Just call get_recovery_mode_retrain_switch() directly.
BUG=b:124141368
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Icb88d6862db1782e0218276984e527638b21fd3a
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This patch upgrades the kernel space to v1.0 to accommodate EC hash,
which is used for CrOS EC's early firmware selection.
BUG=chromium:1045217
BRANCH=none
TEST=Boot Helios. Verify software sync works.
Cq-Depend: chromium:2041695
Change-Id: I525f1551afd1853cae826e87198057410167b239
Signed-off-by: dnojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
If the ChromeOS EC uses EC early firmware selection (EFS), the AP vboot
build must also enable EC EFS. Add an option to control this, passing it
through to vboot.
BUG=b:150742950
TEST=none
BRANCH=none
Signed-off-by: Sam McNally <sammc@chromium.org>
Change-Id: I697e90748e19d15af154011413b30c0f2a0bf52e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39272
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Change-Id: I1d36e554618498d70f33f6c425b0abc91d4fb952
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38928
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Peter Lemenkov <lemenkov@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
As part of vboot1 deprecation, remove an unused vboot_struct.h
include. coreboot is now free of vboot1 data structure use.
One vboot_api.h include remains as part of security/vboot/ec_sync.c.
BUG=b:124141368
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I042d692aa252f8f859d4005455eb6a2eabc24a87
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Use vb2api_get_recovery_reason() API function rather
than accessing vb2_shared_data internals.
Of all the vanilla verified boot code in coreboot,
this is the last remaining use of vboot's internal
data structures in coreboot. There remains only one
sole instance in Eltan's code.
BUG=b:124141368, chromium:957880
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I845c9b14ffa830bc7de28e9a38188f7066871803
Signed-off-by: Joel Kitching <kitching@google.com>
Cq-Depend: chromium:2055662
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Since CB:37231 [1], the vboot working data has been replaced with vboot work
buffer, so corrrect the help text of option VBOOT_STARTS_IN_ROMSTAGE
accordingly.
[1] security/vboot: Remove struct vboot_working_data
BRANCH=none
BUG=chromium:1021452
TEST=none
Change-Id: I80783274179ae7582bbb4c8f9d392895623badce
Signed-off-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38900
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
|
|
This was renamed in vboot_reference CL:1977902.
BUG=b:124141368, chromium:965914
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I79af304e9608a30c6839cd616378c7330c3de00a
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37462
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
With CL:1940398, this option is no longer needed. Recovery
requests are not cleared until kernel verification stage is
reached. If the FSP triggers any reboots, recovery requests
will be preserved. In particular:
- Manual requests will be preserved via recovery switch state,
whose behaviour is modified in CB:38779.
- Other recovery requests will remain in nvdata across reboot.
These functions now only work after verstage has run:
int vboot_check_recovery_request(void)
int vboot_recovery_mode_enabled(void)
int vboot_developer_mode_enabled(void)
BUG=b:124141368, b:35576380
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I52d17a3c6730be5c04c3c0ae020368d11db6ca3c
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38780
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Serves two purposes:
(1) On some platforms, FSP initialization may cause a reboot.
Push clearing the recovery mode switch until after FSP code runs,
so that a manual recovery request (three-finger salute) will
function correctly under this condition.
(2) The recovery mode switch value is needed at BS_WRITE_TABLES
for adding an event to elog. (Previously this was done by
stashing the value in CBMEM_ID_EC_HOSTEVENT.)
BUG=b:124141368, b:35576380
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I30c02787c620b937e5a50a5ed94ac906e3112dad
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
These header files need to make use of vb2_shared_data.
Remove the last vestiges of vboot1 data structures in coreboot.
BUG=b:124141368, chromium:1038260
TEST=Build locally with CL:2054269
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I61b27e33751c11aac9f8af261a75d83b003b5f92
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38884
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Part of the design of vboot persistent context is that the workbuf gets
placed in CBMEM and stays there for depthcharge to use in kernel
verification. As such, the space allocated in CBMEM needs to be at least
VB2_KERNEL_WORKBUF_RECOMMENDED_SIZE.
In the VBOOT_STARTS_IN_ROMSTAGE case, prior to this CL, vboot_get_context()
would get invoked for the first time after CBMEM comes up, and it would
only allocate VB2_FIRMWARE_WORKBUF_RECOMMENDED_SIZE.
Initialize the workbuf directly in vboot_setup_cbmem() instead with the
correct VB2_KERNEL_WORKBUF_RECOMMENDED_SIZE.
BUG=b:124141368, chromium:994060
TEST=make clean && make test-abuild
TEST=boot on GOOGLE_EVE with VBOOT_STARTS_IN_ROMSTAGE set
BRANCH=none
Change-Id: Ie09c39f960b3f14f3a64c648eee6ca3f23214d9a
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38778
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Enabling an assertion in vb2_member_of() results in coreboot
linking vb2ex_abort() and vb2ex_printf() in ramstage.
Move these two functions from vboot_logic.c to vboot_lib.c,
which is should be enabled in all stages if CONFIG_VBOOT_LIB
is enabled. Note that CONFIG_VBOOT_LIB is implied by
CONFIG_VBOOT.
Relevant vboot_reference commit: CL:2037263.
BUG=b:124141368, chromium:1005700
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ica0103c5684b3d50ba7dc1b4c39559cb192efa81
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38706
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The eltan verified_boot is using the vboot 2.1 data structures and code,
as well as the fwlib21 build target, they are all deprecated. Refer to
CB:37654 for more information.
The verified_boot code is updated to use the vb2 structures and code and
make sure only public functions are used.
BUG=N/A
TEST=build
Change-Id: I1e1a7bce6110fe35221a4d7a47c1eb7c7074c318
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38590
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
|
|
Having a working board reset is certainly better when you're running
vboot (because otherwise you'll hang when transitioning into recovery
mode), but I don't think it should be strictly required, since it's
still somewhat usable without. This is particularly important for
certain test platforms that don't have a good way to reset but might
still be useful for vboot testing/prototyping.
Change-Id: Ia765f54b6e2e176e2d54478fb1e0839d8cab9849
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38417
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When a VBOOT enabled system is used without ChromeOS it may be valid to
allow the UDC independent of the vboot state.
Provide the option to always allow UDC when CHROMEOS is not selected.
BUG=N/A
TEST=build
Change-Id: I6142c4a74ca6930457b16f62f32e1199b8baaff8
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
When vboot was first integrated into CBFS it was still part of Google
vendorcode. So to not directly tie custom vendorcode into the core CBFS
library, the concept of cbfs_locator was introduced to decouple core
code from an arbitrary amount of platform-specific implementations that
want to decide where the CBFS can be found.
Nowadays vboot is a core coreboot feature itself, and the locator
concept isn't used by anything else anymore. This patch simplifies the
code by removing it and just calling vboot from the CBFS library
directly. That should make it easier to more closely integrate vboot
into CBFS in the future.
Change-Id: I7b9112adc7b53aa218c58b8cb5c85982dcc1dbc0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38419
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I238fce2d48cf62003a701f972a87974415419538
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38198
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Ic6b66dd8fa387e67bb0ce609fb7e2553eeb66b3c
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
As discussed in CB:35077, since both measured boot and verified boot
depends on vboot library, it had better to introduce a dedicated flag
CONFIG_VBOOT_LIB to control the building and linking of the vboot
library, and make other flags needing vboot library select it. Only
the actual verification stuff should be conditional on CONFIG_VBOOT.
Change-Id: Ia1907a11c851ee45a70582e02bdbe08fb18cc6a4
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37787
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
|
|
Change-Id: I0b5c375baf7911ebced2f8c43a88aae014c877ad
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33694
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ia0405fdd448cb31b3c6ca3b3d76e49e9f430bf74
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
Only headers from firmware/lib should be imported.
As far as I can tell, nothing imports 2lib headers
directly anymore, so we can get rid of this CFLAG.
BUG=b:124141368, chromium:968464
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ie5f3fe1d0180113b332e57ed07d4cfe563e7ecf2
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37786
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
CB:37655 updated all secdata_xxx to secdata_firmware_xxx, but forgot the
code that's only compiled when MOCK_SECDATA is set. This patch fixes it.
Change-Id: Icf12fe405d7ce46345ccbdcb76f6aa1b56ed0194
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37772
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Joel Kitching <kitching@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
CB:36845 simplified how coreboot finds the RW CBFS after vboot has and
eliminated a layer of caching. Unfortunately, we missed the fact that
the former cached value didn't exactly match the FMAP section... it was
in fact truncated to the data actually used by vboot. That patch
unintentionally broke this truncation which leads to performance
regressions on certain CBFS accesses.
This patch makes use of a new API function added to vboot (CL:1965920)
which we can use to retrieve the real firmware body length as before.
(Also stop making all the vb2_context pointers const. vboot generally
never marks context pointers as const in its API functions, even when
the function doesn't modify the context. Therefore constifying it inside
coreboot just makes things weird because it prevents you from calling
random API functions for no reason. If we really want const context
pointers, that's a refactoring that would have to start inside vboot
first.)
This patch brings in upstream vboot commit 4b0408d2:
2019-12-12 Julius Werner 2lib: Move firmware body size reporting to
separate function
Change-Id: I167cd40cb435dbae7f09d6069c9f1ffc1d99fe13
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mathew King <mathewk@chromium.org>
|
|
secdata -> secdata_firmware
secdatak -> secdata_kernel
BUG=b:124141368, chromium:972956
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ie2051de51c8f483a8921831385557fad816eb9fb
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This function was removed in CB:33535.
BUG=b:124141368
TEST=make clean && make runtests
BRANCH=none
Change-Id: Ifded75319c92dcbb4befbb3fbecc1cd2df8a9ad0
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37588
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Some return codes were missed when implementing this initially; the vboot
logic can require the system to command the EC to reboot to its RO, switch
RW slots or it can require a poweroff of the SoC. This patch appropriately
handles these return codes.
BUG=b:145768046
BRANCH=firmware-hatch-12672.B
TEST=ODM verified this patch fixes the issues seen.
Change-Id: I2748cf626d49c255cb0274cb336b072dcdf8cded
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
factory_initialize_tpm() calls secdata_xxx_create() (for both firmware
and kernel space) and then immediately writes those spaces out to the
TPM. The create() functions make vboot think it just changed the secdata
(because it reinitialized the byte arrays in the context), so we also
need to clear the VB2_CONTEXT_SECDATA_xxx_CHANGED flags again, otherwise
vboot thinks it still needs to flush the spaces out to the TPM even
though we already did that.
Also clean up some minor related stuff (VB2_CONTEXT_SECDATA_CHANGED
notation is deprecated, and secdata space intialization should use the
same write-and-readback function we use for updates).
Change-Id: I231fadcf7b35a1aec3b39254e7e41c3d456d4911
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37471
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Going forwards, vb2ex_commit_data will be used to flush both
nvdata and secdata.
The patch that is circularly dependent on this lies between a patch that
makes vboot no longer build and the patch that fixes that, so we have to
pull the whole thing in at once to sort out the mess.
Updating from commit id 1c4dbaa0:
2019-11-18 Julius Werner Makefile: Fix typo for MOCK_TPM
to commit id 695c56dc:
2019-12-04 Julius Werner Makefile: Make loop unrolling fully
controllable by the caller
BUG=b:124141368, chromium:1006689
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ia2612da0df101cd3c46151dbce728633a39fada1
Signed-off-by: Joel Kitching <kitching@google.com>
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37315
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I9b2cc1bb58922d9e32202ea4c20b9aacfe308bad
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Since struct vb2_shared_data already contains workbuf_size and
vboot_workbuf_size is never used in depthcharge, remove it from struct
sysinfo_t. In addition, remove lb_vboot_workbuf() and add
CBMEM_ID_VBOOT_WORKBUF pointer to coreboot table with
add_cbmem_pointers(). Parsing of coreboot table in libpayload is
modified accordingly.
BRANCH=none
BUG=chromium:1021452
TEST=emerge-nami coreboot libpayload depthcharge; Akali booted correctly
Change-Id: I890df3ff93fa44ed6d3f9ad05f9c6e49780a8ecb
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
After CB:36808, CB:36844 and CB:36845, all fields except buffer_offset
were removed from struct vboot_working_data. Since buffer_offset is used
to record the offset of the workbuf relative to the whole structure, it
is no longer needed.
This patch removes the structure, and renames vboot_get_working_data()
to vboot_get_workbuf().
BRANCH=none
BUG=chromium:1021452
TEST=emerge-nami coreboot
Change-Id: I304a5e4236f13b1aecd64b88ca5c8fbc1526e592
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
|
|
Change-Id: I9dee03da028b9111b685e325368815a86e444a47
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37028
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
With the persistent vboot context coreboot no longer needs to read GBB
flags from flash itself -- it can just ask vboot for the cached result.
This patch removes the existing GBB code and provides gbb_is_flag_set()
(with a slightly better namespaced name) as a static inline instead.
Change-Id: Ibc3ed0f3fbeb53d630925d47df4dc474b0ed07ee
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
|
|
This macro is already defined in commonlib/helpers.h
Change-Id: I1fce2936757b13807e254f4a844f583b938bf349
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Alex James <theracermaster@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The romcc bootblock will be deprecated soon and most platforms use
C_ENVIRONMENT_BOOTBLOCK already. This patch drops the
CONFIG_C_ENVIRONMENT_BOOTBLOCK symbol and adds CONFIG_ROMCC_BOOTBLOCK
where needed.
Change-Id: I773a76aade623303b7cd95ebe9b0411e5a7ecbaf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37154
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
All cases of testing for __PRE_RAM__ have been converted
to equivalent ENV_xxx definitions from <rules.h>.
Change-Id: Ib6cd598f17109cc1072818cebe4791f7410c3428
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Currently, depthcharge and coreboot are using two different vboot libraries.
coreboot is using "fwlib20", while depthcharge uses "fwlib". The only
difference between the two libraries is the inclusion of vboot1-only
compilation units in fwlib, which are now deprecated. Therefore, coreboot
may as well use fwlib too. Vboot is expected to converge on a single firmware
library soon.
BUG=none
BRANCH=none
TEST=compiles and runs verstage correctly
Change-Id: I905b781c3596965ec7ef45a2a7eafe15fdd4d9cc
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36341
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add 4 new timestamps to the EC software sync flow:
1) Beginning of EC software sync
2) EC finished calculating Vboot hash
3) EC is no longer requesting power limiting
4) End of EC software sync
BUG=none
BRANCH=none
TEST=verified timestamps show up in cbmem log
Change-Id: I6e5703c146b5ec27d01700fdb39cb3d2092ea8a8
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Use the new functions introduced into the EC driver to support
performing EC software sync via vboot callbacks.
NOTE: This patch assumes that the EC image is added to CBFS
uncompressed. Streaming decompression of the image will be added in a
future patch.
Also adds a new Kconfig option VBOOT_EARLY_EC_SYNC. The new Kconfig
option compiles EC software sync into romstage, dependent upon having a
CrOS EC.
BUG=b:112198832
BRANCH=none
TEST=Successful EC software sync
Change-Id: I9b1458a45ab3ed5623af50f78036c4f88461b226
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36208
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Drop struct cbfs_props and replace with struct region_device object.
The goal of the cbfs locator APIs are to determine the correct region
device to find the cbfs files. Therefore, start directly using struct
region_device in the cbfs location paths. Update the users of the API
and leverage the default boot region device implementation for
apollolake.
Change-Id: I0158a095cc64c9900d8738f8ffd45ae4040575ea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Since we already have pre-RAM cache for FMAP (CB:36657), calling
load_firmware() multiple times is no longer a problem. This patch
replaces vboot_get_selected_region() usage with vboot_locate_firmware(),
which locates the firmware by reading from the CBMEM cache.
In addition, returning false from vboot_is_slot_selected() implies the
recovery path was requested, i.e., vb2_shared_data.recovery_reason was
set. Therefore, we simply remove the vboot_is_slot_selected() check from
vboot_check_recovery_request().
BRANCH=none
BUG=chromium:1021452
TEST=emerge-kukui coreboot
Change-Id: I27cb1a2175beb189053fc3e44b17b60aba474bb0
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Since buffer_size is no longer used, remove it from struct
vboot_working_data.
BRANCH=none
BUG=chromium:1021452
TEST=emerge-kukui coreboot
Change-Id: Ie770e89b4a45e0ec703d5bbb8fb6a298ce915056
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Remove vboot_named_region_device(_rw) and use
fmap_locate_area_as_rdev(_rw) directly.
BRANCH=none
BUG=none
TEST=emerge-kukui coreboot
Change-Id: I244ac4e01ae5b80285162b3baffc0b30aa057bfb
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In order to always show the bootlogo very early in coreboot we need the
option to always enable the display when VBOOT is enabled.
To do this a config option is added to make sure this functionality can
be provided without interfering with systems that require the standard
VBOOT display handing.
BUG=N/A
TEST=tested on facebook fbg1701.
Change-Id: I3ffaac85d2082717bb9608d536f7cec66a583789
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
vboot_possibly_executed previously provided some better
compile-time code elimination, before CB:32716 made
vboot_logic_executed capable of that directly.
BUG=b:124141368,
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: If5ca8f03c51e1ced20e1215b1cfdde54da3d001f
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36863
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The comment in the source referred to an earlier approach, so update
it to match current reality.
Change-Id: I9a23ec0a719fb623cfd465c397ef7ef16550b93c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
|
|
Since now we have persistent context, the usage of the flags can be
replaced with vb2_context.flags.
BRANCH=none
BUG=chromium:1021452
TEST=emerge-kukui coreboot
Change-Id: I8e5757a8cc09712c3acde9cbaab910b7498681b4
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
vb2_context object is now stored on the workbuf as part of
vb2_shared_data. Use vboot's new API functions vb2api_init
and vb2api_relocate to create and move the workbuf.
BUG=b:124141368, chromium:994060
TEST=Build locally
BRANCH=none
Change-Id: I051be1e47bf79b15a1689d49a5d4c031e9363dfa
Signed-off-by: Joel Kitching <kitching@google.com>
Also-Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/1902339
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
|
|
In some case where the flash space is limited or when a large payload such as LinuxBoot
is used, the RO region may not be large enough to contain all components that would
normally be added.
This patch adds the possibility to add specific components to the RW regions only in
the same way as the RO_ONLY_SUPPORT does for the RO region.
Please note: this applies only to the items that would normally be added to all regions.
If the payload is directed to the RW region only, a recovery payload needs to be added
to the RO region manually.
BUG=N/A
TEST=build
Change-Id: Ie0df9b5dfc6df4f24efc5582a1aec9ecfb48c44d
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36544
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
With this change cbfs_boot_locate will check the RO (COREBOOT) region if
a file can not be found in the active RW region. By doing so it is not
required to duplicate static files that are not intended to be updated
to the RW regions.
The coreboot image can still be updated by adding the file to the RW
region.
This change is intended to support VBOOT on systems with a small flash
device.
BUG=N/A
TEST=tested on facebook fbg1701
Change-Id: I81ceaf927280cef9a3f09621c796c451e9115211
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36545
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I417a2ff45b4a8f5bc800459a64f1c5a861fcd3d5
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
When prog_locate() is called in the stage VBOOT is starting from and the
image to be loaded is not the target image vboot_prepare() may be called
too early.
To prevent this vboot_prepare() is removed from the vboot_locator
structure. This allows more control over the start of the vboot logic.
To clarify the change the vboot_prepare() has been renamed to
vboot_run_logic() and calls to initialize vboot have been added at the
following places:
postcar_loader: when VBOOT starts in ROMSTAGE
romstage_loader: when VBOOT starts in BOOTBLOCK
ramstage_loader: when VBOOT starts in ROMSTAGE
BUG=N/A
TEST=tested on facebook fbg1701
Change-Id: Id5e8fd78458c09dd3896bfd142bd49c2c3d686df
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36543
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: If6b5930f78c3da6dcefaa7b6202cd0424a24525b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36331
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I3d90e46ed391ce323436750c866a0afc3879e2e6
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36359
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
* Add cbfsoption --ibb to mark files as IBB
* Will be used by "Legacy FIT TXT" boot
Change-Id: I83313f035e7fb7e1eb484b323862522e28cb73d4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
|
|
Required for new VB2_ASSERT and VB2_DIE macros in vboot code.
(See chromium:972956.)
BUG=b:124141368, chromium:1005700
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I61a1036ccab80862d6eb12f9f72286f29e8478cf
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36035
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The HWID in vboot GBB is an identifier for machine model. On Chrome OS,
that should be provisioned in manufacturing process (by collecting real
hardware information), and will be checked in system startup.
For bring up developers, they usually prefer to generate a test-only
string for HWID. However that format was not well documented and cause
problems. Further more, most Chromebooks are using HWID v3+ today while
the test-only HWID is usually v2. Non-Chrome OS developers may also
prefer their own format.
To simplify development process, the GBB_CONFIG now defaults to empty
string, and will be replaced by a board-specific test-only v2 HWID
automatically. Developers can still override that in mainboard Kconfig
if they prefer v3 or other arbitrary format.
BUG=b:140067412
TEST=Built 'kukui' successfully. Removed kukui GBB config and built
again, still seeing correct test HWID.
Change-Id: I0cda17a374641589291ec8dfb1d66c553f7cbf35
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35634
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
With the support of various algorithms and banks in tlcl_extend(),
digest_algo parameter of tpm_extend_pcr() started defining the target
PCR bank in TPM2 case.
The OS expects coreboot to extend the SHA256 bank of BOOT_MODE_PCR.
The value that the OS expects coreboot to extend into BOOT_MODE_PCR
is the SHA1 digest of mode bits extended to the length of SHA256 digest
by appending zero bytes.
Thus the correct value for digest_algo passed into tpm_extend_pcr() for
BOOT_MODE_PCR is TPM_ALG_SHA256.
This didn't matter until adding the support for multiple digest introduced
by patches like https://review.coreboot.org/c/coreboot/+/33252, as
tlcl_extend always used SHA256 bank before.
Change-Id: I834fec24023cd10344cc359117f00fc80c61b80c
Signed-off-by: Andrey Pronin <apronin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35476
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ibaeda2762c733fdbe48979b635cc0cfd7ee4295d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35387
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Fastboot support in vboot_reference is unused, unmaintained, and
produces compile errors when enabled. Since there is no current
or planned use cases for fastboot, remove it.
BUG=b:124141368, chromium:995172
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I06ea816ffb910163ec2c3c456b3c09408c806d0b
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35002
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
To make explicit when vboot2 error codes should be returned,
use the new vb2_error_t type on all functions which return
VB2_ERROR_* constants.
Additionally, add required vboot submodule commit id e6700f4c:
2019-07-31 14:12:30 +0800 - (vboot: update vboot2 functions to use new vb2_error_t)
NOTE: This patch was merged separately on the Chromium tree:
https://chromium-review.googlesource.com/c/1728499
BUG=b:124141368, chromium:988410
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I804c2b407e496d0c8eb9833be629b7c40118415c
Signed-off-by: Joel Kitching <kitching@google.com>
Cq-Depend: chromium:1728292
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Previously, the initial value for secdatak was embedded
in secdata_tpm.c as a uint8_t array. Switch to using
vb2api_secdatak_create instead, and write the value in
ctx->secdatak.
Remove an unnecessary call to vb2api_secdata_create in
_factory_initialize_tpm.
BUG=b:124141368, chromium:972956
TEST=make clean && make test-abuild
BRANCH=none
TEST=Check that size and value of initial secdatak
has not changed. Apply the patch below and
check for this output:
_factory_initialize_tpm():266: _factory_initialize_tpm: secdatak sizes are identical? 1
_factory_initialize_tpm():269: _factory_initialize_tpm: secdatak values are identical? 1
diff --git a/src/security/vboot/secdata_tpm.c b/src/security/vboot/secdata_tpm.c
index ff62185107..c1818b482f 100644
--- a/src/security/vboot/secdata_tpm.c
+++ b/src/security/vboot/secdata_tpm.c
@@ -148,6 +148,18 @@ static uint32_t write_secdata(uint32_t index,
return TPM_E_CORRUPTED_STATE;
}
+/*
+ * This is derived from rollback_index.h of vboot_reference. see struct
+ * RollbackSpaceKernel for details.
+ */
+static const uint8_t secdata_kernel[] = {
+ 0x02,
+ 0x4C, 0x57, 0x52, 0x47,
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00,
+ 0xE8,
+};
+
/*
* This is used to initialize the TPM space for recovery hash after defining
* it. Since there is no data available to calculate hash at the point where TPM
@@ -250,6 +262,11 @@ static uint32_t _factory_initialize_tpm(struct vb2_context *ctx)
* indication that TPM factory initialization was successfully
* completed.
*/
+ VBDEBUG("%s: secdatak sizes are identical? %d\n", __func__,
+ sizeof(secdata_kernel) == sizeof(ctx->secdatak));
+ VBDEBUG("%s: secdatak values are identical? %d\n", __func__,
+ memcmp(secdata_kernel, ctx->secdatak,
+ sizeof(secdata_kernel)) == 0);
RETURN_ON_FAILURE(set_kernel_space(ctx->secdatak));
if (CONFIG(VBOOT_HAS_REC_HASH_SPACE))
@@ -452,7 +469,7 @@ uint32_t antirollback_read_space_firmware(struct vb2_context *ctx)
/* Read the firmware space. */
rv = read_space_firmware(ctx);
- if (rv == TPM_E_BADINDEX) {
+ if (true) {
/*
* This seems the first time we've run. Initialize the TPM.
*/
Change-Id: I74261453df6cc55ef3f38d8fb922bcc604084c0a
Signed-off-by: Joel Kitching <kitching@google.com>
Cq-Depend: chromium:1652874, chromium:1655049
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
vboot_setup_tpm returns (TPM_SUCCESS == 0) on success.
In this case, call antirollback_read_space_firmware.
This regression was introduced in CB:34510.
BUG=b:139101213
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ifdea1d85167a50a1ada5afe9b107408e3a2e0d6f
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34790
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Reviewed-by: caveh jalali <caveh@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add support for Intel PTT. For supporting Intel PTT we need to disable
read and write access to the TPM NVRAM during the bootblock. TPM NVRAM
will only be available once the DRAM is initialized. To circumvent this,
we mock secdata if HAVE_INTEL_PTT is set. The underlying problem is,
that the iTPM only supports a stripped down instruction set while the
Intel ME is not fully booted up. Details can be found in Intel document
number 571993 - Paragraph 2.10.
Change-Id: I08c9a839f53f96506be5fb68f7c1ed5bf6692505
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This reverts commit 598af2e2c2785c00eb4290cdcefe1082b2a6f858.
Reason for revert: This commit breaks every board with VBOOT enabled
if the platform is apollolake, broadwell, skylake, baswell, baytrails
or icelake. The reason is, that the SoC selects
VBOOT_MUST_REQUEST_DISPLAY by default, and this has a dependency now
on VBOOT_MAY_SKIP_DISPLAY_INIT. This will only be auto-selected if
it is a CHROMEOS platform.
Change-Id: I3872d9aa993326ded135d8a5d950d5b1b1eddf34
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34308
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Relocate call to vboot_save_recovery_reason_vbnv and rename
vb2_clear_recovery_reason_vbnv for consistency.
BUG=b:124141368, b:124192753
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I111cc23cf3d4b16fdb058dd395ac17a97f23a53f
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
vboot_handoff is no longer used in coreboot, and is not
needed in CBMEM or cbtable.
BUG=b:124141368, b:124192753
TEST=make clean && make runtests
BRANCH=none
Change-Id: I782d53f969dc9ae2775e3060371d06e7bf8e1af6
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33536
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This config option, when set, will allow the platform to skip display
initialization in normal (non-developer, non-recovery) mode. This allows
platforms that do not implement firmware UI in normal mode to skip the
display init in firmware.
TEST=Set option CONFIG_VBOOT and clear CONFIG_VBOOT_MAY_SKIP_DISPLAY_INIT
and the display should initialize in ramstage when platform boots. Set
CONFIG_VBOOT and set CONFIG_VBOOT_MAY_SKIP_DISPLAY_INIT and the display
initialization should be skipped in coreboot.
Signed-off-by: Sukerkar, Amol N <amol.n.sukerkar@intel.com>
Change-Id: Icadad6da34dcb817af02868e89a94ea62dbfa7b3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
When we added CONFIG_VBOOT_MIGRATE_WORKING_DATA, the idea was that on
some Arm platforms the original working data buffer was in SRAM, which
stays accessbile for the whole runtime of the system. There is no reason
to migrate it into CBMEM on those platforms because ramstage and the
payload could continue to access it in SRAM.
Now that we've had a couple of months of experience with this option, we
found that most of our Arm platforms have some issue that requires
migrating anyway, because BL31 often claims SRAM for itself and makes it
inaccessible to the payload. On the remaining platforms, accessing SRAM
from the payload is possible but still an issue, because libpayload
doesn't have enough memory layout information to set up proper page
tables for it, so we're accessing it uncached and at risk of alignment
errors.
Rather than having to figure out how to map the right SRAM range for
every platform in the payload, let's just get rid of the option.
memcpy()ing 12KB isn't worth this much hassle.
Change-Id: I1b94e01c998f723c8950be4d12cc8f02b363a1bf
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
Depthcharge no longer reads this data structure, and uses
the vboot workbuf in vboot_working_data instead.
Since vboot2 downstream migration is not yet completed, the
vboot2 -> vboot1 migration code is still required, but has
been relocated to depthcharge.
BUG=b:124141368, b:124192753
TEST=make clean && make runtests
BRANCH=none
Change-Id: I769abbff79695b38d11fb6a93c2b42f64d4bafde
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33535
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I3b5ca272abffe46c6a63251cf4905780f87a6836
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33540
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Logging and clearing the recovery mode switch doesn't have
anything to do with vboot_handoff. Move it to the main verstage
logic file.
BUG=b:124141368, b:124192753
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I2e74f3893463e43fe5fad4a8df8036560f34e0db
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33534
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
These functions are no longer used and may be removed:
* vboot_handoff_check_recovery_flag
* vboot_get_handoff_flag
BUG=b:124141368, b:124192753
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ie05652ef1288eef74bd2e7e8bea79fd29d523859
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33533
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Two functions retrieve vboot recovery_reason:
* vboot_handoff_get_recovery_reason
* vboot_get_recovery_reason_shared_data
Previously, when CBMEM comes online, a vboot_handoff data
structure is created, and depending on the architecture,
coreboot may eventually lose access to vboot_working_data.
After implementing vboot_working_data CBMEM migration,
vboot_working_data is always guaranteed to be accessible.
vboot_get_recovery_reason_shared_data is corrected to also
allow accessing vboot_working_data in ramstage and postcar.
Now, vboot_handoff_get_recovery reason returning a valid recovery
reason implies that vboot_get_recovery_reason_shared_data should
*also* return a valid recovery reason. Thus we may remove the
former.
BUG=b:124141368, b:124192753
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Iac216dc968dd155d9d4f8bd0f2dfd5034762f9a0
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33532
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Recovery path should finalize work context, and trim
vboot_working_data buffer_size. Otherwise, depthcharge ingests
the full 12 KB workbuf in recovery path.
BUG=chromium:972528, b:134893812
TEST=Build with vboot_reference CL:1584488. Check that USB disks
are properly verified in recovery path.
BRANCH=none
Change-Id: Icf2600d2eb5d846a26aec35a153946dd2f7f128c
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Add a new post code, POST_INVALID_ROM, used when coreboot fails to
locate or validate a resource that is stored in ROM.
BUG=b:124401932
BRANCH=sarien
TEST=build coreboot for sarien and arcada platforms
Change-Id: Ie6de6590595d8fcdc57ad156237fffa03d5ead38
Signed-off-by: Keith Short <keithshort@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32770
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Display is required by recovery mode. Determine display init
before recovery check.
BUG=b:133197727,b:133175864
TEST=enter recovery mode, checked the display shows up
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Id6ac611f51241373bca3e2b394a94dcd52d3fde7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
vboot_measure_cbfs_hook() is included when CONFIG_VBOOT_MEASURED_BOOT
is enabled, but this function is defined as 0 in vboot_crtm.h using ENV_
Remove ENV_ for vboot_measure_cbfs_hook() function definition.
This function is added to bootblock stage also.
BUG=NA
TEST=Build Google Banon and Google Cyan
Change-Id: Ic62c18db09c119dfb85340a6b7f36bfd148aaa45
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32532
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Save whether or not vboot has selected developer mode as a flag
in vboot_working_data. Other coreboot code may access this flag
without needing to consult vboot_handoff (which is in the process
of being deprecated).
BUG=b:124141368, b:124192753
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ieb6ac4937c943aea78ddc762595a05387d2b8114
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32843
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
As of CL:1605641, vboot2 code should be used for setting and
checking display init state. Remove all vboot1 OPROM-related
code, and use the vboot2 display init code which has already
been added in previous commits.
coreboot should not be reading vboot NVRAM flags directly.
Remove the function vboot_wants_oprom(), and instead rely on
display_init_required(), which uses the
VBOOT_WD_FLAG_DISPLAY_INIT value stored in
vboot_working_data.flags, initialized during verstage.
Note that this means in the case of CONFIG_VBOOT=y, the return
value of display_init_required() can only be trusted after
verstage has been executed. This should not be a problem
assuming that all display initialization occurs in ramstage.
BUG=b:124141368, b:124192753, chromium:948529
TEST=Build locally
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ic8f9dc5a3c7f1546a8fed82bde02be4d04568f8d
Signed-off-by: Joel Kitching <kitching@google.com>
Cq-Depend: chromium:1605641, chromium:1605525
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32723
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Verified Boot OPROM code is being refactored. OPROM is being
generalized into "display initialization". As such, the NVRAM
request flag is being renamed from OPROM_NEEDED to
DISPLAY_REQUEST.
BUG=b:124141368, b:124192753, chromium:948529
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I74374abf7d1deb594c073f7a4a76c9de46092143
Signed-off-by: Joel Kitching <kitching@google.com>
Cq-Depend: chromium:1605640
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This patch moves vboot_logic_executed() (and its dependencies) into a
header and turns it into a static inline function. The function is used
to guard larger amounts of code in several places, so this should allow
us to save some more space through compile-time elimination (and also
makes it easier to avoid undefined reference issues in some cases).
Change-Id: I193f608882cbfe07dc91ee90d02fafbd67a3c324
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32716
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
|
|
This patch adds another check to vboot_logic_executed() to make sure we
only do a runtime check for verstage_should_load() if
CONFIG_VBOOT_RETURN_FROM_VERSTAGE is enabled. That's the only case where
the stage that's loading the verstage can execute after verification has
run (because the verstage will return to it when it's done). In the
other case, the stage that loads verstage really just loads it and will
never do anything again after hand-off, so it's guaranteed to always
execute before verification.
This change may allow extra dead-code elimination in some cases.
Change-Id: I7019b6f7b0acfbf0a8173914b53364751b08f2cf
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32714
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|