PetaLinux-based images are designed for technology evaluation and prototyping and do not provide the security update mechanisms required for a secure solution in production environments. When running a PetaLinux-built image built from 2024.1 onwards, you will see the following banner:
“The PetaLinux source code and images provided/generated are for demonstration purposes only”
When moving from prototype to production, you need to ensure that you have a comprehensive software update plan in place to respond to and resolve critical vulnerabilities throughout the lifetime of your product in a timely manner. PetaLinux build outputs do not provide some of the update features that are available from a commercially supported Linux distributions such as:
A package manager with live updates for security vulnerabilities in user space applications and libraries or an update mechanism to push out new root file systems
Rapid response CVE fixes for critical Linux kernel vulnerabilities including 0-day vulnerabilities
Support for kernel LTS fixes outside the upstream support window
Cryptographic boot validation and key revocation for boot runtime and file system
AMD provide current software based on a recent Yocto release, however this is only updated through new installations of the PetaLinux tool and Yocto libraries, which are provided in the .1 and .2 releases each year. There are generally no releases outside of this cadence.
It is the responsibility of the end product manufacturer to ensure they meet the security and update standards necessary for the target marketplace and product.
A number of options are available to provide a fully featured solution depending on the end use case and requirements for your product. This page is intended to introduce some of these options to the reader, such that this can be looked at in more detail and an informed decision can be made regarding production updates.
Roll-your-own vs Commercial Solutions
In broad terms, there are two categories of solution for Linux distributions:
Roll-your-own - The developer has ultimate flexibility of sources and the responsibility for updating and maintaining security and bug fixes is bespoke. Roll-your-own solutions can still be maintained commercially as well as in-house. However this would be a custom 1:1 solution.
Commercial Distribution - Often with a commercial distribution, there is less flexibility in using custom sources (for the kernel and OS filesystem), however the response to security and bug updates is centralized. Service level agreements might be in place to guarantee response times to urgent vulnerabilities, and some OS vendors work with communities to provide updates immediately after vulnerability disclosure, in some cases by working on patches prior to disclosure.
A self-maintained roll-your-own distribution requires a bespoke update strategy, and is suitable for developers who are experienced with keeping up to speed with industry alerts for vulnerabilities, or are familiar with merging and testing updates from upstream sources. Generally the maintenance will be based on aligning with a Long Term Support (LTS) version of Linux (currently on a 2 year community support cycle) and Yocto LTS (currently on a 4 years+ community support cycle) and periodically scanning and updating their sources in response to vulnerabilities and bug fixes.
The AMD Yocto distribution is an example of a baseline structure suitable to be adapted to a custom roll-your-own distribution, appending custom package combinations and sources on top of the Yocto community-provided layers. The Linux kernel consumed by AMD Yocto layers is customized to enable new product features, and not-yet-upstream drivers to ensure quick coverage of new technologies prior to wider upstream rollout. In order to maintain security, upstream fixes in the kernel.org LTS source tree and Yocto project branch for the specific release used must be periodically applied. Once a Linux kernel or Yocto branch is no longer community-maintained, bespoke engineering effort to backport fixes (commercial or in-house) will be required. Alternatively, after a Yocto branch or Linux kernel LTS is out of maintenance, and update can be applied to update to the latest supported version.
Buildroot and Other Build Systems
Additional roll-your-own build systems are also available, such as Buildroot, which can be adapted to consume either upstream or vendor-adapted kernel sources. Some build systems will leverage update strategies, and others will be static or stale. It is the responsibility of the developer to understand the features and the limitations of such and adapt accordingly.
AMD work closely with Canonical to provide a path to Certified Ubuntu for use on our products. This solution has the benefit of being closely aligned between AMD and Canonical, and as such little work is required to transition from an evaluation environment to a solution supported by Canonical for long term support. https://ubuntu.com/download/amd
Foundries provide an environment to automate over-the-air updates for bespoke Linux packages, and allow their customers to bring in their Yocto-based projects and adapt them to a centrally-managed and maintained solution suitable for a production environment. https://foundries.io/
Vulnerability Scanning Tools and Alerts
Detailed below are of a limited set of tools and websites that are being provided as an example. The user is responsible for ensuring the applicability and timeliness of any resources that are relied upon.
Industry and Specialist News Websites and Podcasts
A comprehensive database of Common Vulnerabilities and Exposures (CVEs) is available at https://www.cve.org/
OpenCVE has a browsable database of CVEs and can filter for many open source software projects, and create customized email alerts. https://www.opencve.io/