The wrong format was used. It looks like struct bitfields are of type
int according to gcc so %u needs to be used and not %lu.
Change-Id: I54419d722aec0d43e6f54a4bb4eb4d899c909fec
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55847
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The CBnT provisioning tooling in intel-sec-tools are now cbfs aware
and don't need to have a fixed size at buildtime.
Tested on OCP/Deltalake with CBnT enabled.
Change-Id: I446b5045fe65f51c5fa011895cd56dbd25b6ccc7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55821
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christopher Meis <christopher.meis@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On platforms where the boot media can be updated externally, e.g.
using a BMC, add the possibility to enable writes in SMM only. This
allows to protect the BIOS region even without the use of vboot, but
keeps SMMSTORE working for use in payloads. Note that this breaks
flashconsole, since the flash becomes read-only.
Tested on Asrock B85M Pro4 and HP 280 G2, SMM BIOS write protection
works as expected, and SMMSTORE can still be used.
Change-Id: I157db885b5f1d0f74009ede6fb2342b20d9429fa
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This decodes and logs the CBnT status and error registers.
Change-Id: I8b57132bedbd944b9861ab0e2e0d14723cb61635
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54093
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The purpose is to reuse the types string in CBnT error printing.
Change-Id: I435de402fef6d4702c9c7250c8bd31243a04a46e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54092
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Always building makes sure this code gets buildtested.
Calling this code already was guarded by
"if CONFIG(INTEL_TXT_LOGGING)".
Also build this in all stages as future code will use this in
bootblock.
Change-Id: I654adf16b47513e3279335c8a8ad48b9371d438e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54295
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 makes it possible to build cbnt-prov with Jenkins.
Change-Id: I658723a4e10bff45176d7c1ea7a410edbb182dc6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
If the early crtm is not initialised there is nothing to write to PCR
in the early tpm init.
Change-Id: I9fa05f04588321163afc817de29c03bd426fc1f0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55470
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is only called locally.
Change-Id: Ie3eaf659a2868eee1d4688885495c413f94f42e2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55469
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Depending on how the "middle-end" (yes, the gcc developers are
serious about that) optimizer ends up mangling the code, there may
or may not be a complaint about x being used uninitialized when it's
clearly not used at all.
So instead, why keep x in the first place? memcpy(foo, NULL, 0) is
the same as memcpy(foo, some_uninitialized_variable, 0) in that it
does nothing.
Change-Id: Ib0a97c3e3fd1a2a6aff37da63376373c88ac595d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We are not currently tracking how long it takes to load verstage. The
enum values already exist, they just weren't used.
BUG=b:179092979
TEST=Dump timestamps
501:starting to load verstage 2,280,656 (1)
502:finished loading verstage 2,340,845 (60,189)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I2cde58cb8aa796829a4e054e6925e2394973484b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This commit adds support for the Chrome OS Zero-Touch Enrollment related
spaces. For TPM 2.0 devices which don't use Cr50, coreboot will define
the RMA+SN Bits, Board ID, and RMA Bytes counter spaces.
The RMA+SN Bits space is 16 bytes initialized to all 0xFFs.
The Board ID space is 12 bytes initialized to all 0xFFs.
The RMA Bytes counter space is 8 bytes intialized to 0.
BUG=b:184676425
BRANCH=None
TEST=Build and flash lalala, verify that the ZTE spaces are created
successfully by undefining the firmware antirollback space in the TPM
such that the TPM undergoes factory initialization in coreboot. Reboot
the DUT. Boot to CrOS and run `tpm_manager_client list_spaces` and
verify that the ZTE spaces are listed. Run `tpm_manager_client
read_space` with the various indices and verify that the sizes and
initial values of the spaces are correct.
TEST=Attempt to undefine the ZTE spaces and verify that it fails due to
the unsatisfiable policy.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I97e3ae7e18fc9ee9a02afadbbafeb226b41af0eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55242
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds support for the TPM2_NV_SetBits command to the TLCL.
This command is used to set bits in an NV index that was created as a
bit field. Any number of bits from 0 to 64 may be set. The contents of
bits are ORed with the current contents of the NV index.
The following is an excerpt from lalala undergoing TPM factory
initialization which exercises this function in a child commit:
```
antirollback_read_space_firmware():566: TPM: Not initialized yet.
factory_initialize_tpm():530: TPM: factory initialization
tlcl_self_test_full: response is 0
tlcl_force_clear: response is 0
tlcl_define_space: response is 14c
define_space():197: define_space: kernel space already exists
tlcl_write: response is 0
tlcl_define_space: response is 14c
define_space():197: define_space: RO MRC Hash space already exists
tlcl_write: response is 0
tlcl_define_space: response is 14c
define_space():197: define_space: FWMP space already exists
tlcl_write: response is 0
tlcl_define_space: response is 0
tlcl_write: response is 0
tlcl_define_space: response is 0
tlcl_write: response is 0
tlcl_define_space: response is 0
tlcl_set_bits: response is 0
tlcl_define_space: response is 0
tlcl_write: response is 0
factory_initialize_tpm():553: TPM: factory initialization successful
```
BUG=b:184676425
BRANCH=None
TEST=With other changes, create a NVMEM space in a TPM 2.0 TPM with the
bits attribute. Issue the command and verify that the TPM command
succeeds.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I6ca6376bb9f7ed8fd1167c2c80f1e8d3c3f46653
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55241
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Bob Moragues <moragues@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch assings 2 to EC_EFS_BOOT_MODE_TRUSTED_RO to make coreboot
set VB2_CONTEXT_EC_TRUSTED when the GSC reports TRUSTED_RO.
Old GSC doesn't use 2. So, the new BIOS won't mistakenly set
VB2_CONTEXT_EC_TRUSTED.
BUG=b:180927027, b:187871195
BRANCH=none
TEST=build
Change-Id: I11a09d0035a4bd59f80018c647ca17e3318be81e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55373
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update intel-sec-tools to commit of BootGuard support.
Remove --coreboot argument in src/security/intel/cbnt/Makefile.inc:
was removed as argument for cbnt
Change-Id: Iaf34bdb65a5f067d1d632e35d340b8fc49aaf318
Signed-off-by: Christopher Meis <christopher.meis@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55013
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch makes coreboot set VB2_CONTEXT_EC_TRUSTED based on the EC"s
boot mode. Vboot will check VB2_CONTEXT_EC_TRUSTED to determine
whether it can enter recovery mode or not.
BUG=b:180927027, b:187871195
BRANCH=none
TEST=build
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I9fa09dd7ae5baa1efb4e1ed4f0fe9a6803167c93
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
We would like to have an easy way to completely disable TPM support on a
board. For boards that don't pre-select a TPM protocol via the
MAINBOARD_HAS_TPMx options, this is already possible with the
USER_NO_TPM option. In order to make this available for all boards, this
patch just removes the whole USER_TPMx option group and directly makes
the TPM1 and TPM2 options visible to menuconfig. The MAINBOARD_HAS_TPMx
options can still be used to select defaults and to prevent selection of
a protocol that the TPM is known to not support, but the NO_TPM option
always remains available.
Also fix some mainboards that selected TPM2 directly, which they're not
supposed to do (that's what MAINBOARD_HAS_TPM2 is for), and add a
missing dependency to TPM_CR50 so it is set correctly for a NO_TPM
scenario.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib0a73da3c42fa4e8deffecb53f29ee38cbb51a93
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54641
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Most of the time when INIT_BOOTBLOCK is selected, the cache should be
empty here anyway, so this is a no-op. But when it's not empty that
means the bootblock loaded some other file before it got to the TPM
init part (which is possible, for example, if hooks like
bootblock_soc_init() load something).
Change-Id: I4aea86c094abc951d7670838f12371fddaffaa90
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
TPM_RUNTIME_DATA_PCR is for "for measuring data which changes during
runtime e.g. CMOS, NVRAM..." according to comments. FMAP does not
change during runtime.
Change-Id: I23e61a2dc25cd1c1343fb438febaf8771d1c0621
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52968
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
RAS error injection requires TXT and other related lockdown steps to
be skipped.
Change-Id: If9193a03be7e1345740ddc705f20dd4d05f3af26
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The new kernel secdata v1 stores the last read EC hash, and reboots the
device during EC software sync when that hash didn't match the currently
active hash on the EC (this is used with TPM_CR50 to support EC-EFS2 and
pretty much a no-op for other devices). Generally, of course the whole
point of secdata is always that it persists across reboots, but with
MOCK_SECDATA we can't do that. Previously we always happened to somewhat
get away with presenting freshly-reinitialized data for MOCK_SECDATA on
every boot, but with the EC hash feature in secdata v1, that would cause
a reboot loop. The simplest solution is to just pretend we're a secdata
v0 device when using MOCK_SECDATA.
This was encountered on using a firmware built with MOCK_SECDATA but had
EC software sync enabled.
BUG=b:187843114
BRANCH=None
TEST=`USE=mocktpm cros build-ap -b keeby`; Flash keeby device, verify
that DUT does not continuously reboot with EC software sync enabled.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: Id8e81afcddadf27d9eec274f7f85ff1520315aaa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This commit has coreboot create the Chrome OS Firmware Management
Parameters (FWMP) space in the TPM. The space will be defined and the
contents initialized to the defaults.
BUG=b:184677625
BRANCH=None
TEST=emerge-keeby coreboot
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I1f566e00f11046ff9a9891c65660af50fbb83675
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
The name `set_space()` seems to imply that it's writing to a TPM space
when actually, the function can create a space and write to it. This
commit attempts to make that a bit more clear. Additionally, in order
to use the correct sizes when creating the space, this commit also
refactors the functions slightly to incorporate the vboot context object
such that the correct sizes are used. The various vboot APIs will
return the size of the created object that we can then create the space
with.
BUG=b:184677625
BRANCH=None
TEST=`emerge-keeby coreboot`
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I80a8342c51d7bfaa0cb2eb3fd37240425d5901be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54308
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The CBFS mcache size default was eyeballed to what should be "hopefully
enough" for most users, but some recent Chrome OS devices have already
hit the limit. Since most current (and probably all future) x86 chipsets
likely have the CAR space to spare, let's just double the size default
for all supporting chipsets right now so that we hopefully won't run
into these issues again any time soon.
The CBFS_MCACHE_RW_PERCENTAGE default for CHROMEOS was set to 25 under
the assumption that Chrome OS images have historically always had a lot
more files in their RO CBFS than the RW (because l10n assets were only
in RO). Unfortunately, this has recently changed with the introduction
of updateable assets. While hopefully not that many boards will need
these, the whole idea is that you won't know whether you need them yet
at the time the RO image is frozen, and mcache layout parameters cannot
be changed in an RW update. So better to use the normal 50/50 split on
Chrome OS devices going forward so we are prepared for the eventuality
of needing RW assets again.
The RW percentage should really also be menuconfig-controllable, because
this is something the user may want to change on the fly depending on
their payload requirements. Move the option to the vboot Kconfigs
because it also kinda belongs there anyway and this makes it fit in
better in menuconfig. (I haven't made the mcache size
menuconfig-controllable because if anyone needs to increase this, they
can just override the default in the chipset Kconfig for everyone using
that chipset, under the assumption that all boards of that chipset have
the same amount of available CAR space and there's no reason not to use
up the available space. This seems more in line with how this would work
on non-x86 platforms that define this directly in their memlayout.ld.)
Also add explicit warnings to both options that they mustn't be changed
in an RW update to an older RO image.
BUG=b:187561710
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I046ae18c9db9a5d682384edde303c07e0be9d790
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54146
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
While memcpy(foo, bar, 0) should be a no-op, that's hard to prove for a
compiler and so gcc 11.1 complains about the use of an uninitialized
"bar" even though it's harmless in this case.
Change-Id: Idbffa508c2cd68790efbc0b4ab97ae1b4d85ad51
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54095
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Because the STM build doesn't use the coreboot toolchain it's not
reproducible. Make sure that's displayed during the build.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I3f0101400dc221eca09c928705f30d30492f171f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Building the cbnt-prov tool requires godeps which does not work if
offline. Therefore, add an option to provide this binary via Kconfig.
It's the responsibility of the user to use a compatible binary then.
Change-Id: I06ff4ee01bf58cae45648ddb8a30a30b9a7e027a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some changes:
- bg-prov got renamed to cbnt-prov
- cbfs support was added which means that providing IBB.Base/Size
separatly is not required anymore. Also fspt.bin gets added as an
IBB to secure the root of trust.
Change-Id: I20379e9723fa18e0ebfb0622c050524d4e6d2717
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52971
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 prepares for updating the intel-sec-tools submodule pointer. In
that submodule bg-prov got renamed to cbnt-prov as Intel Bootguard
uses different structures and will require a different tool.
Change-Id: I54a9f458e124d355d50b5edd8694dee39657bc0d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
When using a hardware assisted root of trust measurement, like Intel
TXT/CBnT, the TPM init needs to happen inside the bootblock to form a
proper chain of trust.
Change-Id: Ifacba5d9ab19b47968b4f2ed5731ded4aac55022
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51923
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
FMAP is used to look up cbfs files or other FMAP regions so it should
be measured too.
TESTED: on qemu q35 with swtpm
Change-Id: Ic424a094e7f790cce45c5a98b8bc6d46a8dcca1b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52753
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
fspt.bin is run before verstage so it is of no use in RW_A/B.
Change-Id: I6fe29793fa638312c8b275b6fa8662df78b3b2bd
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch changes the vboot EC sync code to use the new CBFS API. As a
consequence, we have to map the whole EC image file at once (because the
new API doesn't support partial mapping). This should be fine on the
only platform that uses this code (Google_Volteer/_Dedede family)
because they are x86 devices that support direct mapping from flash, but
the code was originally written to more carefully map the file in
smaller steps to be theoretically able to support Arm devices.
EC sync in romstage for devices without memory-mapped flash would be
hard to combine with CBFS verification because there's not enough SRAM
to ever hold the whole file in memory at once, but we can't validate the
file hash until we have loaded the whole file and for performance (or
TOCTOU-safety, if applicable) reasons we wouldn't want to load anything
more than once. The "good" solution for this would be to introduce a
CBFS streaming API can slowly feed chunks of the file into a callback
but in the end still return a "hash valid/invalid" result to the caller.
If use cases like this become pressing in the future, we may have to
implement such an API.
However, for now this code is the only part of coreboot with constraints
like that, it was only ever used on platforms that do support
memory-mapped flash, and due to the new EC-EFS2 model used on more
recent Chrome OS devices we don't currently anticipate this to ever be
needed again. Therefore this patch goes the easier way of just papering
over the problem and punting the work of implementing a more generic
solution until we actually have a real need for it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7e263272aef3463f3b2924887d96de9b2607f5e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52280
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
RETURN_FROM_VERSTAGE is a somewhat tricky construct that we don't
normally do otherwise in coreboot. While it works remarkably well in
general, new development can lead to unintentional interactions with
confusing results. This patch adds a debug print to the verstage right
before returning to the bootblock so that it's obvious this happens,
because otherwise in some cases the last printout in the verstage is
about some TPM commands which can be misleading when execution hangs
after that point.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9ca68a32d7a50c95d9a6948d35816fee583611bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52086
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using brackets here seems to break the build for _some_ environments.
Removing the brackets fixes it and works just fine.
Change-Id: I965b0356337fe74281e7f410fd2bf95c9d96ea93
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51974
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Deomid "rojer" Ryabkov <rojer9@fb.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The PCR algorithms used for vboot are frequently causing confusion (e.g.
see CB:35645) because depending on the circumstances sometimes a
(zero-extended) SHA1 value is interpreted as a SHA256, and sometimes a
SHA256 is interpreted as a SHA1. We can't really "fix" anything here
because the resulting digests are hardcoded in many generations of
Chromebooks, but we can document and isolate it better to reduce
confusion. This patch adds an explanatory comment and fixes both
algorithms and size passed into the lower-level TPM APIs to their actual
values (whereas it previously still relied on the TPM 1.2 TSS not
checking the algorithm type, and the TPM 2.0 TSS only using the size
value for the TCPA log and not the actual TPM operation).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib0b6ecb8c7e9a405ae966f1049158f1d3820f7e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This add an option to generate BPM using the 9elements bg-prov tool
using a json config file.
A template for the json config file can be obtained via
"bg-prov template".
Another option is to extract it from a working configuration:
"bg-prov read-config".
The option to just include a provided BPM binary is kept.
Change-Id: I38808ca56953b80bac36bd186932d6286a79bebe
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50411
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 is useful if you have external infrastructure to sign KM.
Change-Id: If5e9306366230b75d97e4e1fb271bcd7615abd5f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51572
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add an option to generate the Key Manifest from Kconfig options.
Change-Id: I3a448f37c81148625c7879dcb64da4d517567067
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50410
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This add an option to generate KM using the 9elements bg-prov tool
using a json config file.
The option to just include a provided KM binary is kept.
A template for the json config file can be obtained via
"bg-prov template".
Another option is to extract it from a working configuration:
"bg-prov read-config".
Change-Id: I18bbdd13047be634b8ee280a6b902096a65836e4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50409
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Private and/or public keys will be provided as user input via Kconfig.
As a private key also contains the public key, only ask what is required.
Change-Id: I86d129bb1d13d833a26281defad2a1cb5bf86595
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Make sure the bytes in RTC cmos used by CBNT don't collide with the
option table. This depends on what is set up in the BPM, Boot Policy
Manifest. When the BPM is provided as a binary the Kconfig needs to be
adapted accordingly. A later patch will use this when generating the
BPM.
Change-Id: I246ada8a64ad5f831705a4293d87ab7adc5ef3aa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51538
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With CBnT a digest needs to be made of the IBB, Initial BootBlock, in
this case the bootblock. After that a pointer to the BPM, Boot Policy
Manifest, containing the IBB digest needs to be added to the FIT
table.
If the fit table is inside the IBB, updating it with a pointer to the
BPM, would make the digest invalid.
The proper solution is to move the FIT table out of the bootblock.
The FIT table itself does not need to be covered by the digest as it
just contains pointers to structures that can by verified by the
hardware itself, such as microcode and ACMs (Authenticated Code
Modules).
Change-Id: I352e11d5f7717147a877be16a87e9ae35ae14856
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50926
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In pursuit of the eventual goal of removing cbfs_boot_locate() (and
direct rdev access) from CBFS APIs, this patch replaces all remaining
"simple" uses of the function call that can easily be replaced by the
newer APIs (like cbfs_load() or cbfs_map()). Some cases of
cbfs_boot_locate() remain that will be more complicated to solve.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icd0f21e2fa49c7cc834523578b7b45b5482cb1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Arthur Heymans