Adds support for signing and encrypting Cortex-M firmware on STM platforms,
following the STM32 MPU Ecosystem v6.1.0. This update enables secure boot of
co-processor binaries on ConnectCore MP2, enhancing firmware protection.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
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>
On NXP platforms, the signed/encrypted bootloader images are not
included on the installer ZIP. This prevents from using the installer
when TrustFence is enabled.
This commit adds to the installer:
- If encryption is enabled
- encrypted bootloader
- signed bootloader (for USB recovery boot)
- If encryption is disabled
- signed bootloader
- If TrustFence is disabled
- non-signed bootloader
It also treats the ccimx6ul special, as this has a dedicated file for
USB recovery boot.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://onedigi.atlassian.net/browse/DEL-9698
This generates an installer.zip image with all the firmware
images, including install scripts for UUU, SD card, and USB.
This is helpful to share the artifacts with manufacturing
or for deploying to external media such as microSD or USB stick.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
There are several recipes in meta-digi related to features that we haven't
tested in a long time and don't appear in the DEY 5.0 documentation. Remove
them to avoid unexpected behavior.
Said features are:
* Coral TPU support (only supported in DEY 3.2)
* AWS support (removed from default images and docs in DEY 4.0)
* dey-image-tiny (hasn't been maintained since DEY 2.0)
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@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>
Refactored some functions to make them more generic, allowing for
greater parameter reusability.
https://onedigi.atlassian.net/browse/DEL-9526
Signed-off-by: Francisco Gil <francisco.gilmartinez@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>
Our new dey-toolchain recipe was missing the logic needed to create the
"dey-version" file in the SDK's installation path. Move this logic from the
dey-image bbclass to a new bbclass meant exclusively for SDK logic, and inherit
it where needed. While at it, move other common SDK modifications to this
class.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@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)
When it comes to inheriting this qt bbclass, we used to do so for every image
inheriting the "dey-image" bbclass that had "dey-qt" in its IMAGE_FEATURES. In
theory, only dey-image-qt follows these requirements.
However, starting in DEY 3.0, we added support for multiple graphical images,
all of them sharing the same characteristics save for a defining IMAGE_FEATURE.
To implement this, all images have the IMAGE_FEATURE "dey-${GRAPHICAL_CORE}",
with GRAPHICAL_CORE having a default value of "qt" and being overwritten in
each image recipe with its respective value: "qt", "webkit", "crank" or "lvgl".
The problem is that, when checking whether to inherit populate_sdk_qt[5/6] or
not, it's still very early in the recipe parsing process and GRAPHICAL_CORE
still has its default value of "qt", meaning the "dey-qt" IMAGE_FEATURE is
considered present for all graphical images. In turn, this results in qt
packages being included in all graphical image SDKs.
Move the inherit clause to the dey-image-qt recipe and remove the check so
that the qt packages only get installed in the dey-image-qt SDK.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
(cherry picked from commit 593ff866578e6d341ec4d8a09581922c6390e2a4)
Commit 99f1425340 ("image-buildinfo: Improve and extend to SDK coverage too")
in the Poky layer changes the name of the default build information file from
"build" to "buildinfo", so this commit reflects this change by adapting the
sysinfo script.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit enables SWU image authentication when TrustFence
is enabled instead of when signing of images is enabled.
This allows the system to authenticate SWU images on images that
have been externally signed.
https://onedigi.atlassian.net/browse/DEL-8891
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
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 support to update U-Boot in the redundant partition must be enabled in the project
configuration file by setting the variable "SWUPDATE_UBOOTIMG_REDUNDANT" to "true":
SWUPDATE_UBOOTIMG_REDUNDANT = "true"
This feature is only available for the newer platforms: ccmp13, ccmp15 and ccimx93. Trying to
enable it in older platforms will display a warning and fallback to non-redundant update.
Signed-off-by: David Escalona <david.escalona@digi.com>
While on it, enable support to update encrypted U-Boot for all mmc platforms
supporting it. The install script extracts the DEK blob from the installed
U-Boot and appends it to the new U-Boot before flashing it.
Signed-off-by: David Escalona <david.escalona@digi.com>
This new variable establishes the number of 1Kb blocks to skip before writing U-Boot in the
bootloader partition.
Signed-off-by: David Escalona <david.escalona@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>
This commit adds u-boot swupdate support for all platforms.
Now u-boot can be updated with all our supported update
options. Currently it will only update first partition
u-boot partition.
https://onedigi.atlassian.net/browse/DEL-8749
Signed-off-by: Mike Engel <Mike.Engel@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>
Implement a new mechanism to allow users to create update packages based on differences for read-only
systems. The update mechanism requires full knowledge of the current software running on the device in order
to compute a sensitive patch. For this reason, only systems without user modifications in the rootfs/boot
partitions are eligible for this kind of updates. At the moment, only the 'rootfs' partition supports the
read-only squashfs file system type, so it is the only partition supporting incremental updates. The 'boot'
partition will still be updated but as a full image.
This new feature is done making use of the SWUpdate 'rdiff' handler, which applies binary deltas with the
functionallity provided by the rsync library. During the update process, the contents of the active 'rootfs'
partition are read as the base and written to the inactive 'rootfs' partition applying the delta binary patch
on-the-fly. To ensure the delta file is applied using the correct base, the firmware update process verifies
the contents of the 'rootfs' base partition before applying the update.
The binary delta file is automatically generated by the DEY build system using the resulting 'rootfs' squashfs
image as target and the user specified file as source. The file is then packaged with the rest of components in
the SWU update image. Users must specify the base source file in their project configuration file using the
new variable 'SWUPDATE_RDIFF_ROOTFS_SOURCE_FILE'. Also, 'read-only-rootfs' image feature should be set in the
project to generate this new SWU update package.
Since a base and a target 'rootfs' partition is required during the update, only 'dualboot' systems can benefit
from this new feature.
Note: If variable 'SWUPDATE_RDIFF_ROOTFS_SOURCE_FILE' is configured in the project but any of 'SWUPDATE_FILES_LIST'
or 'SWUPDATE_FILES_TARGZ_FILE' variables is also set, the build system will prioritize a SWU update package
based on files instead of a differences package.
https://onedigi.atlassian.net/browse/DEL-8624
Signed-off-by: David Escalona <david.escalona@digi.com>
Arturo Buzarra
Hector Palacios
Javier Viguera
Gabriel Valcazar
Francisco Gil
Gonzalo Ruiz
Mike Engel
David Escalona