Moving from AMD Software Stacks to Production Deployment

Warning

AMD is a hardware vendor, not an Operating System Vendor (OSV). AMD does not provide production-grade software, Long Term Support (LTS), compliance attestations, or SLA-backed software updates for any AMD Adaptive SoC product family (Versal, Zynq UltraScale+, Zynq-7000).

Hardware product lifetime commitments do not imply software support commitments. Contact your AMD representative for product-specific software support information.

It is the responsibility of the end product manufacturer to ensure they meet the security and update standards required for their target marketplace and product.

Introduction

The AMD Embedded Development Framework and the images based on it are designed for technology evaluation and prototyping and do not provide the security update mechanisms required for a secure solution in production environments. The EDF image displays the following message at login:

WARNING: Embedded Development Framework is a reference Yocto Project
distribution that intended for testing and development purposes only.

For more detail, see AMD Embedded Development Framework (EDF).

When moving from prototype to production, you need to ensure that you meet the requirements of your application. This might include a comprehensive software update plan to respond to and resolve critical vulnerabilities throughout the lifetime of your product, redundancy mechanisms, or image encryption. The EDF reference image and AMD’s release process do not provide the following:

  • A maintained update feed or service. The EDF image ships with a package manager, but AMD does not operate an update feed against which it can be used in production. Yocto documents runtime package management in Using Runtime Package Management; whole-rootfs update is served by community projects such as OSTree, RAUC, Mender, and swupdate, each of which ships its own Yocto layer.

  • Rapid-response CVE scanning at build time. This is covered by the Yocto Project Security Manual.

  • Cryptographic boot validation and key revocation, available through U-Boot verified boot, OP-TEE, and meta-secure-core. AMD’s support for these integrations varies by hardware generation, and the degree of integration in the EDF reference design may be limited. For Adaptive SoC products, secure and authenticated boot needs additional hardware-specific configuration. Current guidance is in AMD’s device-specific application notes; contact your AMD representative for the resources that apply to your device.

  • Kernel Long Term Support (LTS) fixes beyond the upstream support window — this is a genuine commercial differentiator and is not available from upstream Yocto or the kernel community alone.

AMD provides current software based on a recent Yocto release; however, AMD’s release process delivers this only through new installations of the image or Yocto layers, as full images rather than incremental software updates.

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 introduces some of these options so that an informed decision can be made regarding production updates.

AMD Linux Kernel Sources and Branch Policy

AMD contributes as directly as possible to the upstream Linux kernel, but some code cannot be upstreamed for technical or business reasons. For these patches, AMD maintains a public fork of the Linux kernel at github.com/Xilinx/linux-xlnx.

This fork is a source repository, not a supported OS product. AMD is not an Operating System Vendor (OSV) and does not provide guarantees about when or how its kernel branches receive security patches or bug fixes. Customers who need those guarantees should work with an OSV.

Kernel Version Cadence

AMD aligns its kernel to an upstream LTS release each year for its .1 release and uses the same kernel base for its .2 release. The base is always the latest LTS kernel selected by the upstream kernel maintainer at the time of AMD’s annual selection.

AMD kernel release alignment

AMD Release

Kernel Base

2022.1, 2022.2

5.15

2023.1, 2023.2

6.1

2024.1, 2024.2

6.6

2025.1, 2025.2

6.12

2026.1

6.18

Branch Types

The fork contains several branch types with different intended uses and support scopes.

linux-xlnx branch types

Branch

Intended use

xlnx_rebase_<version>

Clean-history branch: the upstream kernel with all AMD patches applied sequentially. Used by AMD and OSVs when moving AMD patches to a new kernel version.

xlnx_rebase_<version>_LTS

AMD’s active working branch for a given kernel release. Receives both AMD hardware and patch updates and semiannual pulls from upstream. Intended for customers or OSVs who are providing their own long-term support based on an AMD kernel.

xlnx_rebase_<version>_LTS_<AMD release>_update

Short-term critical bug and security fixes for a specific AMD release. Longer-term or SLA-level support cannot be provided through this branch. Do not base products that require ongoing security updates or long-term bug fixes on this branch.
Release cadence by branch type

Branch type

Cadence

xlnx_rebase_<version>, xlnx_rebase_<version>_LTS

Approximately every 6 months, aligned with AMD releases (April and October)

xlnx_rebase_<version>_LTS_<AMD release>_update

Approximately every 10th upstream patch level (x.y.zz)

For branch history diagrams and worked examples of how patches flow through these branches, see Branch Description and Policy for linux-xlnx.

Roll-Your-Own vs. Commercial Solutions

In broad terms, there are two categories of solution for Linux distributions. Both commonly use Yocto as a build foundation; the meaningful distinction is who carries the obligation for ongoing security maintenance, the product team itself or a commercial vendor under a support contract.

  • Self-maintained — The developer has ultimate flexibility of sources, and the responsibility for updating and maintaining security and bug fixes is bespoke. Self-maintained solutions can be serviced commercially as well as in-house. However, this is a custom, one-to-one solution.

  • Commercial distribution — With a commercial distribution, there is often 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.

Self-Maintained Solutions

A self-maintained 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. The best practice is to align with an LTS version of Linux and a Yocto LTS release, and to scan and update your sources periodically in response to vulnerabilities and bug fixes.

For the current Yocto LTS cadence and support windows, see the Yocto Project Release Process and Stable Release and LTS. For the Linux kernel LTS schedule, see kernel.org releases.

Yocto-Based Self-Maintained

The AMD Yocto distribution is an example of a baseline structure suitable to be adapted to a custom self-maintained 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, ensuring quick coverage of new technologies prior to wider upstream rollout.

That customization carries an obligation. Customers moving to a self-maintained or commercially supported distribution need to assess which elements of the AMD kernel delta their hardware requires, and plan to either carry that delta forward or work with their chosen vendor to incorporate it into the vendor’s kernel. AMD upstreams drivers to mainline where possible, but some customizations are hardware-specific and may not be candidates for mainline inclusion; carrying the AMD delta forward requires ongoing rebasing work as upstream stable fixes are applied. AMD publishes its kernel sources to assist with this transition.

Maintaining security in a Yocto-based distribution — periodically applying upstream kernel and Yocto branch fixes, backporting fixes after a branch leaves community maintenance, and upgrading to a newer supported release — is covered comprehensively by the Yocto Project. See the Yocto Project Release Process for how stable branches are maintained and the Security Manual for handling vulnerabilities.

Buildroot and Other Build Systems

Additional self-maintained build systems are also available, such as Buildroot, which can be adapted to consume either upstream or vendor-adapted kernel sources. It is the responsibility of the developer to understand the features and limitations of such systems and adapt accordingly.

Commercially Supported Solutions

Commercially supported solutions fall into two main sub-categories: a curated package-based distribution (usually a binary distribution) and a source-code build system with commercially supported update mechanisms, which can be incident-based or rolling-release. For a fuller list of vendors supporting AMD hardware, see Embedded Software Ecosystem and the Yocto Project member organizations. Some examples follow.

Certified Ubuntu

AMD works with Canonical to provide a path to Certified Ubuntu for use on our products. This solution has the benefit of close alignment between AMD and Canonical, and as such little work may be required to transition from an evaluation environment to a solution with long-term support from Canonical. ubuntu.com/download/amd

Wind River Linux

Wind River Linux uses a Yocto-based build system, and is a solution suitable for users looking to maintain their existing framework or build environment while moving over to long-term commercial support. Wind River Linux

Foundries.io

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. foundries.io

Vulnerability Resources

The following sections list a limited set of example tools and websites. The user is responsible for ensuring the applicability and timeliness of any resources that are relied upon.

Vulnerability Databases and Announcement Lists

  • A comprehensive database of Common Vulnerabilities and Exposures (CVEs) is available at cve.org

  • OpenCVE has a browsable database of CVEs and can filter for many open source software projects, and create customized email alerts. opencve.io

  • Linux kernel CVE announcements are published to the linux-cve-announce mailing list. For background on how kernel CVEs are assigned, see CVEs and Security bugs in the kernel documentation.

  • The Yocto Project maintains a yocto-security mailing list for security discussion.

Vulnerability Scanning Tools

The following tools can help identify known vulnerabilities in your software stack.

Yocto Project Built-in Tools

Commercial Scanning Tools for Yocto

  • Lynx Vigiles (formerly Timesys Vigiles) is a commercial service that extends Yocto’s built-in SBOM and CVE scanning with managed alerting and support. More details can be found at Lynx Vigiles