STM32MP1 OpenSTLinux release update

[Marie-Christine CAYALE]

Contents: 

• Which OpenSTLinux release should be used?
  
• Should we move to the next version of OpenSTLinux?
  
• Information on firmware update support
• How to monitor patches

Guidelines that may assist you in your decision-making process

STMicroelectronics OpenSTLinux follows Yocto deliveries;
A new yocto version is delivered each year:
https://wiki.yoctoproject.org/wiki/Releases

Two different kernel versions are delivered by Yocto

• An LTS kernel version: Every two years and provide maintenance for two years.
  
• A Non-LTS kernel version: Every two years and provide maintenance for seven months.

Each year STMicroelectronics delivers a new major OpenSTLinux x.0, followed six months later by OpenSTLinux x.1 based on the same Yocto release.
Then minor releases x.y.z are delivered under GitHub.

STMicroelectronics is responsible for the BSP components and provides support on deliveries for two years.
Userland components are delivered as examples.

Regarding security CVE patches for the components, the OpenSTLinux release takes the ones available when doing the release. It does not do the consolidation of a patch after the release. This is on your side (or with an STMicroelectronics partner like TimeSys).

• The next Non-LTS OpenSTLinux release will be OpenSTLinux 5.1 in June 2024, still based on Yocto Mickledore
• The next LTS OpenSTLinux release based on LTS Yocto release will be OpenSTLinux 6.0 in October 2024 based on Yocto LTS Scarthgap
• If you need the LTS kernel version, it is easier to migrate to this version if you are already taking OpenSTLinux5.x
  
  

For the contents of the OpenSTLinux release, see the release note below:
https://wiki.st.com/stm32mpu/wiki/STM32_MPU_OpenSTLinux_release_note

For changes on the release, see the release notes below with an example of OpenSTLinux 4.0. 
https://wiki.st.com/stm32mpu/wiki/STM32_MPU_OpenSTLinux_release_note_-_v4.0.0/Changes_notification_%E2%80%93_v4.0.0

A release is a set of components: tf-a, u-boot, optee, and kernel. 
The kernel is depending on optee services so you need to have aligned versions.
The versions are described in the release notes.
Note: You cannot mix components from a release to another release.

Consider the following questions below when you want to update to a new release:
The example below in this case is described with OpenSTLinux 2.x and OpenSTLinux 3.x.

Is updating to a new release really needed?

Moving to a new major release on the customer side can require a large effort. It has to be evaluated and anticipated.

Is a version update really necessary for your product? 

It depends how the board design is different from a STMicroelectronics reference board. Furthermore, consider the differences on a given OpenSTLinux release (BSP configuration differences, Yocto updates from a previous release).
   

If you are close to production with OpenSTLinux 2.0

It is advised to stay on this same version 2.x and take if possible the latest release 2.x for example OpenSTLinux 2.1 (more stable than 2.0).
It is not recommended to switch to the next release of OpenSTLinux 3.x (unless you have good reasons for that).

If you really want to update your OpenSTLinux version

If you want to update your OpenSTLinux version, release 3.1 is always more stable than release 3.0. 
It is better to switch directly from version 2.1 to version 3.1 instead of version 3.0.

If you are in the board bring up phase

If you are in the board bring up phase, it may be easier to use a previous stable release.
As an example use 2.1 instead of 3.0 just for the bring up phase (unless you have good reasons for using 3.0.)

We recommend the following articles: 

• https://community.st.com/t5/stm32-mpus/faq-stm32mp1-how-to-bring-up-stm32mp1/ta-p/49280
  
• https://community.st.com/t5/stm32-mpus/stm32mp1-bring-up-troubleshooting-guide/ta-p/49272
• https://community.st.com/t5/stm32-mpus/faq-stm32mp1-how-to-create-a-device-tree-adapted-to-your-design/ta-p/49260

The main reasons for these proposals are: 2.x and 3.x have the same stability on a STMicroelectronics board (same test plan and pass criteria).
However, the integration on the customer side will usually be more mature on a X.1 release (with half a year of experience).

Firmware update

Since OpenSTLinux4.0 firmware update is supported
Information is available in https://wiki.st.com/stm32mpu/wiki/Secure_Firmware_Update

To summarize:

A firmware update is possible for the bootchain except TF-A bl2 (fsbl).
The fip partition of the boot chain containing u-boot and optee can be updated.

OTA update is based on A/B partitions: STM32 MPU flash mapping - stm32mpu
This flash mapping is used for a firmware update feature from a version to another version.
The mechanism to switch between partitions A (boot chain A) and partitions B (boot chain B) is done thanks to the metadata partition.
During the firmware update phase only, check that a new boot chain is correctly booting before switching to a new partition, otherwise the boot remains on the previous boot chain. 
Be careful as you may need to have another mechanism to handle the system recovery feature (like initramfs), in case of boot failures in normal boot mode.

As already mentioned, partitions of the same bootchain must be aligned on the same release: tf-a, u-boot, optee, and kernel.

A partner who already implements firmware update with STM32MP1 is foundries.io
Incremental Kernel & Docker App OTA Updates | Foundries.io

Monitoring and consolidating patches

You can monitor the continuously updated patches in the ST GitHub (links provided below.)

• STMicroelectronics/STM32MPU_EmbSW_Overall_Offer: STM32MPU_EmbSW_Overall_Offer
  Practical examples: 
• STMicroelectronics/arm-trusted-firmware: Arm trusted firmware
• STMicroelectronics/u-boot: "Das U-Boot" source tree
• STMicroelectronics/linux: Linux kernel source tree

STMicroelectronics/optee_os: Trusted side of the TEE (github.com)

Each component release has a list of CVE. ST does not consolidate these lists but they are public by the software providers.

The CVE monitoring process is done by the uboot, tf-a and optee communities, they are described here:

TF-A:

• https://trustedfirmware-a.readthedocs.io/en/latest/process/security.html
• https://www.cvedetails.com/vulnerability-list/vendor_id-16302/Arm-Trusted-Firmware-Project.html

Optee:

• https://www.op-tee.org/security-advisories/
• https://developer.trustedfirmware.org/w/collaboration/security_center/

For products using optee your company can register as a "Trusted Stakeholder" to be aware on vulnerabilities and corrections before they are published.
https://developer.trustedfirmware.org/w/collaboration/security_center/trusted_stakeholder_registration/

See the link below for a list of published vulnerabilities:
https://github.com/OP-TEE/optee_os/security/advisories?state=published

U-boot: (Example for version 2020.01)

• https://www.cvedetails.com/product/48033/Denx-U-boot.html?vendor_id=18843
• https://repology.org/project/u-boot/cves?version=2020.01

Linux kernel: The CVE list is available with an example for kernel 5.15

• https://www.kernel.org/doc/html/v5.15/admin-guide/security-bugs.html?highlight=cve
• https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33

You can work with third parties (like TimeSys) for consolidating patches.