LockConfig only exists on Intel TXT for Servers. Check whether this is
supported using GETSEC[PARAMETERS]. This eliminates a spurious error for
Client TXT platforms such as Haswell, and is a no-op on TXT for Servers.
Change-Id: Ibb7b0eeba1489dc522d06ab27eafcaa0248b7083
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When Boot Guard is disabled or not available, the IBB might not even
exist. This is the case on traditional (non-ULT) Haswell, for example.
Leave the S3 resume check as-is for now. Skylake and newer may need to
run SCHECK on resume as well, but I lack the hardware to test this on.
Change-Id: I70231f60d4d4c5bc8ee0fcbb0651896256fdd391
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This is merely used to test whether the BIOS ACM calling code is working
properly. There's no need to do this on production platforms. Testing on
Haswell showed that running this NOP function breaks S3 resume with TXT.
Add a Kconfig bool to control whether the NOP function is to be invoked.
Change-Id: Ibf461c18a96f1add7867e1320726fadec65b7184
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
It causes problems on Haswell: SINIT detects that the heap tables differ
in size, and then issues a Class Code 9, Major Error Code 1 TXT reset.
Change-Id: I26f3d291abc7b2263e0b115e94426ac6ec8e5c48
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Heap initialization is self-contained, so place it into a separate
function. Also, do it after the MSEG registers have been written, so
that all register writes are grouped together. This has no impact.
Change-Id: Id108f4cfcd2896d881d9ba267888f7ed5dd984fa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This is not critical to function, but is nice to have.
Change-Id: Ieb5f41f3e4c5644a31606434916c35542d35617a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46493
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The TXT_BIOSACM_ERRORCODE register is only valid if TXT_SPAD bit 62 is
set, or if CBnT is supported and bit 61 is set. Moreover, this is only
applicable to LT-SX (i.e. platforms supporting Intel TXT for Servers).
This allows TXT to work on client platforms, where these registers are
regular scratchpads and are not necessarily written to by the BIOS ACM.
Change-Id: If047ad79f12de5e0f34227198ee742b9e2b5eb54
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46492
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of hardcoding the size in code, expose it as a Kconfig symbol.
This allows platform code to program the size in the MCH DPR register.
Change-Id: I9b9bcfc7ceefea6882f8133a6c3755da2e64a80c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since MRC_SAVE_HASH_IN_TPM depends on TPM2, we can now remove the tpm
1.2 versions of functions that deal with mrc hash in the tpm as it
will not be used by tpm 1.2 boards. Also move all antirollback
functions that deal with mrc hash in the tpm under CONFIG(TPM2).
BUG=b:150502246
BRANCH=None
TEST=make sure boards are still compiling on coreboot Jenkins
Change-Id: I446dde36ce2233fc40687892da1fb515ce35b82b
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Pull selection of tpm hash index logic into cache_region struct. This
CL also enables the storing of the MRC hash into the TPM NVRAM space
for both recovery and non-recovery cases. This will affect all
platforms with TPM2 enabled and use the MRC_CACHE driver.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami and lazor
Change-Id: I1a744d6f40f062ca3aab6157b3747e6c1f6977f9
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46514
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add new index for MRC_CACHE data in RW. Also update antirollback
functions to handle this new index where necessary.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I2de3c23aa56d3b576ca54dbd85c75e5b80199560
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46511
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
We need to extend the functionality of the mrc_cache hash functions to
work for both recovery and normal mrc_cache data. Updating the API of
these functions to pass in an index to identify the hash indices for
recovery and normal mode.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I9c0bb25eafc731ca9c7a95113ab940f55997fc0f
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This CL would remove these calls from fsp 2.0. Platforms that select
MRC_STASH_TO_CBMEM, updating the TPM NVRAM space is moved from
romstage (when data stashed to CBMEM) to ramstage (when data is
written back to SPI flash.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I3088ca6927c7dbc65386c13e868afa0462086937
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use this config to specify whether we want to save a hash of the
MRC_CACHE in the TPM NVRAM space. Replace all uses of
FSP2_0_USES_TPM_MRC_HASH with MRC_SAVE_HASH_IN_TPM and remove the
FSP2_0_USES_TPM_MRC_HASH config. Note that TPM1 platforms will not
select MRC_SAVE_HASH_IN_TPM as none of them use FSP2.0 and have
recovery MRC_CACHE.
BUG=b:150502246
BRANCH=None
TEST=emerge-nami coreboot chromeos-bootimage
Change-Id: Ic5ffcdba27cb1f09c39c3835029c8d9cc3453af1
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
As ongoing work for generalizing mrc_cache to be used by all
platforms, we are pulling it out from fsp 2.0 and renaming it as
mrc_cache_hash_tpm.h in security/vboot.
BUG=b:150502246
BRANCH=None
TEST=emerge-nami coreboot chromeos-bootimage
Change-Id: I5a204bc3342a3462f177c3ed6b8443e31816091c
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Due to platform-specific constraints, it is not possible to enable DPR
by programming the MCH's DPR register in ramstage. Instead, assume it
has been programmed earlier and check that its value is valid. If it is,
then simply configure DPR in TXT public base with the same parameters.
Note that some bits only exist on MCH DPR, and thus need to be cleared.
Implement this function on most client platforms. For Skylake and newer,
place it in common System Agent code. Also implement it for Haswell, for
which the rest of Intel TXT support will be added in subsequent commits.
Do not error out if DPR is larger than expected. On some platforms, such
as Haswell, MRC decides the size of DPR, and cannot be changed easily.
Reimplementing MRC is easier than working around its limitations anyway.
Change-Id: I391383fb03bd6636063964ff249c75028e0644cf
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46490
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The BIOS ACM will check that enabled variable MTRRs do not cover more
than the ACM's size, rounded up to 4 KiB. If that is not the case,
launching the ACM will result in a lovely TXT reset. How boring.
The new algorithm simply performs a reverse bit scan in a loop, and
allocates one MTRR for each set bit in the rounded-up size to cache.
Before allocating anything, it checks if there are enough variable
MTRRs; if not, it will refuse to cache anything. This will result in
another TXT reset, initiated by the processor, with error type 5:
Load memory type error in Authenticated Code Execution Area.
This can only happen if the ACM has specific caching requirements that
the current code does not know about, or something has been compromised.
Therefore, causing a TXT reset should be a reasonable enough approach.
Also, disable all MTRRs before clearing the variable MTRRs and only
enable them again once they have been set up with the new values.
Tested on Asrock B85M Pro4 with a BIOS ACM whose size is 101504 bytes.
Without this patch, launching the ACM would result in a TXT reset. This
no longer happens when this patch is applied.
Change-Id: I8d411f6450928357544be20250262c2005d1e75d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44880
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When caching the BIOS ACM, one must cache less than a page (4 KiB) of
unused memory past the end of the BIOS ACM. Failure to do so on Haswell
will result in a lovely TXT reset with Class Code 5, Major Error Code 2.
The current approach uses a single variable MTRR to cache the whole BIOS
ACM. Before fighting with the variable MTRRs in assembly code, ensure
that enough variable MTRRs exist to cache the BIOS ACM's size. Since the
code checks that the ACM base is aligned to its size, each `one` bit in
the ACM size will require one variable MTRR to properly cache the ACM.
One of the several BIOS ACMs for Haswell has a size of 101504 bytes.
This is 0x18c80 in hexadecimal, and 0001 1000 1100 1000 0000 in binary.
After aligning up the BIOS ACM size to a page boundary, the resulting
size is 0x19000 in hexadecimal, and 0001 1001 0000 0000 0000 in binary.
To successfully invoke said ACM, its base must be a multiple of 0x20000
and three variable MTRRs must be used to cache the ACM. The MTRR ranges
must be contiguous and cover 0x10000, 0x8000, 0x1000 bytes, in order.
The assembly code is updated in a follow-up, and relies on these checks.
Change-Id: I480dc3e4a9e4a59fbb73d571fd62b0257abc65b3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46422
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This needs to be saved and restored, otherwise the BSP might have an
inconsistent MTRR setup with regards to the AP's which results in
weird errors and slowdowns in the operating system.
TESTED: Fixes booting OCP/Deltalake with Linux 5.8.
Change-Id: Iace636ec6fca3b4d7b2856f0f054947c5b3bc8de
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46375
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This function is available for all TXT-capable platforms. Use it.
As it also provides the size of TSEG, display it when logging is on.
Change-Id: I4b3dcbc61854fbdd42275bf9456eaa5ce783e8aa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This simplifies operations with this register's bitfields, and can also
be used by TXT-enabled platforms on the register in PCI config space.
Change-Id: I10a26bc8f4457158dd09e91d666fb29ad16a2087
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46050
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds options that support building the STM as a
part of the coreboot build. The option defaults assume that
these configuration options are set as follows:
IED_REGION_SIZE = 0x400000
SMM_RESERVED_SIZE = 0x200000
SMM_TSEG_SIZE = 0x800000
Change-Id: I80ed7cbcb93468c5ff93d089d77742ce7b671a37
Signed-off-by: Eugene Myers <cedarhouse@comcast.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44686
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
Print chipset as hex value in order to make it more readable.
Change-Id: Ifafbe0a1161e9fe6e790692002375f45d813b723
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This sort-of reverts commit 075df92298 and
fixes the underlying issue. The printf format string type/length
specifier for a size_t type is z.
Change-Id: I897380060f7ea09700f77beb81d52c18a45326ad
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45872
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Size_t seems to have a compiler dependency. When building on the
Purism librem 15v4, size_t is 'unsigned long'. In this instance,
the compiler is the coreboot configured cross-compiler. In another
instance, size_t is defined as 'unsigned short'. To get around
the formatting conflict caused by this, The variable of type
size_t was cast as 'unsigned int' in the format.
Change-Id: Id51730c883d8fb9e87183121deb49f5fdda0114e
Signed-off-by: Eugene D Myers <cedarhouse@comcast.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
This adds the const qualifier to inputs of marshalling functions as
they are intended to be read-only.
Change-Id: I099bf46c928733aff2c1d1c134deec35da6309ba
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This allows calling GETSEC[CAPABILITIES] during early init, when the MSR
isn't locked yet.
Change-Id: I2253b5f2c8401c9aed8e32671eef1727363d00cc
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
For Volteer (and future Tiger Lake boards) we can enable mode S0i3.4
only if we know that the Cr50 is generating 100us interrupt pulses.
We have to do so, because the SoC is not guaranteed to detect pulses
shorter than 100us in S0i3.4 substate.
A new Kconfig setting CR50_USE_LONG_INTERRUPT_PULSES controls new code
running in verstage, which will program a new Cr50 register, provided that
Cr50 firmware is new enough to support the register.
BUG=b:154333137
TEST=util/abuild/abuild -t GOOGLE_VOLTEER -c max -x
Signed-off-by: Jes Bodi Klinke <jbk@chromium.org>
Change-Id: If83188fd09fe69c2cda4ce1a8bf5b2efe1ca86da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch updates regions-for-file function in the
security/vboot/Makefile.inc to support adding a CBFS file into
required FMAP REGIONs in a flexible manner. The file that needs to be
added to specific REGIONs, those regions list should be specified in the
regions-for-file-{CBFS_FILE_TO_BE_ADDED} variable.
For example, if a file foo.bin needs to be added in FW_MAIN_B and COREBOOT,
then below code needs to be added in a Makefile.inc.
regions-for-file-foo := FW_MAIN_B,COREBOOT
cbfs-file-y := foo
foo-file := foo.bin
foo-type := raw
TEST=Verified on hatch
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I1f5c22b3d9558ee3c5daa2781a115964f8d2d83b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The MSR macros were treated as memory addresses and the loops had
off-by-one errors. This resulted in a CPU exception before GETSEC, and
another exception after GETSEC (once the first exception was fixed).
Tested on Asrock B85M Pro4, ACM complains about the missing TPM and
resets the platform. When the `getsec` instruction is commented-out, the
board is able to boot normally, without any exceptions nor corruption.
Change-Id: Ib5d23cf9885401f3ec69b0f14cea7bad77eee19a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Soften the hard dependency on SOC_INTEL_COMMON_BLOCK_SA by allowing CF9
resets to be used in place of global resets. If both types of reset are
available, prefer a global reset. This preserves current behavior, and
allows more platforms to use the TXT support code, such as Haswell.
Change-Id: I034fa0b342135e7101c21646be8fd6b5d3252d9e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Coverity detects an integer handling issue with BAD_SHIFT. The inline
function log2_ceil(u32 x) { return (x == 0) ? -1 : log2(x * 2 - 1); }
could return -1, which causes shifting by a negative amount value and
has undefined behavior. Add sanity check for the acm_header->size to
avoid shifting negative value.
Found-by: Coverity CID 1431124
TEST=None
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ic687349b14917e39d2a8186968037ca2521c7cdc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add TXT ramstage driver:
* Show startup errors
* Check for TXT reset
* Check for Secrets-in-memory
* Add assembly for GETSEC instruction
* Check platform state if GETSEC instruction is supported
* Configure TXT memory regions
* Lock TXT
* Protect TSEG using DMA protected regions
* Place SINIT ACM
* Print information about ACMs
Extend the `security_clear_dram_request()` function:
* Clear all DRAM if secrets are in memory
Add a config so that the code gets build-tested. Since BIOS and SINIT
ACM binaries are not available, use the STM binary as a placeholder.
Tested on OCP Wedge100s and Facebook Watson
* Able to enter a Measured Launch Environment using SINIT ACM and TBOOT
* Secrets in Memory bit is set on ungraceful shutdown
* Memory is cleared after ungraceful shutdown
Change-Id: Iaf4be7f016cc12d3971e1e1fe171e6665e44c284
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
The Kconfig lint tool checks for cases of the code using BOOL type
Kconfig options directly instead of with CONFIG() and will print out
warnings about it. It gets confused by these references in comments
and strings. To fix it so that it can find the real issues, just
update these as we would with real issues.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5c37f0ee103721c97483d07a368c0b813e3f25c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Jenkins does not build `config.stm` because the file name lacks the
mainboard name. So, the code was not being build-tested, and it does not
build because several files lacked the definition for `bool`.
Add the missing #include directives. Renaming the config file so that
Jenkins build-tests it is done in a follow-up.
Change-Id: Idf012b7ace0648027ef6e901d821ca6682cee198
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43622
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the AP actually needs to write to the TPM, then it is important and
the TPM should commit those changes to NVMEM immediately in case there
is an unexpected power loss (e.g. from a USB-C port partner reset upon
cold reboot request).
BRANCH=none
BUG=b:160913048
TEST=Verify that puff will no longer reboot loop when coreboot writes a
new Hmir (Hash mirror) in the TPM
Change-Id: I9597a55891d11bdf040d70f38b4c5a59c7888b8a
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43414
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This code is not even being build-tested. Drop it before it grows moss.
Change-Id: Ie01d65f80caf32a8318d5109ad48321661c5a87b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43213
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This code is not even being build-tested. Drop it before it grows moss.
Change-Id: Ifda2bbd87cd8ef5ec8e449d2c4d303be37b4d7c7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43212
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The AMD firmware package created by amdfwtool contains pointers to the
various binaries and settings. This means that we need different copies
of the package in each region.
This change allows for the different files in each of the 3 vboot
regions.
BUG=b:158124527
TEST=Build trembyle; see the correct versions of the files getting
built into the RW-A & RW-B regions.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I45ff69dbc2266a67e05597bbe721fbf95cf41777
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
We always have it, no need to support opting-out.
For PLATFORM_HAS_DRAM_CLEAR there is a dependency of ramstage
located inside CBMEM, which is only true with ARCH_X86.
Change-Id: I5cbf4063c69571db92de2d321c14d30c272e8098
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43014
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace uses with MAINBOARD_HAS_LPC_TPM, if drivers/pc80/tpm
is present in devicetree.cb it is necessary to always include
the driver in the build.
Change-Id: I9ab921ab70f7b527a52fbf5f775aa063d9a706ce
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41872
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner
SPI_WRITE_PROTECTION_REBOOT seems to be a Winbond thing, other vendors
such as Macronix only support permanent protection but conditional on
the WP# pin state.
Change-Id: Iba7c1229c82c86e1303d74c7bc8f89662b5bb58c
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41747
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Kconfig 4.17 started using the $(..) syntax for environment variable
expansion while we want to keep expansion to the build system.
Older Kconfig versions (like ours) simply drop the escapes, not
changing the behavior.
While we could let Kconfig expand some of the variables, that only
splits the handling in two places, making debugging harder and
potentially messing with reproducible builds (e.g. when paths end up
in configs), so escape them all.
Change-Id: Ibc4087fdd76089352bd8dd0edb1351ec79ea4faa
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Change the name of these variables to 'allowlist'.
Change-Id: I9d5553988a1c9972b8f1ebaeee20878b23a8aa9b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42316
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Once we support building stages for different architectures,
such CONFIG(ARCH_xx) tests do not evaluate correctly anymore.
Change-Id: I599995b3ed5c4dfd578c87067fe8bfc8c75b9d43
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42183
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For AMD's family 17h, verstage can run as a userspace app in the PSP
before the X86 is released. The flags for this have been made generic
to support any other future systems that might run verstage before
the main processor starts.
Although an attempt has been made to make things somewhat generic,
since this is the first and currently only chip to support verstage
before bootblock, there are a number of options which might ultimately
be needed which have currently been left out for simplicity. Examples
of this are:
- PCI is not currently supported - this is currently just a given
instead of making a separate Kconfig option for it.
- The PSP uses an ARM v7 processor, so that's the only processor that
is getting updated for the verstage-before-bootblock option.
BUG=b:158124527
TEST=Build with following patches
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I4849777cb7ba9f90fe8428b82c21884d1e662b96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41814
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
<types.h> is supposed to provide <commonlib/bsd/cb_err.h>,
<stdbool.h>,<stdint.h> and <stddef.h>. So remove those includes
each time when <types.h> is included.
Change-Id: I886f02255099f3005852a2e6095b21ca86a940ed
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41817
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
After removal of CAR_MIGRATION there are no more reasons
to carry around ENV_STAGE_HAS_BSS_SECTION=n case.
Replace 'MAYBE_STATIC_BSS' with 'static' and remove explicit
zero-initializers.
Change-Id: I14dd9f52da5b06f0116bd97496cf794e5e71bc37
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Also adjust a few comments to follow the style guide.
Change-Id: I22001320f2ce1f0db348e0f7fabc5a65b50ba53e
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41600
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The current implementation uses strcmp() without splitting the list
and therefore returns false even when the string pointed to by
'name' is a part of 'whitelist'. The patch fixes this problem.
Also, update help text of CONFIG_TPM_MEASURED_BOOT_RUNTIME_DATA to
space delimited list to align it with the other lists we use.
Change-Id: Ifd285162ea6e562a5bb18325a1b767ac2e4276f3
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41280
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch improves the response buffer handling for TPM 2.0. Previously
we would allow any command to return no payload, but if there was a
payload we would always try to unmarshal it according to the normal
success response. This was sort of relying on the fact that the TPM
usually returns no additional data after the header for error responses,
but in practice that is not always true. It also means that commands
without a response payload accidentally work by default even though we
did not explicitly add unmarshallig support for them, which seems
undesirable. Adding explicit unmarshalling support for TPM2_SelfTest
which was only supported through this loophole before.
This patch changes the behavior to always accept any amount of payload
data for error responses but not unmarshal any of it. None of our use
cases actually care about payload data for errors, so it seems safer to
not even try to interpret it. For success responses, on the other hand,
we always require support for the command to be explicitly added.
This fixes a problem with the Cr50 GET_BOOT_MODE command where an error
response would only return the subcommand code but no data after that.
Also add support for a second, slightly different NO_SUCH_COMMAND error
code that was added in Cr50 recently.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib85032d85482d5484180be6fd105f2467f393cd2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41100
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Similar to bootblock, provide declaration for
verstage_mainboard_early_init() to support early mainboard
initialization if verstage is run before bootblock.
BUG=b:155824234
TEST=Verified that trembyle still builds
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I106213ecc1c44100f1f74071189518563ac08121
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Make vboot verification code accessible in only verstage.
Vboot verification code in vboot_logic.c is being used
in verstage. Due to support function vboot_save_data(),
so core functionality in vboot_logic.c is made available in romstage.
The patch decouples the support function frm vboot_logic.c to
limit itself to verstage.
BUG=b:155544643
TEST=Verified on hatch
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: Id1ede45c4dffe90afcef210eabaa657cf92a9335
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
This change moves all ACPI table support in coreboot currently living
under arch/x86 into common code to make it architecture
independent. ACPI table generation is not really tied to any
architecture and hence it makes sense to move this to its own
directory.
In order to make it easier to review, this change is being split into
multiple CLs. This is change 3/5 which basically is generated by
running the following command:
$ git grep -iIl "arch/acpi" | xargs sed -i 's/arch\/acpi/acpi\/acpi/g'
BUG=b:155428745
Change-Id: I16b1c45d954d6440fb9db1d3710063a47b582eae
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Suggested by Nico Huber in CB:38765.
This placement makes the address calculation simpler and
makes its location indepedent of the number of CPUs.
As part of the change in the BIOS resource list address
calculation, the `size` variable was factored out of the
conditional in line 361, thus eliminating the else.
Change-Id: I9ee2747474df02b0306530048bdec75e95413b5d
Signed-off-by: Eugene D Myers <cedarhouse@comcast.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40437
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.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>
Introduce boot media protection settings and use the existing
boot_device_wp_region() function to apply settings on all
platforms that supports it yet.
Also remove the Intel southbridge code, which is now obsolete.
Every platform locks the SPIBAR in a different stage.
For align up with the common mrc cache driver and lock after it has been
written to.
Tested on Supermicro X11SSH-TF. The whole address space is write-protected.
Change-Id: Iceb3ecf0bde5cec562bc62d1d5c79da35305d183
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32704
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add support for a STM SPI TPM2 by adding checks for CR50.
Tested using ST33HTPH2E32.
Change-Id: I015497ca078979a44ba2b84e4995493de1f7247b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
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>
tlcl_cr50_get_boot_mode gets the boot mode from Cr50. The boot mode
tells coreboot/depthcharge whether booting the kernel is allowed or
not.
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: Iadae848c4bf315f2131ff6aebcb35938307b5db4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40388
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `USE_BLOBS` config only exists for idealistic reasons. If we would
allow us to use blobs by default, we wouldn't need that option and could
just always do it. It's generally debatable for the project as a whole,
but not per board/subject.
Change-Id: I8591862699aef02e5a4ede32655fc82c44c97555
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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>
CB:35077 pulled TPM measurement code into the bootblock, with the catch
that we'll only cache PCR extensions and not actually write them to the
TPM until it gets initialized in a later stage. The goal of this was to
keep the heavy TPM driver code out of the size-constrained bootblock.
Unfortunately, a small mistake in the tspi_tpm_is_setup() function
prevents the compiler from eliminating references to the TPM driver
code in the bootblock on platforms with CONFIG_VBOOT and
CONFIG_SEPARATE_VERSTAGE. In those cases vboot_logic_executed() is known
at compile-time to be 0, but that still makes the final expression
`return 0 || tpm_is_setup;`. We know that tpm_is_setup can never be set
to 1 in the bootblock, but the compiler doesn't.
This patch rewrites the logic slightly to achieve the same effect in a
way that the compiler can follow (because we only really need to check
tpm_is_setup in the stage that actually runs the vboot code).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Idc25acf1e6c02d929639e83d529cc14af80e0870
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39993
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
mrc.bin, on platforms where it is present, is code executed on CPU, so
it should be considered a part of CRTM.
cbfs_locate_file_in_region() is hooked to measurement here too, since
mrc.bin is loaded with it, and CBFS_TYPE_MRC (the type of mrc.bin) is
measured to TPM_CRTM_PCR rather than TPM_RUNTIME_DATA_PCR.
TODO: I have heard that SMM is too resource-limited to link with vboot
library, so currently tspi_measure_cbfs_hook() is masked in SMM.
Please correct me if I am wrong.
Change-Id: Ib4c3cf47b919864056baf725001ca8a4aaafa110
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38858
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>
The code in coreboot is actually for the Arrandale processors, which
are a MCM (Multi-Chip Module) with two different dies:
- Hillel: 32nm Westmere dual-core CPU
- Ironlake: 45nm northbridge with integrated graphics
This has nothing to do with the older, single-die Nehalem processors.
Therefore, replace the references to Nehalem with the correct names.
Change-Id: I8c10a2618c519d2411211b9b8f66d24f0018f908
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38942
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
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>
The STM is a part of the core VTx and using ENABLE_VMX will make the
STM option available for any configuration that has an Intel
processor that supports VTx.
Signed-off-by: Eugene D. Myers <edmyers@tycho.nsa.gov>
Change-Id: I57ff82754e6c692c8722d41f812e35940346888a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38852
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check to ensure that dual monitor mode is supported on the
current processor. Dual monitor mode is normally supported on
any Intel x86 processor that has VTx support. The STM is
a hypervisor that executes in SMM dual monitor mode. This
check should fail only in the rare case were dual monitor mode
is disabled. If the check fails, then the STM will not
be initialized by coreboot.
Signed-off-by: Eugene D. Myers <edmyers@tycho.nsa.gov>
Change-Id: I518bb2aa1bdec94b5b6d5e991d7575257f3dc6e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
Selecting STM on an arbitrary platform would likely result in a brick,
so let's hide the prompt by default.
Change-Id: I50f2106ac05c3efb7f92fccb1e6edfbf961b68b8
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: <cedarhouse1@comcast.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
This update is a combination of all four of the patches so that the
commit can be done without breaking parts of coreboot. This possible
breakage is because of the cross-dependencies between the original
separate patches would cause failure because of data structure changes.
security/intel/stm
This directory contains the functions that check and move the STM to the
MSEG, create its page tables, and create the BIOS resource list.
The STM page tables is a six page region located in the MSEG and are
pointed to by the CR3 Offset field in the MSEG header. The initial
page tables will identity map all memory between 0-4G. The STM starts
in IA32e mode, which requires page tables to exist at startup.
The BIOS resource list defines the resources that the SMI Handler is
allowed to access. This includes the SMM memory area where the SMI
handler resides and other resources such as I/O devices. The STM uses
the BIOS resource list to restrict the SMI handler's accesses.
The BIOS resource list is currently located in the same area as the
SMI handler. This location is shown in the comment section before
smm_load_module in smm_module_loader.c
Note: The files within security/intel/stm come directly from their
Tianocore counterparts. Unnecessary code has been removed and the
remaining code has been converted to meet coreboot coding requirements.
For more information see:
SMI Transfer Monitor (STM) User Guide, Intel Corp.,
August 2015, Rev 1.0, can be found at firmware.intel.com
include/cpu/x86:
Addtions to include/cpu/x86 for STM support.
cpu/x86:
STM Set up - The STM needs to be loaded into the MSEG during BIOS
initialization and the SMM Monitor Control MSR be set to indicate
that an STM is in the system.
cpu/x86/smm:
SMI module loader modifications needed to set up the
SMM descriptors used by the STM during its initialization
Change-Id: If4adcd92c341162630ce1ec357ffcf8a135785ec
Signed-off-by: Eugene D. Myers <edmyers@tycho.nsa.gov>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: ron minnich <rminnich@gmail.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>
Add ClearControl Function which is needed for a follow-up patch.
Change-Id: Ia19185528fd821e420b0bdb424760c93b79523a4
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.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>
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>
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>
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>
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>
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>
No platform is using this.
Change-Id: I3ea6df4d9ce9043755f319f699adc189d754df1f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Relocatable ramstage, postcar stage and C_ENVIRONMENT_BOOTBLOCK are
now mandatory features, which this platform lacks.
Change-Id: I8b6502b0894f9e2b8b1334871d7b6cde65cba7d4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
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>
Angel Pons