They all operate on that file, so just add it globally.
Change-Id: I953975a4078d0f4a5ec0b6248f0dcedada69afb2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Target added to INTERMEDIATE all operate on coreboot.pre, each modifying
the file in some way. When running them in parallel, coreboot.pre can be
read from and written to in parallel which can corrupt the result.
Add a function to create those rules that also adds existing
INTERMEDIATE targets to enforce an order (as established by evaluation
order of Makefile.inc files).
While at it, also add the addition to the PHONY target so we don't
forget it.
BUG=chromium:1154313, b:174585424
TEST=Built a configuration with SeaBIOS + SeaBIOS config files (ps2
timeout and sercon) and saw that they were executed.
Change-Id: Ia5803806e6c33083dfe5dec8904a65c46436e756
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49358
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This functionality only exists on legacy TXT.
Change-Id: I4206ba65fafbe3d4dda626a8807e415ce6d64633
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
intel_txt_memory_has_secret() checks for ESTS.TXT_ESTS_WAKE_ERROR_STS
|| E2STS.TXT_E2STS_SECRET_STS and it looks like with CBNT the E2STS
bit can be set without the ESTS bit.
Change-Id: Iff4436501b84f5c209add845b3cd3a62782d17e6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47934
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION
feature. It's not useful to end-users in this stage so it cannot be
selected in menuconfig (and should not be used other than for
development) yet. With this patch coreboot can verify the metadata hash
of the RO CBFS when it starts booting, but it does not verify individual
files yet. Likewise, verifying RW CBFSes with vboot is not yet
supported.
Verification is bootstrapped from a "metadata hash anchor" structure
that is embedded in the bootblock code and marked by a unique magic
number. This anchor contains both the CBFS metadata hash and a separate
hash for the FMAP which is required to find the primary CBFS. Both are
verified on first use in the bootblock (and halt the system on failure).
The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes
to show some paths that need to be different when full protection
against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For
normal verification it is sufficient to check the FMAP and the CBFS
metadata hash only once in the bootblock -- for TOCTOU verification we
do the same, but we need to be extra careful that we do not re-read the
FMAP or any CBFS metadata in later stages. This is mostly achieved by
depending on the CBFS metadata cache and FMAP cache features, but we
allow for one edge case in case the RW CBFS metadata cache overflows
(which may happen during an RW update and could otherwise no longer be
fixed because mcache size is defined by RO code). This code is added to
demonstrate design intent but won't really matter until RW CBFS
verification can be supported.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfs_boot_locate() is supposed to be deprecated eventually, after slowly
migrating all APIs to bypass it. That means common features (like
RO-fallback or measurement) need to be moved to the new
cbfs_boot_lookup().
Also export the function externally. Since it is a low-level API and
most code should use the higher-level loading or mapping functions
instead, put it into a new <cbfs_private.h> to raise the mental barrier
for using this API (this will make more sense once cbfs_boot_locate() is
removed from <cbfs.h>).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4bc9b7cbc42a4211d806a3e3389abab7f589a25a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds a new CBFS "mcache" (metadata cache) -- a memory buffer
that stores the headers of all CBFS files. Similar to the existing FMAP
cache, this cache should reduce the amount of SPI accesses we need to do
every boot: rather than having to re-read all CBFS headers from SPI
flash every time we're looking for a file, we can just walk the same
list in this in-memory copy and finally use it to directly access the
flash at the right position for the file data.
This patch adds the code to support the cache but doesn't enable it on
any platform. The next one will turn it on by default.
Change-Id: I5b1084bfdad1c6ab0ee1b143ed8dd796827f4c65
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This function is no longer required to be implemented since
EC/AUXFW sync was decoupled from vboot UI. (See CL:2087016.)
BUG=b:172343019
TEST=Compile locally
BRANCH=none
Signed-off-by: Joel Kitching <kitching@google.com>
Change-Id: I43e8160a4766a38c4fa14bcf4495fc719fbcd6c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Actual support CBnT will be added later on.
Change-Id: Icc35c5e6c74d002efee43cc05ecc8023e00631e0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46456
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Generally, this size probably doesn't matter very much, but in the
case of picasso's psp_verstage, the hash is being calculated by
hardware using relatively expensive system calls. By increasing the
block size, we can save roughly 140ms of boot and resume time.
TEST=Build & boot see that boot time has decreased.
BRANCH=Zork
BUG=b:169217270 - Zork: SHA calculation in vboot takes too long
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I68eecbbdfadcbf14288dc6e849397724fb66e0b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46901
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Provide necessary romstage hooks to allow unblocking the memory with
SCLEAN. Note that this is slow, and took four minutes with 4 GiB of RAM.
Tested on Asrock B85M Pro4 with tboot. When Linux has tboot support
compiled in, booting as well as S3 suspend and resume are functional.
However, SINIT will TXT reset when the iGPU is enabled, and using a dGPU
will result in DMAR-related problems as soon as the IOMMU is enabled.
However, SCLEAN seems to hang sometimes. This may be because the AP
initialization that reference code does before SCLEAN is missing, but
the ACM is still able to unblock the memory. Considering that SCLEAN is
critical to recover an otherwise-bricked platform but is hardly ever
necessary, prefer having a partially-working solution over none at all.
Change-Id: I60beb7d79a30f460bbd5d94e4cba0244318c124e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
SCLEAN has specific requirements and needs to run in early romstage,
since the DRAM would be locked when SCLEAN needs to be executed.
Change-Id: I77b237342e0c98eda974f87944f1948d197714db
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This is consistent with how other binaries (e.g. FSP) are added via
Kconfig. This also makes it more visible that things need to be
configured.
Change-Id: I399de6270cc4c0ab3b8c8a9543aec0d68d3cfc03
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The Kconfig variables are used in the C code for cbfs file names but
not in the Makefiles adding them.
Change-Id: Ie35508d54ae91292f06de9827f0fb543ad81734d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This CL fixes the policy digest that restricts deleting the nvmem spaces
to specific PCR0 states.
BRANCH=none
BUG=b:140958855
TEST=verified that nvmem spaces created with this digest can be deleted
in the intended states, and cannot be deleted in other states
(test details for ChromeOS - in BUG comments).
Change-Id: I3cb7d644fdebda71cec3ae36de1dc76387e61ea7
Signed-off-by: Andrey Pronin <apronin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46772
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SMM does not have access to CBMEM and therefore cannot access any
persistent state like the vboot context. This makes it impossible to
query vboot state like the developer mode switch or the currently active
RW CBFS. However some code (namely the PC80 option table) does CBFS
accesses in SMM. This is currently worked around by directly using
cbfs_locate_file_in_region() with the COREBOOT region. By disabling
vboot functions explicitly in SMM, we can get rid of that and use normal
CBFS APIs in this code.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4b1baa73681fc138771ad8384d12c0a04b605377
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46645
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If necessary, SCLEAN needs to run in early romstage, where DRAM is not
working yet. In fact, that the DRAM isn't working is the reason to run
SCLEAN in the first place. Before running GETSEC, CAR needs to be torn
down, as MTRRs have to be reprogrammed to cache the BIOS ACM. Further,
running SCLEAN leaves the system in an undefined state, where the only
sane thing to do is reset the platform. Thus, invoking SCLEAN requires
specific assembly prologue and epilogue sections before and after MTRR
setup, and neither DRAM nor CAR may be relied upon for the MTRR setup.
In order to handle this without duplicating the MTRR setup code, place
it in a macro on a separate file. This needs to be a macro because the
call and return instructions rely on the stack being usable, and it is
not the case for SCLEAN. The MTRR code clobbers many registers, but no
other choice remains when the registers cannot be saved anywhere else.
Tested on Asrock B85M Pro4, BIOS ACM can still be launched.
Change-Id: I2f5e82f57b458ca1637790ddc1ddc14bba68ac49
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46603
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This can be used to enable GETSEC/SMX in the IA32_FEATURE_CONTROL MSR,
and will be put to use on Haswell in subsequent commits.
Change-Id: I5a82e515c6352b6ebbc361c6a53ff528c4b6cdba
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46606
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
