| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I5cd04972936c14d92295915fad65c7a45a8108d9
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This patch adds a GBB flag to coreboot, which, when enabled, enforces
CSE sync even if the current CSE version matches the version in CBFS.
The CSME sync GBB and flag are designed to enhance autotest
functionalities and are not intended or recommended for use in
developing any other features.
BUG=b:353053317
TEST=futility gbb --help
Cq-Depend: chromium:5718196
Change-Id: I6352959e1e898a90b4c6e12a22f8d6513f90ded9
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83685
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Most x86 platforms use CMOS as the vboot nvdata (VBNV) backend storage.
On some platforms such as AMD, certain CMOS registers must be configured
before accessing the CMOS RAM which contains VBNV. More precisely,
according to AMD's spec [1], the bit 4 of Register A of CMOS is bank
selection. Since VBNV is accessed via bank 0 (see the MC146818 driver),
the bit must be cleared before the VBNV can be successfully written to
CMOS. Saving VBNV to CMOS may fail in verstage, if CMOS has lost power.
In that case, all the CMOS registers would contain garbage data.
Therefore, for AMD platforms the bit must be cleared in verstage, prior
to the first save_vbnv_cmos() call.
Introduce vbnv_platform_init_cmos(), which is no-op by default, and can
be defined per platform. The function will be called from vbnv_init() if
VBOOT_VBNV_CMOS.
[1] 48751_16h_bkdg.pdf
BUG=b:346716300
TEST=none
BRANCH=skyrim
Change-Id: Ic899a827bd6bb8ab1473f8c6c03b9fde96ea6823
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83494
Reviewed-by: Bao Zheng <fishbaozi@gmail.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
If BMP_LOGO is set, currently display_init_required() will always return
1, so that platform code will always initialize display. However, that
information isn't passed to vboot, which may result in unnecessary extra
reboots, for example when the payload needs to request display init (by
vb2api_need_reboot_for_display()).
Since there is already a Kconfig option VBOOT_ALWAYS_ENABLE_DISPLAY to
tell vboot that "display is available on this boot", enable it by
default if BMP_LOGO is set.
BUG=b:345085042
TEST=none
BRANCH=none
Change-Id: I20113ec464aa036d0498dedb50f0e82cb677ae93
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83256
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Most of the original secdata_tpm.c was TPM2-specific implementation.
Just moving the code around, with trivial tweaks:
- drop now unnecessary #ifdef directives from _factory_initialize_tpm()
- drop leading underscore from _factory_initialize_tpm{1,2}() (external
identifiers should not start with an underscore in C)
- drop unused <security/vboot/tpm_common.h> include and sub-includes of
tss.h which should be considered its part (so this isn't an indirect
inclusion)
- fixed formatting of RETURN_ON_FAILURE() which didn't have slashes
aligned no matter what tab width was used
Change-Id: I0090b748d7d3b2d76a941b87b5885682fd81c4fc
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81415
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This prepares the code for enabling both CONFIG_TPM1 and CONFIG_TPM2
during compilation, in which case actual TPM family in use can be
determined at runtime.
In some places both compile-time and runtime checks are necessary.
Yet in places like probe functions runtime state checks don't make sense
as runtime state is defined by results of probing.
Change-Id: Id9cc25aad8d1d7bfad12b7a92059b1b3641bbfa9
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69161
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
No functional changes. Refactor code such that there won't be any
compiler or linker errors if TSS 1.2 and TSS 2.0 were both compiled
in.
One might want to support both TPM families for example if TPM is
pluggable, while currently one has to reflash firmware along with
switching TPM device.
Change-Id: Ia0ea5a917c46ada9fc3274f17240e12bca98db6a
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This also sets a good default in arch and vboot to have a separate
romstage when it makes sense.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I09ab5f8c79917bf93c9d5c9dfd157c652478b186
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80580
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch passes the correct flag to vboot to enable SIMD crypto
acceleration on arm64 devices. This uses a core part of the ISA and
should thus be supported on all arm64 SoCs -- so we normally always
want it enabled, but there should still be a Kconfig in case a SoC wants
to use the hwcrypto interface for its own (off-CPU) crypto acceleration
engine instead. (You could also disable it to save a small amount of
code size at the cost of speed, if necessary.)
Change-Id: I3820bd6b7505202b7edb6768385ce5deb18777a4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I41f8a9b5d1bdb647a915da1a5e95161b2e34df28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80082
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
To verify the boot chain, we will need to extend the PCR with the
firmware version. And the server will be able to attest the firmware
version of devices.
The "firmware version" here is the RW firmware anti-rollback version,
determined by the ChromeOS's signing infra, and will be verified in
vb2api_fw_phase3, by comparing it with the version stored in the TPM.
This version will be increased when there is critical vulnerability
in the RW firmware.
According to [1], PCRs 8-15 usage is defined by Static OS. Therefore
PCR_FW_VER is chosen to be within that range. Ideally the existing
PCR_BOOT_MODE and PCR_HWID should also be allocated in the same range,
but unfortunately it's too late to fix them. Because PCRs 11 and 13
have been used for other purposes in ChromeOS, here PCR_FW_VER is set
to 10.
[1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_05_3feb20.pdf
BUG=b:248610274
TEST=Boot the device, and check the PCR 10
BRANCH=none
Signed-off-by: Yi Chou <yich@google.com>
Change-Id: I601ad31e8c893a8e9ae1a9cdd27193edce10ec61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79437
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add `VBOOT_X86_RSA_ACCELERATION' Kconfig option to enable SSE2
instruction set implementation of modulus exponentiation which is part
of the RSA signature verification process.
BUG=b:312709384
TEST=Able to use SSE2 accelerated implementation on rex0
Change-Id: Ib6e39eb9f592f36ad3dca76c8eaf2fe334704265
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79289
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This updates all warnings currently being printed under the files_added
and build_complete targets to the show_notices target.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia14d790dd377f2892f047059b6d24e5b5c5ea823
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79423
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
vboot_fw.a is built via a sub-invocation of make, but make is not able
to track dependencies between different invocations. That means the
toplevel make assumes that the vboot_fw.a target depends only on the
dependencies explicitly listed in coreboot's Makefile (only config.h in
this case), and thus assumes that if config.h didn't change it does not
need to rebuild the library. This breaks incremental builds when files
inside the vboot repository change.
This patch marks the target as .PHONY so that it will always be rebuilt.
The vboot Makefile's own dependency tracking will then ensure that on an
incremental build we only rebuild the vboot sources that actually
changed, so if nothing changed this will just add a simple and quick
$(AR) call.
Change-Id: I8bdd4e1589124914ba1e877e04b40ee709ea4140
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79375
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
For ChromeOS platform the recovery reason is cleared in
vb2api_kernel_phase2 which is probably not called by any non-ChromeOS
system. It results in the platform being stuck in recovery mode, e.g.
when RW firmware verification fails. Even if the RW partition is
flashed with correctly signed image, the persistent non-zero recovery
reason will prevent vboot from attempting the RW partition check.
Use the newly exposed vb2api_clear_recovery and
VBOOT_CLEAR_RECOVERY_IN_RAMSTAGE Kconfig option to clear the recovery
reason and save it immediately to the VBNV. The idea is to let
non-ChromeOS coreboot platform to clear the recovery reason when
needed.
TEST=Clear the recovery reason in mainboard_final function right
before payload jump when RW partition is corrupted and RW partition is
valid. In case it is corrupted, the platform stays in recovery mode,
when valid the platform boots from RW partition. Tested on MSI PRO
Z690-A DDR4.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I7ffaf3e8f61a28a68c9802c184961b1b9bf9d617
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74343
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The code for "phase 4" of firmware verification currently only sets a
recovery reason when there's an actual hash mismatch detected in
vb2api_check_hash_get_digest(). This is the most likely way how this
section of code can fail but not the only one. If any other unexpected
issue occurs, we should still set a recovery reason rather than just
reboot and risk an infinite boot loop.
This patch adds a catchall recovery reason for any error code that falls
out of this block of code. If a more specific recovery reason had
already been set beforehand, we'll continue to use that -- if not, we'll
set VB2_RECOVERY_FW_GET_FW_BODY.
Change-Id: If00f00f00f00aa113e0325aad58d367f244aca49
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78866
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In vboot_get_context(), vb2api_reinit() is called to restore the vboot
context from the previous stage. We use assert() for the return value of
vb2api_reinit() because there shouldn't be runtime errors, except for
one edge case: vb2_shared_data struct version mismatch. More precisely,
when RW firmware's VB2_SHARED_DATA_VERSION_MINOR is greater than RO's,
vb2api_reinit() will return VB2_ERROR_SHARED_DATA_VERSION.
To avoid using an invalid vb2_context pointer (when FATAL_ASSERTS is
disabled), change assert() to die() on vb2api_reinit() failure. For the
vb2api_init() case the assertion is unchanged because there shouldn't be
any runtime error for that.
Also move the vb2api_init() call outside the assert() argument, as
assert() may be a no-op macro depending on the implementation.
Change-Id: I4ff5ef1202bba2384c71634ec5ba12db1b784607
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Having a separate romstage is only desirable:
- with advanced setups like vboot or normal/fallback
- boot medium is slow at startup (some ARM SOCs)
- bootblock is limited in size (Intel APL 32K)
When this is not the case there is no need for the extra complexity
that romstage brings. Including the romstage sources inside the
bootblock substantially reduces the total code footprint. Often the
resulting code is 10-20k smaller.
This is controlled via a Kconfig option.
TESTED: works on qemu x86, arm and aarch64 with and without VBOOT.
Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This reverts commit 7499d9610016c4a89b722498885f196ed6d217aa.
Reason for revert: coreboot build fails
Change-Id: I8ef853d81ee9b1f18d36dfd82cdf687381ece2c6
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78845
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
The code for "phase 4" of firmware verification currently only sets a
recovery reason when there's an actual hash mismatch detected in
vb2api_check_hash_get_digest(). This is the most likely way how this
section of code can fail but not the only one. If any other unexpected
issue occurs, we should still set a recovery reason rather than just
reboot and risk an infinite boot loop.
This patch adds a catchall recovery reason for any error code that falls
out of this block of code. If a more specific recovery reason had
already been set beforehand, we'll continue to use that -- if not, we'll
set VB2_RECOVERY_FW_GET_FW_BODY.
Change-Id: If00f8f8a5d17aa113e0325aad58d367f244aca49
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78821
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The macro ENV_HAS_CBMEM achieves the same as this inline function.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I6d65ca51c863abe2106f794398ddd7d7d9ac4b5e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77166
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
|
|
Add additional failure mode logic for the TPM to enable an
automated recovery mode for GSC hangs.
BUG=b:296439237
TEST=Force the error by hard coding the return code and observe the
device entering hibernate.
BRANCH=None
Change-Id: Ieec7e9227d538130354dea8b772d0306cdda1237
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77667
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Convert TPM functions to return TPM error codes(referred to as
tpm_result_t) values to match the TCG standard.
BUG=b:296439237
TEST=build and boot to Skyrim
BRANCH=None
Change-Id: Ifdf9ff6c2a1f9b938dbb04d245799391115eb6b1
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77666
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Convert hex print values to use the %#x qualifier to print 0x{value}.
BUG=b:296439237
TEST=build and boot to Skyrim
BRANCH=None
Change-Id: I0d1ac4b920530635fb758c5165a6a99c11b414c8
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78183
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Adopt TCG standard naming and definitions for TPM Return codes.
BUG=b:296439237
TEST=Build and boot to OS on skyrim
BRANCH=None
Change-Id: I60755723262ec205a4c134948b0250aac4974d35
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77665
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This PCR digest length check is no longer necessary.
Signed-off-by: Yi Chou <yich@google.com>
Change-Id: I256938c69be7787f5c8fca3e633ac93a69368452
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78084
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Remove the unnecessary tss_common.h header from the repo.
tss_errors.h is a more appropriate place for the TPM_SUCCESS
value, and the other define is only used by tpm_common.c and
can be placed there.
BUG=b:296439237
TEST=Builds
Change-Id: I99cf90f244a75c1eeab5e9e1500e05c24ae0a8e5
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78033
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Make naming convention consistent across all functions return values.
BUG=b:296439237
TEST=Boot to OS on Skyrim
BRANCH=None
Change-Id: If86805b39048800276ab90b7687644ec2a0d4bee
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77536
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Add the TPM return code to the vboot fail call to provide additional
context.
BUG=None
TEST=builds
Change-Id: Ib855c92d460d1e728718b688ff71cdc6e1d9a84a
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77944
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
Since vboot_extend_pcr() returns vb2_error_t, the return type of
extend_pcrs() should be vb2_error_t too.
Also fix an assignment for vboot_locate_firmware(), which returns int
instead of vb2_error_t.
Change-Id: I1a2a2a66f3e594aba64d33cfc532d1bd88fa305e
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
coreboot offers two vboot schemes VBOOT_SLOTS_RW_A and
VBOOT_SLOTS_RW_AB. When VBOOT_SLOTS_RW_AB is not selected then the
resulting image is rather not expected to have the FW_MAIN_B FMAP
region. When only RW_A region is used, vboot does additional full_reset
cycles to try RW_B, even though it does not exist / the build was not
configured for two RW partitions. To avoid it, a new vboot context
flag has been introduced, VB2_CONTEXT_SLOT_A_ONLY, which can be set
right after context initialization to inform vboot about absence of
slot B. This will result in less full_reset cycles when vboot runs
out of available slots and cause vboot to switch to recovery mode
faster.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ie123881a2f9f766ae65e4ac7c36bc2a8fce8d100
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75462
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Recent ChromeOS devices use Ti50 instead of Cr50. Therefore, some
strings or comments are not accurate anymore. When applicable, rename
Cr50 to GSC (Google security chip).
BUG=b:275544927
TEST=./util/abuild/abuild -x -t GOOGLE_TOMATO -a
BRANCH=none
Cq-Depend: chromium:4756700
Change-Id: Ie5b9267191a5588830ed99a8382ba1a01933028f
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77100
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
|
|
The static function read_space_firmware() is used only once, so merge it
into antirollback_read_space_firmware(). Also change a debug log to
error.
BUG=none
TEST=emerge-geralt coreboot
BRANCH=none
Change-Id: I8abcb8b90e82c3e1b01a2144070a5fde6fe7157f
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
|
|
Commit d054bbd4f1ba ("Makefile.inc: fix multiple jobs build issue")
added a dependency on $(obj)/fmap_config.h to all .c source files in all
stages, so it's not needed any more to add it as a dependency to files
that include fmap_config.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7b62917f32ae9f51f079b243a606e5db07ca9099
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76002
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Board IDs are now filled in as part of the signing process, so we don't
need to set them in coreboot.
BUG=b:240620735
TEST=Build and check VBOOT_GSC_BOARD_ID is set to ZZCR.
Change-Id: I7dda8ad59046a1dd9a28595e037eda86e91c98df
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75641
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
vboot code changes have eliminated the redundant call to WP the EC-RO
region as protecting RW flash implies protecting both RO and RW flash,
so the call to protect RO is redundant. google/rex currently takes
about 17 ms to lock down the EC.
Along with vboot changes, this patch drops argument to choose between
RO and RW slot to protect while calling into `vb2ex_ec_protect()`.
It ensures vb2ex_ec_protect() is explicitly meant for protecting RW
regions.
w/o this patch:
517:waiting for EC to allow higher power draw 846,196 (17,297)
w/ this patch:
517:waiting for EC to allow higher power draw 838,258 (9,719)
Additionally, update vboot submodule to upstream main to avoid the
compilation error.
Updating from commit id 35f50c3154e5:
Fix build error when compiling without -DNDEBUG
to commit id 034907b279c9db:
vboot_reference: eliminate redundant call to write protect EC-RO
Change-Id: I2974f0cb43ba800c2aaeac4876ebaa052b5ee793
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75521
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Harsha B R <harsha.b.r@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
At this moment, only GBB flags are moved from PCR-0 to PCR-1 when
vboot-compatibility is not enabled.
Change-Id: Ib3a192d902072f6f8d415c2952a36522b5bf09f9
Ticket: https://ticket.coreboot.org/issues/424
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68750
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
Currently this is only used in bootblock and expects a fixed offset.
Change-Id: I3c4db6fffe3343f12383fe9585620ffefb01cf81
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
|
|
After first recovery request coreboot would get stuck in bootloop with
VB2_RECOVERY_PREAMBLE as recovery reason due to not checking whether
coreboot is alread in recovery mode, and calling failing code.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Idc947a1d150ff6487cf973b36bf4f0af41daa220
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Add Kconfig option for VBOOT_ARMV8_CE_SHA256_ACCELERATION, which will
use ARMv8 Crypto Extension for SHA256[1] instead of software
implementation.
This will speed up firmware verification in verstage.
[1] https://crrev.com/c/4170144
BUG=b:263514393
BRANCH=corsola
TEST='calculating body hash (SHA2)' get 13 msecs improvement on
Tentacruel.
Before:
509:finished calculating body hash (SHA2) 161,548 (14,490)
After:
509:finished calculating body hash (SHA2) 155,101 (1,187)
Change-Id: I02671338fd9e0deb5294dbb7c03528061edc18c4
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72711
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add methods to store and retrieve the hash of the data stored in the
VBIOS cache FMAP region. Add a dedicated index in TPM NVRAM to store
the hash, and methods to calculate/read/write it.
Modeled after mrc_cache_hash_tpm.{c,h}
BUG=b:255812886
TEST=tested with rest of patch train
Change-Id: I030017d3bf956b8593bc09073ad6545b80a5b52b
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
We don't need flashrom support just for vboot payloads. The current
default (USE_FLASHROM=1) is mostly harmless, especially if libflashrom
is not present (the autodetection in vboot_reference just spits out a
pkg-config error but doesn't actually fail the build), but it's better
to be clear we don't need it.
BUG=b:172225709
TEST=build
Change-Id: I53bcc2d1e7666646ddad58ba3717cfdd321014e8
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72716
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
This avoids runtime failures of lacking a RW_NVRAM section in fmap or
one having a size too small.
Change-Id: I3415bd719428a23b21210eb2176dbe15fa44eb9c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71868
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I2af3bc9bf9eaf258b9180da5fc5494b21764f379
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71518
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It's true that vbnv_udc_enable_flag() is called after vbnv_init()
(that's why the assertion was added). However, the former is called in
the ramstage, while the latter in verstage. This means that
vbnv_initialized will be false in ramstage, which leads
to the assertion failure:
[EMERG] ASSERTION ERROR: file 'src/security/vboot/vbnv.c', line 88
Since the ctx->nvdata will be restored in ramstage (by vb2api_reinit()),
simply remove the assertion. So, the patch drops assert call from
vbnv_udc_enable_flag() function.
TEST=Verify Rex system boots to OS without assert error.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I49022155239febd5c5be5cf2c5eca2019ca61c12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
If the temporary nvdata storage inside the vboot context is already
initialized then return immediately without reinitializing from the
backup NV storage. This allows vbnv_init to be called more than once.
Also the check to enable USB Device Controller (UDC) happens after
NVdata is initialized. Hence the nvdata in vboot context can be used
instead of reading from the backup storage again.
BUG=b:242825052
TEST=Build Skyrim BIOS image and boot to OS in Skyrim.
Change-Id: Id72709e2fc3fe6a12ee96df8df25e55cf11e50a7
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
CONFIG_VBOOT_CBFS_INTEGRATION images are signed differently than normal
images. futility needs to be able to tell this difference, and it parses
the `config` file included in CBFS to do this. This change codifies that
dependency in Kconfig so that nobody can accidentally break this by
turning off config file inclusion.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2b2d245b850bc65abb4e72f20b4e360312c828f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70157
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Adjust asserts to allow to store and compare (at S3 resume) hashes
without padding to maximum hash length / slot size.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: If6d46e0b58dbca86af56221b7ff2606ab2d1799a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Compilers are not optimizing-out code correctly. This patch fixes
incorrect behavior by splitting if statement and extracting code to
another function, this allowing for better code size optimization and
reduction of undefined references.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ia5330efeeb4cfd7477cf8f7f64c6abed68281e30
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69761
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Change-Id: Ic64625bdaf8c4e9f8a5c1c22cece7f4070012da7
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69903
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ibd41382d0e0ef58498ac925dc9e10b54a76a798a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69800
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This removes the dev_index argument from the google_chromeec_reboot
API. It's always set to 0, so don't bother passing it.
BUG=b:258126464
BRANCH=none
TEST=none
Change-Id: Iadc3d7c6c1e048e4b1ab8f8cec3cb8eb8db38e6a
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69373
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch introduces support signing and verification of firmware
slots using CBFS metadata hash verification method for faster initial
verification. To have complete verification, CBFS_VERIFICATION should
also be enabled, as metadata hash covers only files metadata, not their
contents.
This patch also adapts mainboards and SoCs to new vboot reset
requirements.
TEST=Google Volteer/Voxel boots with VBOOT_CBFS_INTEGRATION enabled
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I40ae01c477c4e4f7a1c90e4026a8a868ae64b5ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66909
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch groups vboot context, recovery reason and subcode saving, and
reboot calls into two handy functions:
- vboot_save_and_reboot() - save context and reboot
- vboot_fail_and_reboot() - store recovery reason and call function
above
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ie29410e8985e7cf19bd8d4cccc393b050ca1f1c5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69208
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Currently build rules allow using x86 SHA extensions for all coreboot
stages when enabled. On some SoCs where verstage can run in non-x86
environment, x86 SHA extension cannot be used. Update build rules
accordingly such that x86 SHA extensions can be used in AMD SoCs. This
is particularly useful when CBFS verificiation is enabled which verifies
the hash of the CBFS file being loaded.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim. Observe that hardware acceleration
is used when a CBFS file is loaded and observe an overall improvement of
10 ms.
Change-Id: I4f388e963eb82990cda41d3880e66ad937334908
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68953
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Create an NVRAM space in TPM 2.0 that survives owner clear and can be
read and written without authorization. This space allows to seal data
with the TPM that can only be unsealed before the space was cleared.
It will be used during ChromeOS enterprise rollback to securely
carry data across a TPM clear.
Public documentation on the rollback feature:
https://source.chromium.org/chromium/chromiumos/platform2/+/main:oobe_config/README.md
BUG=b/233746744
Signed-off-by: Miriam Polzer <mpolzer@google.com>
Change-Id: I59ca0783b41a6f9ecd5b72f07de6fb403baf2820
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66623
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I3def65c016015d8213824e6b8561d8a67b6d5cf0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Since mono_time is now 64-bit, the utility functions interfacing with
mono_time should also be 64-bit so precision isn't lost.
Fixed build errors related to printing the now int64_t result of
stopwatch_duration_[m|u]secs in various places.
BUG=b:237082996
BRANCH=All
TEST=Boot dewatt
Change-Id: I169588f5e14285557f2d03270f58f4c07c0154d5
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66170
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
For TPM2, vb2api_secdata_firmware_create() is already called from
setup_firmware_space() from _factory_initialize_tpm(). Therefore move
the duplicate call from factory_initialize_tpm() to TPM1's
_factory_initialize_tpm().
Change-Id: I892df65c847e1aeeabef8a7578bec743b639a127
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Intel platforms have soft straps stored in the SI_DESC FMAP section
which can alter boot behavior and may open up a security risk if they
can be modified by an attacker. This patch adds the SI_DESC region to
the list of ranges covered by GSC verification (CONFIG_VBOOT_GSCVD).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0f1b297e207d3c6152bf99ec5a5b0983f01b2d0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66346
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
CL:3825558 changes all vb2_digest and vb2_hash functions to take a new
hwcrypto_allowed argument, to potentially let them try to call the
vb2ex_hwcrypto API for hash calculation. This change will open hardware
crypto acceleration up to all hash calculations in coreboot (most
notably CBFS verification). As part of this change, the
vb2_digest_buffer() function has been removed, so replace existing
instances in coreboot with the newer vb2_hash_calculate() API.
Due to the circular dependency of these changes with vboot, this patch
also needs to update the vboot submodule:
Updating from commit id 18cb85b5:
2load_kernel.c: Expose load kernel as vb2_api
to commit id b827ddb9:
tests: Ensure auxfw sync runs after EC sync
This brings in 15 new commits.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I287d8dac3c49ad7ea3e18a015874ce8d610ec67e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
|
|
Firmware is typically delivered as one large binary image that gets
flashed. Since this final image consists of binaries and data from
a vast number of different people and companies, it's hard to
determine what all the small parts included in it are. The goal of
the software bill of materials (SBOM) is to take a firmware image
and make it easy to find out what it consists of and where those
pieces came from. Basically, this answers the question, who supplied
the code that's running on my system right now? For example, buyers
of a system can use an SBOM to perform an automated vulnerability
check or license analysis, both of which can be used to evaluate
risk in a product. Furthermore, one can quickly check to see if the
firmware is subject to a new vulnerability included in one of the
software parts (with the specified version) of the firmware.
Further reference:
https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/
- Add Makefile.inc to generate and build coswid tags
- Add templates for most payloads, coreboot, intel-microcode,
amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM,
intel ME and compiler (gcc,clang,other)
- Add Kconfig entries to optionally supply a path to CoSWID tags
instead of using the default CoSWID tags
- Add CBFS entry called SBOM to each build via Makefile.inc
- Add goswid utility tool to generate SBOM data
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Icb7481d4903f95d200eddbfed7728fbec51819d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
futility now supports image truncation and signing of whole images with
a single command invocation. Use it for vboot-enabled coreboot images.
TEST=Build and run coreboot on google/volteer
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I49eb7e977b635ccb9f6c1b76e53c36e82be1d795
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Branding changes to unify and update Chrome OS to ChromeOS (removing the
space).
This CL also includes changing Chromium OS to ChromiumOS as well.
BUG=None
TEST=N/A
Change-Id: I39af9f1069b62747dbfeebdd62d85fabfa655dcd
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65479
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Boards using VBOOT_VBNV_EC (nyan, daisy, veyron, peach_pit) are all
ChromeOS devices and they've reached the end of life since Feb 2022.
Therefore, remove VBOOT_VBNV_EC for them, each with different
replacement.
- nyan (nyan, nyan_big, nyan_blaze): Add RW_NVRAM to their FMAP (by
reducing the size of RW_VPD), and replace VBOOT_VBNV_EC with
VBOOT_VBNV_FLASH.
- veyron: Add RW_NVRAM to their FMAP (by reducing the size of
SHARED_DATA), and replace VBOOT_VBNV_EC with VBOOT_VBNV_FLASH. Also
enlarge the OVERLAP_VERSTAGE_ROMSTAGE section for rk3288 (by reducing
the size of PRERAM_CBMEM_CONSOLE), so that verstage won't exceed its
allotted size.
- daisy: Because BOOT_DEVICE_SPI_FLASH is not set, which is required for
VBOOT_VBNV_FLASH, disable MAINBOARD_HAS_CHROMEOS and VBOOT configs.
- peach_pit: As VBOOT is not set, simply remove the unused VBOOT_VBNV_EC
option.
Remove the VBOOT_VBNV_EC Kconfig option as well as related code, leaving
VBOOT_VBNV_FLASH and VBOOT_VBNV_CMOS as the only two backend options for
vboot nvdata (VBNV).
Also add a check in read_vbnv() and save_vbnv() for VBNV options.
BUG=b:178689388
TEST=util/abuild/abuild -t GOOGLE_NYAN -x -a
TEST=util/abuild/abuild -t GOOGLE_VEYRON_JAQ -x -a
TEST=util/abuild/abuild -t GOOGLE_DAISY -a
TEST=util/abuild/abuild -t GOOGLE_PEACH_PIT -a
BRANCH=none
Change-Id: Ic67d69e694cff3176dbee12d4c6311bc85295863
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This patch adds a new CONFIG_VBOOT_GSCVD option that will be enabled by
default for TPM_GOOGLE_TI50 devices. It makes the build system run the
`futility gscvd` command to create a GSCVD (GSC verification data) which
signs the CBFS trust anchor (bootblock and GBB). In order for this to
work, boards will need to have an RO_GSCVD section in their FMAP, and
production boards should override the CONFIG_VBOOT_GSC_BOARD_ID option
with the correct ID for each variant.
BUG=b:229015103
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1cf86e90b2687e81edadcefa5a8826b02fbc8b24
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64707
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
There are efforts to have bootflows that do not follow a traditional
bootblock-romstage-postcar-ramstage model. As part of that CBMEM
initialisation hooks will need to move from romstage to bootblock.
The interface towards platforms and drivers will change to use one of
CBMEM_CREATION_HOOK() or CBMEM_READY_HOOK(). Former will only be called
in the first stage with CBMEM available.
Change-Id: Ie24bf4e818ca69f539196c3a814f3c52d4103d7e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
The makefiles don't like cbfs file names with spaces in them so update
the file name with '_' instead of spaces. To keep the master header at
the top of cbfs, add a placeholder.
This removes the need to handle the cbfs master header in cbfstool.
This functionality will be dropped in a later CL.
On x86 reserve some space in the linker script to add the pointer.
On non-x86 generate a pointer inside a C struct file.
As a bonus this would actually fix the master header pointer mechanism
on Intel/APL as only the bootblock inside IFWI gets memory mapped.
TESTED on thinkpad X201: SeaBIOS correctly finds the cbfs master
header.
Change-Id: I3ba01be7da1f09a8cac287751497c18cda97d293
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Break TPM related Kconfig into the following dimensions:
TPM transport support:
config CRB_TPM
config I2C_TPM
config SPI_TPM
config MEMORY_MAPPED_TPM (new)
TPM brand, not defining any of these is valid, and result in "generic" support:
config TPM_ATMEL (new)
config TPM_GOOGLE (new)
config TPM_GOOGLE_CR50 (new, implies TPM_GOOGLE)
config TPM_GOOGLE_TI50 (new to be used later, implies TPM_GOOGLE)
What protocol the TPM chip supports:
config MAINBOARD_HAS_TPM1
config MAINBOARD_HAS_TPM2
What the user chooses to compile (restricted by the above):
config NO_TPM
config TPM1
config TPM2
The following Kconfigs will be replaced as indicated:
config TPM_CR50 -> TPM_GOOGLE
config MAINBOARD_HAS_CRB_TPM -> CRB_TPM
config MAINBOARD_HAS_I2C_TPM_ATMEL -> I2C_TPM && TPM_ATMEL
config MAINBOARD_HAS_I2C_TPM_CR50 -> I2C_TPM && TPM_GOOGLE
config MAINBOARD_HAS_I2C_TPM_GENERIC -> I2C_TPM && !TPM_GOOGLE && !TPM_ATMEL
config MAINBOARD_HAS_LPC_TPM -> MEMORY_MAPPED_TPM
config MAINBOARD_HAS_SPI_TPM -> SPI_TPM && !TPM_GOOGLE && !TPM_ATMEL
config MAINBOARD_HAS_SPI_TPM_CR50 -> SPI_TPM && TPM_GOOGLE
Signed-off-by: Jes B. Klinke <jbk@chromium.org>
Change-Id: I4656b2b90363b8dfd008dc281ad591862fe2cc9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
cb_err_t was meant to be used in place of `enum cb_err` in all
situations, but the choice to use a typedef here seems to be
controversial. We should not be arbitrarily using two different
identifiers for the same thing across the codebase, so since there are
no use cases for serializing enum cb_err at the moment (which would be
the primary reason to typedef a fixed-width integer instead), remove
cb_err_t again for now.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iaec36210d129db26d51f0a105d3de070c03b686b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62600
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
This patch aims to make timestamps more consistent in naming,
to follow one pattern. Until now there were many naming patterns:
- TS_START_*/TS_END_*
- TS_BEFORE_*/TS_AFTER_*
- TS_*_START/TS_*_END
This change also aims to indicate, that these timestamps can be used
to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
This function actually dumps cbmem to the UART. This change renames the
function to make that clear.
BUG=b:213828947
TEST=Build guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Icc314c530125e5303a06b92aab48c1e1122fd18c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This reverts commit 7dce19080889955576f8fd197658077aced96a96.
Reason for revert: Unable to boot in factory mode
Change-Id: I1b51010080164c6e28d77a932f77c10006fd4153
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
This patch removes all remaining pieces of the old CBFS API, now that
the last straggling use cases of it have been ported to the new one
(meaning cbfs_map()/cbfs_load()/etc... see CB:39304 and CB:38421).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1cec0ca2d9d311626a087318d1d78163243bfc3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
High Definition (HD) protected content playback requires secure counters
that are updated at regular interval while the protected content is
playing. To support similar use-cases, define space for secure counters
in TPM NVRAM and initialize them. These counters are defined once during
the factory initialization stage. Also add
VBOOT_DEFINE_WIDEVINE_COUNTERS config item to enable these secure
counters only on the mainboard where they are required/used.
BUG=b:205261728
TEST=Build and boot to OS in guybrush. Ensure that the secure counters
are defined successfully in TPM NVRAM space.
tlcl_define_space: response is 0
tlcl_define_space: response is 0
tlcl_define_space: response is 0
tlcl_define_space: response is 0
On reboot if forced to redefine the space, it is identified as already
defined.
tlcl_define_space: response is 14c
define_space():219: define_space: Secure Counter space already exists
tlcl_define_space: response is 14c
define_space():219: define_space: Secure Counter space already exists
tlcl_define_space: response is 14c
define_space():219: define_space: Secure Counter space already exists
tlcl_define_space: response is 14c
define_space():219: define_space: Secure Counter space already exists
Change-Id: I915fbdada60e242d911b748ad5dc28028de9b657
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59476
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Create an NVRAM counter in TPM 2.0 that survives owner clear and can be
read and written without authorization. This counter allows to seal data
with the TPM that can only be unsealed before the counter was
incremented. It will be used during Chrome OS rollback to securely carry
data across a TPM clear.
Signed-off-by: Miriam Polzer <mpolzer@google.com>
Change-Id: I511dba3b3461713ce20fb2bda9fced0fee6517e1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
When fetching antirollback information for the kernel, it is not always
known ahead of time what the current size of the kernel secdata area
is. If the incorrect size is passed, the TPM will return back the
correct size, but at the cost of an extra transaction; when using cr50
over I2C, this can be as much as 20ms. Currently, the first attempt uses
the minimium size (aka version 0 or 0.2), and if another size is used
(which is the case for all modern cr50-based boards, version 1 or 1.0),
then a transaction is wasted on every boot.
Therefore, change the default size sent to the TPM to be the default one
used in the VB2 API instead of the minimum one.
BUG=b:201304784
TEST=verify TPM initialization time drops by ~20ms. Also the Kernel NV
Index is read correctly in the BIOS logs.
src/security/tpm/tss/tcg-2.0/tss.c:231 index 0x1007 return code 0
src/security/tpm/tss/tcg-2.0/tss.c:231 index 0x1008 return code 0
504:finished TPM initialization 99,953 (65,606)
Change-Id: I22d9c0079bb1175f24ff7317d116e79aa5ba08ed
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
This reverts commit adb393bdd6cd6734fa2672bd174aca4588a68016.
This relands commit 6260bf712a836762b18d80082505e981e040f4bc.
Reason for revert:
The original CL did not handle some devices correctly.
With the fixes:
* commit 36721a4 (mb/google/brya: Add GPIO_IN_RW to all variants'
early GPIO tables)
* commit 3bfe46c (mb/google/guybrush: Add GPIO EC in RW to early
GPIO tables)
* commit 3a30cf9 (mb/google/guybrush: Build chromeos.c in verstage
This CL also fix the following platforms:
* Change to always trusted: cyan.
* Add to early GPIO table: dedede, eve, fizz, glados, hatch, octopus,
poppy, reef, volteer.
* Add to both Makefile and early GPIO table: zork.
For mb/intel:
* adlrvp: Add support for get_ec_is_trusted().
* glkrvp: Add support for get_ec_is_trusted() with always trusted.
* kblrvp: Add support for get_ec_is_trusted() with always trusted.
* kunimitsu: Add support for get_ec_is_trusted() and initialize it as
early GPIO.
* shadowmountain: Add support for get_ec_is_trusted() and initialize
it as early GPIO.
* tglrvp: Add support for get_ec_is_trusted() with always trusted.
For qemu-q35: Add support for get_ec_is_trusted() with always trusted.
We could attempt another land.
Change-Id: I66b8b99d6e6bf259b18573f9f6010f9254357bf9
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58253
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
This reverts commit 6260bf712a836762b18d80082505e981e040f4bc.
Reason for revert: This CL did not handle Intel GPIO correctly. We need
to add GPIO_EC_IN_RW into early_gpio_table for platforms using Intel
SoC.
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: Iaeb1bf598047160f01e33ad0d9d004cad59e3f75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57951
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that the vb2ex_hwcrypto_* stub functions are included in vboot fwlib
(CL:2353775), we can remove the same stubs from coreboot.
BUG=none
TEST=emerge-brya coreboot
TEST=emerge-cherry coreboot
BRANCH=none
Change-Id: I62bdc647eb3e34c581cc1b8d15e7f271211e6156
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58095
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
vboot_reference is introducing a new field (ctx) to store the current
boot mode in crrev/c/2944250 (ctx->bootmode), which will be leveraged
in both vboot flow and elog_add_boot_reason in coreboot.
In current steps of deciding bootmode, a function vb2ex_ec_trusted
is required. This function checks gpio EC_IN_RW pin and will return
'trusted' only if EC is not in RW. Therefore, we need to implement
similar utilities in coreboot.
We will deprecate vb2ex_ec_trusted and use the flag,
VB2_CONTEXT_EC_TRUSTED, in vboot, vb2api_fw_phase1 and set that flag
in coreboot, verstage_main.
Also add a help function get_ec_is_trusted which needed to be
implemented per mainboard.
BUG=b:177196147, b:181931817
BRANCH=none
TEST=Test on trogdor if manual recovery works
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: I479c8f80e45cc524ba87db4293d19b29bdfa2192
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57048
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Currently, check_boot_mode is called after vb2api_fw_phase1, which
makes verstage_main exit before reaching check_boot_mode if recovery
mode is manually requested. Thus, recovery mode isn't able to test
whether VB2_CONTEXT_EC_TRUSTED is set or not.
This patch makes verstage_main call check_boot_mode before
vb2api_fw_phase1 to fix the issue.
BUG=b:180927027, b:187871195
BRANCH=none
TEST=build
Change-Id: If8524d1513b13fd79320a116a83f6729a820f61f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57623
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
It can be nice to update the TPM firmware without having to clear the
TPM owner. However, in order to do so would require platformHierarchy
to be enabled which would leave the kernel antirollback space a bit
vulnerable. To protect the kernel antirollback space from being written
to by the OS, we can use the WriteLock command. In order to do so we
need to add the WRITE_STCLEAR TPM attribute.
This commit adds the WRITE_STCLEAR TPM attribute to the rw antirollback
spaces. This includes the kernel antirollback space along with the MRC
space. When an STCLEAR attribute is set, this indicates that the TPM
object will need to be reloaded after any TPM Startup (CLEAR).
BUG=b:186029006
BRANCH=None
TEST=Build and flash a chromebook with no kernel antirollback space set
up, boot to Chrome OS, run `tpm_manager_client get_space_info
--index=0x1007` and verify that the WRITE_STCLEAR attribute is present.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I3181b4c18acd908e924ad858b677e891312423fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56358
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add Kconfig option for VBOOT_X86_SHA256_ACCELERATION, which will
use x86-sha extension for SHA256 instead of software implementation.
TEST=Able to call vb2ex_hwcrypto_digest_init() and perform SHA
using HW crypto engine.
Change-Id: Idc8be8711c69f4ebc489cd37cc3749c0b257c610
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
We are not currently tracking how long it takes to load verstage. The
enum values already exist, they just weren't used.
BUG=b:179092979
TEST=Dump timestamps
501:starting to load verstage 2,280,656 (1)
502:finished loading verstage 2,340,845 (60,189)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I2cde58cb8aa796829a4e054e6925e2394973484b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This commit adds support for the Chrome OS Zero-Touch Enrollment related
spaces. For TPM 2.0 devices which don't use Cr50, coreboot will define
the RMA+SN Bits, Board ID, and RMA Bytes counter spaces.
The RMA+SN Bits space is 16 bytes initialized to all 0xFFs.
The Board ID space is 12 bytes initialized to all 0xFFs.
The RMA Bytes counter space is 8 bytes intialized to 0.
BUG=b:184676425
BRANCH=None
TEST=Build and flash lalala, verify that the ZTE spaces are created
successfully by undefining the firmware antirollback space in the TPM
such that the TPM undergoes factory initialization in coreboot. Reboot
the DUT. Boot to CrOS and run `tpm_manager_client list_spaces` and
verify that the ZTE spaces are listed. Run `tpm_manager_client
read_space` with the various indices and verify that the sizes and
initial values of the spaces are correct.
TEST=Attempt to undefine the ZTE spaces and verify that it fails due to
the unsatisfiable policy.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I97e3ae7e18fc9ee9a02afadbbafeb226b41af0eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55242
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch assings 2 to EC_EFS_BOOT_MODE_TRUSTED_RO to make coreboot
set VB2_CONTEXT_EC_TRUSTED when the GSC reports TRUSTED_RO.
Old GSC doesn't use 2. So, the new BIOS won't mistakenly set
VB2_CONTEXT_EC_TRUSTED.
BUG=b:180927027, b:187871195
BRANCH=none
TEST=build
Change-Id: I11a09d0035a4bd59f80018c647ca17e3318be81e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55373
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch makes coreboot set VB2_CONTEXT_EC_TRUSTED based on the EC"s
boot mode. Vboot will check VB2_CONTEXT_EC_TRUSTED to determine
whether it can enter recovery mode or not.
BUG=b:180927027, b:187871195
BRANCH=none
TEST=build
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I9fa09dd7ae5baa1efb4e1ed4f0fe9a6803167c93
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Change-Id: I54b296563940cd46fe9da9fe789b746f2fc1987d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
Defined as TPM1 || TPM2.
Change-Id: I18c26d6991c2ccf782a515a8e90a3eb82b53b0e6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The new kernel secdata v1 stores the last read EC hash, and reboots the
device during EC software sync when that hash didn't match the currently
active hash on the EC (this is used with TPM_CR50 to support EC-EFS2 and
pretty much a no-op for other devices). Generally, of course the whole
point of secdata is always that it persists across reboots, but with
MOCK_SECDATA we can't do that. Previously we always happened to somewhat
get away with presenting freshly-reinitialized data for MOCK_SECDATA on
every boot, but with the EC hash feature in secdata v1, that would cause
a reboot loop. The simplest solution is to just pretend we're a secdata
v0 device when using MOCK_SECDATA.
This was encountered on using a firmware built with MOCK_SECDATA but had
EC software sync enabled.
BUG=b:187843114
BRANCH=None
TEST=`USE=mocktpm cros build-ap -b keeby`; Flash keeby device, verify
that DUT does not continuously reboot with EC software sync enabled.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: Id8e81afcddadf27d9eec274f7f85ff1520315aaa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This commit has coreboot create the Chrome OS Firmware Management
Parameters (FWMP) space in the TPM. The space will be defined and the
contents initialized to the defaults.
BUG=b:184677625
BRANCH=None
TEST=emerge-keeby coreboot
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I1f566e00f11046ff9a9891c65660af50fbb83675
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
|
The name `set_space()` seems to imply that it's writing to a TPM space
when actually, the function can create a space and write to it. This
commit attempts to make that a bit more clear. Additionally, in order
to use the correct sizes when creating the space, this commit also
refactors the functions slightly to incorporate the vboot context object
such that the correct sizes are used. The various vboot APIs will
return the size of the created object that we can then create the space
with.
BUG=b:184677625
BRANCH=None
TEST=`emerge-keeby coreboot`
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I80a8342c51d7bfaa0cb2eb3fd37240425d5901be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54308
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The CBFS mcache size default was eyeballed to what should be "hopefully
enough" for most users, but some recent Chrome OS devices have already
hit the limit. Since most current (and probably all future) x86 chipsets
likely have the CAR space to spare, let's just double the size default
for all supporting chipsets right now so that we hopefully won't run
into these issues again any time soon.
The CBFS_MCACHE_RW_PERCENTAGE default for CHROMEOS was set to 25 under
the assumption that Chrome OS images have historically always had a lot
more files in their RO CBFS than the RW (because l10n assets were only
in RO). Unfortunately, this has recently changed with the introduction
of updateable assets. While hopefully not that many boards will need
these, the whole idea is that you won't know whether you need them yet
at the time the RO image is frozen, and mcache layout parameters cannot
be changed in an RW update. So better to use the normal 50/50 split on
Chrome OS devices going forward so we are prepared for the eventuality
of needing RW assets again.
The RW percentage should really also be menuconfig-controllable, because
this is something the user may want to change on the fly depending on
their payload requirements. Move the option to the vboot Kconfigs
because it also kinda belongs there anyway and this makes it fit in
better in menuconfig. (I haven't made the mcache size
menuconfig-controllable because if anyone needs to increase this, they
can just override the default in the chipset Kconfig for everyone using
that chipset, under the assumption that all boards of that chipset have
the same amount of available CAR space and there's no reason not to use
up the available space. This seems more in line with how this would work
on non-x86 platforms that define this directly in their memlayout.ld.)
Also add explicit warnings to both options that they mustn't be changed
in an RW update to an older RO image.
BUG=b:187561710
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I046ae18c9db9a5d682384edde303c07e0be9d790
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54146
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
fspt.bin is run before verstage so it is of no use in RW_A/B.
Change-Id: I6fe29793fa638312c8b275b6fa8662df78b3b2bd
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch changes the vboot EC sync code to use the new CBFS API. As a
consequence, we have to map the whole EC image file at once (because the
new API doesn't support partial mapping). This should be fine on the
only platform that uses this code (Google_Volteer/_Dedede family)
because they are x86 devices that support direct mapping from flash, but
the code was originally written to more carefully map the file in
smaller steps to be theoretically able to support Arm devices.
EC sync in romstage for devices without memory-mapped flash would be
hard to combine with CBFS verification because there's not enough SRAM
to ever hold the whole file in memory at once, but we can't validate the
file hash until we have loaded the whole file and for performance (or
TOCTOU-safety, if applicable) reasons we wouldn't want to load anything
more than once. The "good" solution for this would be to introduce a
CBFS streaming API can slowly feed chunks of the file into a callback
but in the end still return a "hash valid/invalid" result to the caller.
If use cases like this become pressing in the future, we may have to
implement such an API.
However, for now this code is the only part of coreboot with constraints
like that, it was only ever used on platforms that do support
memory-mapped flash, and due to the new EC-EFS2 model used on more
recent Chrome OS devices we don't currently anticipate this to ever be
needed again. Therefore this patch goes the easier way of just papering
over the problem and punting the work of implementing a more generic
solution until we actually have a real need for it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7e263272aef3463f3b2924887d96de9b2607f5e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52280
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
RETURN_FROM_VERSTAGE is a somewhat tricky construct that we don't
normally do otherwise in coreboot. While it works remarkably well in
general, new development can lead to unintentional interactions with
confusing results. This patch adds a debug print to the verstage right
before returning to the bootblock so that it's obvious this happens,
because otherwise in some cases the last printout in the verstage is
about some TPM commands which can be misleading when execution hangs
after that point.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9ca68a32d7a50c95d9a6948d35816fee583611bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52086
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The PCR algorithms used for vboot are frequently causing confusion (e.g.
see CB:35645) because depending on the circumstances sometimes a
(zero-extended) SHA1 value is interpreted as a SHA256, and sometimes a
SHA256 is interpreted as a SHA1. We can't really "fix" anything here
because the resulting digests are hardcoded in many generations of
Chromebooks, but we can document and isolate it better to reduce
confusion. This patch adds an explanatory comment and fixes both
algorithms and size passed into the lower-level TPM APIs to their actual
values (whereas it previously still relied on the TPM 1.2 TSS not
checking the algorithm type, and the TPM 2.0 TSS only using the size
value for the TCPA log and not the actual TPM operation).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib0b6ecb8c7e9a405ae966f1049158f1d3820f7e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
