This commit updates the secure boot support for STM platforms based on the
STM32 MPU Ecosystem v6.1.0. It introduces support for encrypted boot artifacts,
including TF-A and FIP, and enables this functionality for the ConnectCore MP2
platform.
This enhancement allows secure boot deployments with both authentication and
encryption for improved protection of critical boot components.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit updates secure boot support based on the STM32 MPU Ecosystem v6.0
and integrates support for the ConnectCore MP2 platform.
https://onedigi.atlassian.net/browse/DEL-9442
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This was causing issues when installing an SWU package on ccmp1 platforms with
dualboot disabled and Trustfence enabled: the package was triggering an
encrypted rootfs update, which isn't supported on these platforms.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
(cherry picked from commit af06ea16adc85285d9264468d2fd5946ed401de9)
Now all platforms support setting the GPIO name instead of an index
as the configuration for the GPIO-enabled secure console.
Repurpose the TRUSTFENCE_GPIO_ENABLE macro to directly set the GPIO
name.
Also take the opportunity to remove TRUSTFENCE_GPIO_ENABLE and
TRUSTFENCE_CONSOLE_PASSPHRASE_ENABLE commented definitions from bbclass
and conf files, and remove a duplicated TRUSTFENCE_CONSOLE_DISABLE
definition from ccmp1.inc.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
Commit 998598415a moved this logic to the
trustfence.bbclass file, but in doing so, it removed the TRUSTFENCE_SIGN check
it used to have. The check is needed for two reasons:
* The signing of SWU packages only occurs when TRUSTFENCE_SIGN is enabled, so
there's no need to copy the key if it's disabled
* When building a project from scratch that has Trustfence enabled but
TRUSTFENCE_SIGN disabled, a PKI is never generated and the key doesn't exist.
Because of this, the key won't be found and an error will occur. Note that
if your project is already pointing to a populated PKI, the error won't
happen, only if there's no PKI to begin with.
Although the PKI is guaranteed to exist by the time the rootfs is populated,
make sure to check that it has been properly generated and create it if it
doesn't exist. This logic depends on the trustfence-gen-pki.sh from
trustfence-sign-tools-native, so add it as a dependency for
dey-image-recovery-initramfs. The dependency is already there for another
feature in the dey-image recipes, so simply reflect this new dependency in a
comment.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
(cherry picked from commit 8e52c27d5a8e8071c3a17754e91c1819bcceee15)
This commits adds the CCMX91 platform to the DEY
build system. Furthermore, it creates generic ccimx9
support to be used for the CCiMX91 and CCiMX93
platform.
https://onedigi.atlassian.net/browse/DEL-9106
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
On new platforms, trustfence will use file-based encryption instead of
full-disk encryption. Add base variables and platform defaults to allow
implementing file-based encryption.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Encrypting boot artifacts impacts the device's boot time, so disable them
by default. It is still possible to enable it in the project's config
file by setting the TRUSTFENCE_DEK_PATH option.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Unlike the rest of the NXP platforms, in u-boot, the ccimx93 allows
configuring a GPIO name to activate the console when secure console is
enabled. Those u-boot options were not translated to the trustfence code
in meta-digi.
https://onedigi.atlassian.net/browse/DEL-9063
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Add a check on the existence of the "temp-fitimg-loaded" environment
variable before setting it. It is needed, as with encrypted FIT images,
we need to decrypt them before accessing the boot script. In such cases,
u-boot sets that variable to "no" so the boot script does not override it,
and the FIT image is loaded again before the final boot to the OS.
https://onedigi.atlassian.net/browse/DEL-8945
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Trustfence class was setting the TRUSTFENCE_PASSWORD_FILE variable using the
old keys format where a unique key_pass.txt file contains all the key
passwords. However, in the new format there are one key_pass file for each
key, so using a PKI tree with the new format throws an unexpected error in the
FIP generation due to it is not able to find the required key password.
This commit sets the TRUSTFENCE_PASSWORD_FILE variable for the ccmp1 platforms
on different way.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Different mechanisms are used to sign FIT images on the ccmp1 platforms and the
ccimx93, and we manage each mechanism via a different variable. The variable
names don't really reflect which platform they affect, which makes maintenance
harder.
Rename the variables so that it's easier to identify the platforms/vendors they
affect:
* Replace TRUSTFENCE_FIT_IMG with TRUSTFENCE_SIGN_FIT_STM
* Replace TRUSTFENCE_SIGN_FIT_ARTIFACT with TRUSTFENCE_SIGN_FIT_NXP
Don't rename TRUSTFENCE_FIT_IMG_SIGN_KEYNAME
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
We rely on FIT support to implement boot artifact authentication on ccmp1
platforms, but our implementation made it impossible to enable FIT support
outside of the context of Trustfence/secure boot.
Change this so that it's possible to enable FIT support without having to sign
the FIT artifacts. Also, modify the linux-dey 5.15 recipe so that the U-Boot
DTBs with signatures get copied only when FIT signing is enabled.
https://onedigi.atlassian.net/browse/DEL-8946
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The TF-A and OP-TEE images have different suffixes depending
on whether TrustFence is enabled or not, but the suffix variables
themselves must exist independently of whether TF is enabled.
Currently, they were defined on the trustfence.bbclass, and the
variables did not exist when TF was disabled, which caused build
problems, for example, building the SWU file.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
When TrustFence is enabled, the boot artifacts (TFA and FIP)
have a 'signed' suffix. Handle this case so that the correct
symlinks are created and the correct artifacts are put into the
SWU file.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
For signing SWU files we need to set a couple of variables:
- SWUPDATE_PRIVATE_KEY_TEMPLATE to the private key file
- SWUPDATE_PASSWORD_FILE to the password of the private key
The latter must only contain one password, whereas the current key_pass.txt
file had (for the ccmp13) the eight keys separated by a white space.
This commit:
- If the file key_pass.txt exists, it extracts each key into a separate
file key_pass0X.txt.
- If the keys don't exist, generates separate files per key.
- Changes the permissions of password files to 400.
- Adapts the sign script to use the single password files.
- Fixes a few quotes
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
meta-digi layers use many conditionals basing on TRUSTFENCE_SIGN, but this
variable may be disabled when the signing process wants to be isolated
from the image creation.
There are cases when we still need to know if TrustFence is enabled even
if the images are not going to be signed.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
In commit df9b1cf329, the UBOOT_SIGN_ENABLE is set for all
platforms, and should be only added for FIT images.
This is making the process failing in cc8mn/cc8mm platforms
due to the UBOOT_SIGN_ENABLE is also used there to use a dtb
patched with the signature node.
https://onedigi.atlassian.net/browse/DEL-8764
Signed-off-by: Francisco Gil francisco.gilmartinez@digi.com
- Set variables required for FIT signing inside python function, under the
condition of having TRUSTFENCE_SIGN="1".
- Define two sign keys using TRUSTFENCE_ wrapper constants. Default values:
- 'fitcfg' for configuration nodes inside the FIT
- 'fitimg' for image nodes inside the FIT
- Enable FIT_SIGN_INDIVIDUAL to also sign individual images inside the FIT
- Set FIT_GENERATE_KEYS by default (kernel-fitimage.bbclass already checks
if the keys exist before generating new ones)
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
This commit adds signed FIT image support for the CCMP1
platforms when using Trustfence.
https://onedigi.atlassian.net/browse/DEL-8591
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Current pattern does not match the SRKs generated for the ccimx93. The
ccimx93 does not support subordinated SGK certs, so the name of the SRKs
do not contain the "_ca_" pattern. So relax the expression used in the
trustfence bbclass to match the SRKs generated for both platforms.
# For the ccimx93
$ ls -1 crts/SRK1*crt.pem
crts/SRK1_sha512_secp521r1_v3_usr_crt.pem
# For the ccimx8x
$ ls -1 crts/SRK1*crt.pem
crts/SRK1_sha512_secp521r1_v3_ca_crt.pem
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Some platforms do not support signing external artifacts (kernel, dtb,
etc.) yet, so we need to decouple the signing of the bootloader from the
signing of the external artifacts.
This commit generalizes the code, so instead of having platform exceptions
scattered along the recipes, we create a new variable used conditionally
to sign or not the external artifacts.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Bitbake was always copying the public key 1 to the rootfs, no matter what the value specified in
the 'TRUSTFENCE_KEY_INDEX' variable was. This commit fixes the issue by enclosing the variable
between curly braces so that bitbake is able to expand it and calculate the correct key index.
Signed-off-by: David Escalona <david.escalona@digi.com>
PKI tree generation for the STM32MP15 cpu provides the undesired file
"publicKeysHashHashes.bin", which is only required by STM32MP13. This commit
generates the PKI tree according to the KeyGen tool documentation to avoid
generate this extra file and avoid confusing the end user.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
In the context of the class, we must use ${IMAGE_ROOTFS} instead of ${D}.
Change the calling of the function to POSTPROCESS (after the rootfs has
been created) instead of POSTINSTALL (after the packages have been
installed).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
When TrustFence is enabled, a PKI tree is generated.
In the case of NXP platforms, the PKI contains public certificates
from which the public key needs to be extracted using an openssl
command.
In the case of STM platforms, the PKI contains directly the
public key.
In all cases, we need the public key to be installed in the
rootfs /etc/ssl/certs/ folder, so that it can be used by
swupdate to authenticate signed SWU packages.
Up to now, this was being done on the dualboot recipe, but the
installation of the public key should really be only dependant
on the fact of TF being enabled.
This commit:
- Removes the generation of the public key from dualboot.bb.
- Generates a patch to extract the public key from the certificate
as part of the PKI tree generation (on NXP platforms).
- Installs the public key during a post install function after
the final rootfs has been created.
- For NXP platforms, extracts the public key using openssl if
it does not exist (for backwards compatibility).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Create a new script for the generation of PKI tree for STM platforms
and leave the trustfence-sign-artifact script exclusively for signing.
The new gen-pki script only requires the platform as an argument and the
path to where to save the tree (if it doesn't exist) in
CONFIG_SIGN_KEYS_PATH.
This commit also reverts commit 13c136dbc5 by getting rid of the
trustfence-genpki-native.bb recipe and moving back the PKI generation
functions into trustfence.bbclass. This recipe didn't quite guarantee
that the PKI was generated on time for the recipes that required the
keys to exist, anyway.
Instead, the PKI generation function must be called right after
do_compile() of recipe tf-a-stm32mp to be ready for do_deploy() where
the key is used.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
This commits changes the CONFIG_CONSOLE_ENABLE_GPIO_NAME to be a string
and not an integer.
https://onedigi.atlassian.net/browse/DEL-8520
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Sometimes, it may be desired that the DEY project does not sign the
artifacts, for example, if they are going to be externally signed on a
secure server. In this case, the user sets TRUSTFENCE_SIGN="0".
On STM platforms, all the variables were being set if TRUSTFENCE_SIGN="1"
and authentication support is not enabled on TF_A otherwise.
Set TF_A_SIGN_ENABLE (which adds authentication support to TF_A) always
for STM platforms (as long as the project inherits the trustfence class)
and set FIP_SIGN_ENABLE="0" if its sibling TRUSTFENCE_SIGN="0", so that
DEY doesn't sign the FIP image either.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
For the moment, do not sign aditional artifacts, such as the ramdisk,
the kernel or the boot scripts for STM platforms.
In the specific case of the ramdisk, simply copy it over with the
expected filename extension.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Several recipes depend on the PKI creation.
Create a small recipe to just run this function which
is moved from the trustfence.bbclass.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Set TRUSTFENCE_DEK_PATH to "0" for CCMP1 (not using dek.bin), as if this
was disabled.
Set temporarily TRUSTFENCE_ENCRYPT_ENVIRONMENT to "0" for CCMP1 until
environment encryption is fully supported.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The stand-alone signing script 'trustfence-sign-artifact.sh' checks
if a valid PKI tree exists (by checking the existance of four SRK
files) and if they don't, it calls trustfence-gen-pki.sh (which is
a wrapper over different generators (for HAB or AHAB) to create one.
Recipes such as 'dualboot' or 'recovery-initramfs' may need to call
openssl functions over the PKI tree. These recipes do not currently
generate the PKI tree; they expect it to be already in place.
This might not be the case if the trustfence-sign-artifact.sh script
has not been called yet.
Originally, a fake dependency on virtual/kernel recipe was made to
force it, but it doesn't quite work since the calling only happens
on deploy() while regular DEPENDS doesn't wait for this task.
If the PKI does not exist, a recipe that requires the PKI tree will
fail.
The solution is to create a function on the trustfence.bbclass that
allows any recipe to check for the existance of a PKI tree and
generate it if it doesn't exist. This is repeated inside the
trustfence-sign-artifact.sh, but it needs to be in both places
because this script must work stand-alone.
The generation of the PKI tree takes some seconds so this commit
adds a lock dir to prevent race conditions when called from
different recipes.
It also removes the fake dependency on virtual/kernel and adds a
dependency on trustfence-cst-native (which is the recipe that
provides the PKI generation tool).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://onedigi.atlassian.net/browse/DEL-8430
(cherry picked from commit 6a8bf7afff)
The stand-alone signing script 'trustfence-sign-artifact.sh' checks
if a valid PKI tree exists (by checking the existance of four SRK
files) and if they don't, it calls trustfence-gen-pki.sh (which is
a wrapper over different generators (for HAB or AHAB) to create one.
Recipes such as 'dualboot' or 'recovery-initramfs' may need to call
openssl functions over the PKI tree. These recipes do not currently
generate the PKI tree; they expect it to be already in place.
This might not be the case if the trustfence-sign-artifact.sh script
has not been called yet.
Originally, a fake dependency on virtual/kernel recipe was made to
force it, but it doesn't quite work since the calling only happens
on deploy() while regular DEPENDS doesn't wait for this task.
If the PKI does not exist, a recipe that requires the PKI tree will
fail.
The solution is to create a function on the trustfence.bbclass that
allows any recipe to check for the existance of a PKI tree and
generate it if it doesn't exist. This is repeated inside the
trustfence-sign-artifact.sh, but it needs to be in both places
because this script must work stand-alone.
The generation of the PKI tree takes some seconds so this commit
adds a lock dir to prevent race conditions when called from
different recipes.
It also removes the fake dependency on virtual/kernel and adds a
dependency on trustfence-cst-native (which is the recipe that
provides the PKI generation tool).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://onedigi.atlassian.net/browse/DEL-8430
True is the default since long time ago, and thus not necessary. This
follows similar changes done in other layers.
Command used:
sed -e 's|\(d\.getVar \?\)( \?\([^,()]*\), \?True)|\1(\2)|g' -i $(git grep -E 'getVar ?\( ?([^,()]*), ?True\)' | cut -d':' -f1 | sort -u)
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Instead of overriding the whole do_compile function, just to reconfigure
u-boot for Trustfence, create a do_configure pre-function that takes care
of that. This allows the removal of duplicated code.
Also, disable the generation of u-boot environment artifacts. We are
not using them and so many u-boot artifacts in the deploy directory
are confusing.
Finally, adjust the names of the TF u-boot artifacts in the do_deploy
append function.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Signed image support in U-Boot has been split into two separate configurations:
one that adds artifact authentication support and another that signs the U-Boot
binary at the end of the build. Reflect this change in meta-digi.
https://onedigi.atlassian.net/browse/DEL-7862
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
SQUASHFS read-only rootfs cannot be unencrypted on-the-fly
so skip encryption if read-only-rootfs is active.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
When TrustFence and a read-only rootfs are enabled, U-Boot must
authenticate the SQUASHFS root file system. Add config switch to force
U-Boot to authenticate this image.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Arturo Buzarra
Gabriel Valcazar
Gonzalo Ruiz
Mike Engel
Javier Viguera
Hector Palacios
fgilmar
David Escalona