Skip to main content
Emmanuel COMBETTE DE RYMON
Emmanuel COMBETTE DE RYMON
ST Employee
September 14, 2021

FAQ: Updating OpenSTLinux

  • September 14, 2021
  • 0 replies
  • 10316 views

Purpose

 

Guidelines that may assist you in your decision-making process

  • What is an OpenSTLinux release ?
  • Should we move to the next version of OpenSTLinux

General information about OpenSTLinux release

  • Information on firmware update and System recovery mechanisms
  • How to monitor CVE patches

 

1/ OpenSTLinux release and ST flow

 

OpenSTLinux release is a set of software components called the Board Support Package (BSP), which includes the boot chain components and the Linux kernel, and the root file systems with a collection of user-space applications from the Yocto Project. This is part of the ecosystem delivery that includes tools and extra frmware 

The OpenSTLinux release flows  follows Yocto Project long-term support (LTS) deliveries.
A new Yocto version is delivered each year:
https://wiki.yoctoproject.org/wiki/Releases

Two different kernel versions are delivered by the Yocto Project:

  • An LTS kernel version is delivered every two years, and the Yocto Project provides maintenance for two years.
  • A non-LTS kernel version is delivered every two years, and the Yocto Project provides maintenance for seven months.

The Yocto Project LTS versions are based on the LTS kernel version.

Each year, STMicroelectronics delivers a new major OpenSTLinux x.0 release based on a long-term support (LTS) version of the Yocto Project. Based on the same Yocto Project release, two subsequent releases follow: OpenSTLinux x.1.1 after eight months and OpenSTLinux x.2.0 eight months later. This period lasts 1.5 years. A wiki is dedicated to each release.

Then, minor x.2.z releases are delivered on GitHub for 2.5 years without a wiki.

Releases might then be delivered for one year in the event of a vulnerability.

The table below provides the version history for the different releases and their major software component versions: Wiki archives - stm32mpu

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 to the release, see the release notes: https://wiki.st.com/stm32mpu/wiki/STM32_MPU_OpenSTLinux_release_note#Release_changes_notification

For Minor deliveries, available on GitHub:

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)

To get a Linux Machine to rebuild the latest release of the OpenSTlinux BSP sources code,  see STM32MPUs-LinuxMachine-SDK-Setup


2/ ST Responsibility

 

STMicroelectronics is responsible for the board support package (BSP) components and provides delivery support for five years: 1.5 years for new features, 2.5 years for corrections, and 1 year for vulnerabilities.

Userland components are provided as examples.

For security Common Vulnerabilities and Exposures (CVE) patches for the components, the OpenSTLinux release includes the patches that are available when the release is issued. It does not consolidate any patches after the release. This task is the customer's responsibility or can be handled by an ST partner such as TimeSys.

 

3/ Mixing the OpenSTLinux components

 

An OpenSTLinux_BSP release is a set of components: TF-A, U-Boot, OP-TEE, and the Linux kernel.

The Linux kernel and U-Boot depend on OP-TEE and TF-A services, so the aligned versions in the delivery must be used. The versions are described in the release notes.

! Components from one release cannot be mixed with components from another release !


4/ Move to the next version of OpenSTLinux

Consider the following questions below when you want to update to a new release:

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. The product device tree of each software components of the OpenSTLinux_BSP (Board Support Package) might need to be re-adapted.

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 X.0

It is advised to stay on this same version x.y and take if possible the latest release x.y 
It is not recommended to switch to the next release of OpenSTLinux x+1.y (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 x.1 is more mature than release x.0 (with half a year of experience).. 
It is better to switch directly from version x.1 to version x+1.1 instead of version x.0.
 

If you are in the board bring up phase

it may be easier to use a previous more mature release.
As an example use x.1 instead of x+1.0 just for the bring up phase (unless you have good reasons for using x+1.0.)

We recommend the following articles: 

https://community.st.com/t5/stm32-mpus/faq-stm32mp1-how-to-create-a-device-tree-adapted-to-your-design/ta-p/49260
 

5/ Firmware update & System recovery mechanisms

 

  • About Firmware update:

    OpenSTLinux offers the firmware over-the-air (OTA) update feature for the boot chain except for TF-A BL2 (FSBL).

    The fip-boot partition, which contains BL31 for STM32MP2, OP-TEE, and U-Boot, can be updated. The firmware update is based on A/B partitions. For this the flash mapping contains the “metadata” partition for the controls of the switch mechanism between partition A (boot chain A) and partition B (boot chain B), see STM32 MPU flash mapping - stm32mpu

    During the firmware update phase only, the system checks that the new boot chain boots correctly before it switches to the new partition. Otherwise, the boot remains on the previous boot chain.

    Information is available at https://wiki.st.com/stm32mpu/wiki/Secure_Firmware_Update.

  • About System recovery:
    The System recovery feature that boots the kernel from initramfs in case of boot the kernel  fails to boot from flash partition is not present by default in OpenSTlinux release
     

As already mentioned, partitions of the same bootchain must be aligned on the same release: TF-A, U-boot, OP-TEE, and kernel.

A partner foundries.io implements firmware update with STM32MP series
Incremental Kernel & Docker App OTA Updates | Foundries.io


6/ Security vulnerability Incident 


Customer can report vulnerability on ST hardware or software ST provide security advisories and security notes on each product page (hardware or software) and also on our Product Security Incident Response Team (PSIRT) page.

Each component release has a list of CVE. STMicroelectronics does not consolidate these lists but they are public by the software providers. Third-party providers such as TimeSys can consolidate patches.

The CVE monitoring process is done by the U-boot, TF-A and OP-TEE communities, they are described here:

TF-A:

OP-TEE:

For products using OP-TEE 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)

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

 

    This topic has been closed for replies.
    Terms & ConditionsAccessibility statement