The digest size in bytes for sha1/256/384/512 were defined in multiple
places. Refactor the macros into a common header file.
Change-Id: I84ef3561486ff70345ae8c871d5d6e1564574ec2
Signed-off-by: Raghu Krishnamurthy <raghupathyk@nvidia.com>
The target_locality attribute is meant to specify that
a certain SW component is expected to run and thereby
send DPE commands from a given security domain. The DPE
service must be capable of determining the locality of
a client on his own. RSE determines the client's locality
based on the MHU channel used for communication.
If the expected locality (specified by the parent component)
is not matching with the determined locality by DPE
service then command fails.
The goal is to protect against spoofing when a
context_handle is stolen and used by a component
that should not have access.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: I96d255de231611cfed10eef4335a47b91c2c94de
Improve the restart handling of DPE. In the case of a restart
scenario where only that core is restarted which executes
the DPE client, but the core executes the DPE service
remains up and running. In this case, client needs to save
a valid context handle to be able to send commands again
to the DPE service during the new boot sequence.
BL1 saves a valid parent context handle to SDS
before passing the execution to BL2. This handle
can be used in case of a restart scenario when AP
is restarted but RSE is not. Because in that case
RSE does not save an initial context handle to SDS,
which meant to be used by AP during the boot process.
By then the very first initial context handle is
invalidated because it was already used in the
previous boot cycle by BL1.
BL2 does not need to do this, because the cold
boot starts with BL1.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: Id14eefd2ec758f89f672af176e4f5386a397fa35
Changes all occurrences of "RSS" and "rss" in the code and build files
to "RSE" and "rse".
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: I8c2fcbdf1de1c75f9969d28bc15e0b3500071404
This custom argument is meant to simplify to group
components into certificates. Components with
the same cert_id contribute to the same certificate
regardless of the load order or the structure of the
derivation tree. This argument aims to flatten the tree
structure and make it easy to include branches or
subtrees in the main derivation line.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: I83c4abc399616063a5eb04792d603899f7513627
Each client who wants to communicate with the DPE service
must own a valid context handle issued by the DPE service.
A context handle can be used for a single time then it will
be invalidated by the DPE service. In case of calls from
the same component, the next valid context handle is
returned in the response to a DPE command. When a component
finishes their job then the next component in the boot flow
inherits its first context handle from its parent.
How the inheritance is done can be client or
platform-dependent. It can be shared through shared
memory or be part of a DTB object passed to the next
bootloader stage.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Signed-off-by: David Vincze <david.vincze@arm.com>
Change-Id: Ic82f074f1c5b15953e78f9fa5404ed7f48674cbb
To be allowed to communicate with DPE service all
components must own a valid context handle. The first
valid context handle is inherited from the parent
component via a DTB object.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: Id357fab3586398b1933444e1d10d1ab6d8243ab9
Implement a DPE specific backend within the
generic measured boot framework.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: Ia3a0eac0ee6f7b4b337a93d08286613e7c8186b4
The max size macros of metadata elements are shared across
multiple measured boot backends: rss-measured-boot, dpe.
Increase the SW_TYPE_MAX_SIZE to be able to accomodate
all macro.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: Ic9004a36ef1df96c70a4f7adf7bb86dc27dd307c
The image identifier strings are used across different measured boot
backends. Move them to a common location to avoid the redefiniton
of these per backend and to avoid code duplication.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: I58897b9a19396be932ca5d230ee00858c09ef03f
Calculate a hash of the public key and put that into the signer-ID
field of the relevant RSS metadata. The signer-ID metadata is mandatory
in the Arm CCA attestation scheme.
Change-Id: Ic846d8bf882cfea8581d3523a3461c919462df30
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Currently, Measured Boot RSS driver gathers data from platform calls,
specifically RSS metadata. Generally, the driver should use the least
amount of platform calls possible, and the platform should provide the
data directly to the driver via the driver interface.
For this purpose, RSS Measured Boot driver interface APIs were updated
and platform calls were removed from RSS Measured Boot driver.
Change-Id: I6c797d9ac2d70215f32a084a7643884b399ee28c
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Updated the event log driver's function to accept metadata as an
argument, to remove the platform function usage from the event log
driver to make it a standalone driver.
Change-Id: I512cf693d51dc3c0b9d2c1bfde4f89414e273049
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Reorganized a few Event Log functions into multiple functions so that
they can be used for the upcoming DRTM feature. This change mainly
implements below new functions -
1. event_log_buf_init - called by 'event_log_init' to initialise Event
Log buffer
2. event_log_write_specid_event - called by 'event_log_fixed_header' to
write specification id event to Event Log buffer
3. event_log_measure and event_log_record - called by
'event_log_measure_and_record' to measure and record the measurement
to the Event Log buffer
Change-Id: I1aabb57f79bead726fcf36d59839702cd6a3521d
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Added PCR entries for the measurement performed by the
DCE and D-CRTM in DRTM implementation
Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>
Change-Id: Ib9bfafe7fa2efa1cc36d7ff138468d648235dcf1
Add SP entries to event_log_metadata if SPD_spmd is enabled. Otherwise
the platform cannot boot with measured boot enabled.
Signed-off-by: Imre Kis <imre.kis@arm.com>
Change-Id: I525eb50e7bb60796b63a8c7f81962983017bbf87
Enable the RSS backend based measured boot feature.
In the absence of RSS the mocked version of PSA APIs
are used. They always return with success and hard-code data.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: I7543e9033a7a21f1b836d911d8d9498c6e09b956
Runtime Security Subsystem (RSS) provides for the host:
- Runtime service to store measurments, which were
computed by the host during measured boot.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: Ia9e4e8a1fe8f01a28da1fd8c434b780f2a08f94e
Platforms which support Realm world cannot boot up
properly if measured boot is enabled at build time.
An assertions occurs due to the missing RMM entry
in the event_log_metadata array.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: I172f10a440797f7c9e1bc79dc72242b40c2521ea
Implemented a platform function 'plat_mboot_measure_critical_data' to
measure critical data and record its measurement using the Event Log
driver.
'bl2_plat_mboot_finish' function invokes this platform function
immediately after populating the critical data.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: Ia198295c6e07ab26d436eab1ff90df2cf28303af
Renamed a macro 'INVALID_ID' to 'EVLOG_INVALID_ID' to avoid its clash
with other macro names and to show it is explicitly used for Event
Log driver.
Change-Id: Ie4c92b3cd1366d9a59cd6f43221e24734865f427
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Made measurement strings compliant to Server Base Security Guide
(SBSG, Arm DEN 0086) hence updated measurement strings for BL32, BL31,
and SCP_BL2 images. As the GPT image is not get measured by BL2 so
removed its measurement string.
Also, namespaced measurement string defines that were looking quite
generic.
Change-Id: Iaa17c0cfeee3d06dc822eff2bd553da23bd99b76
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
It looks safer and cleaner approach to record the measurement taken by
BL1 straightaway in TCG Event Log instead of deferring these recordings
to BL2.
Hence pull in the full-fledged measured boot driver into BL1 that
replaces the former ad-hoc platform interfaces i.e.
bl1_plat_set_bl2_hash, bl2_plat_get_hash.
As a result of this change the BL1 of Arm FVP platform now do the
measurements and recordings of below images:
1. FW_CONFIG
2. TB_FW_CONFIG
3. BL2
Change-Id: I798c20336308b5e91b547da4f8ed57c24d490731
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Currently, the Event Log driver does platform layer work by invoking
a few platform functions in the 'event_log_finalise' call. Doing
platform work does not seem to be the driver's responsibility, hence
moved 'event_log_finalise' function's implementation to the platform
layer.
Alongside, introduced few Event Log driver functions and done
some cosmetic changes.
Change-Id: I486160e17e5b0677c734fd202af7ccd85476a551
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Right now, event_log_init() does 2 things:
1) It writes all the necessary TCG data structures in the event log buffer.
2) It writes the first measurement (BL2's).
Step 2) introduces in the TCG event log driver an assumption on what
is getting measured and in what order. Ideally, the driver should only
be concerned about generic operations, such as initializing the event
log or recording a measurement in it. As much as possible, we should
design the driver such that it could be reused in another project that
has a different measure boot flow.
For these reasons, move step 2) up to the caller, plat_mboot_init() in
this case. Make event_log_record() a public function for this purpose.
This refactoring will also help when we make BL1 record BL2's
measurement into the event log (instead of BL2). Both BL1 and BL2 will
need to call the driver's init function but only BL1 will need
recording BL2's measurement. We can handle this through different
implementations of plat_mboot_init() for BL1 and BL2, leaving the TCG
event log driver unchanged.
Change-Id: I358e097c1eedb54f82b866548dfc6bcade83d519
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
With the removal of the generic functions measured_boot_init()/finish(),
measured_boot.mk becomes specific to the TCG event log backend. Change
its file name to event_log.mk.
Also, the Event Log driver is one of the backend of measured boot hence
created a separate folder for it under the measured_boot directory.
Alongside done some cosmetic changes (adding a comment and fixing
identation).
Change-Id: I4ce3300e6958728dc15ca5cced09eaa01510606c
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Right now, the measured boot driver is strongly coupled with the TCG
event log driver. It would not be possible to push the measurements
somewhere else, for instance to a physical TPM.
To enable this latter use case, turn the driver's init and teardown
functions into platform hooks. Call them bl2_plat_mboot_init()/finish().
This allows each platform to implement them appropriately, depending on
the type of measured boot backend they use. For example, on a platform
with a physical TPM, the plat_mboot_init() hook would startup the TPM
and setup it underlying bus (e.g. SPI).
Move the current implementation of the init and teardown function to the
FVP platform layer.
Finally move the conditional compilation logic (#if MEASURED_BOOT) out
of bl2_main() to improve its readability. Provide a dummy implementation
in the case measured boot is not included in the build.
Change-Id: Ib6474cb5a9c1e3d4a30c7f228431b22d1a6e85e3
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
tpm_record_measurement() function name suggests that:
- It only records a measurement but does not compute it.
This is not the case, the function does both.
- It stores this measurement into a TPM (discrete chip or fTPM).
This is not the case either, the measurement is just stored into
the event log, which is a data structure hold in memory, there is
no TPM involvement here.
To better convey the intent of the function, rename it into
event_log_measure_and_record().
Change-Id: I0102eeda477d6c6761151ac96759b31b6997e9fb
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Builds in Debug mode with Measured Boot enabled might run out of trusted
SRAM. This patch allows to change the Log Level at which the Measured Boot
driver will dump the event log, so the latter can be accessed even on
Release builds if necessary, saving space on RAM.
Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com>
Change-Id: I133689e313776cb3f231b774c26cbca4760fa120
This patch adds support for Event Log generation required
for Measured Boot functionality.
Change-Id: I34f05a33565e6659e78499d62cc6fb00b7d6c2dc
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
