Sick Gaming - Linux, BSD & Unix

[Ubuntu News] php2shell (CVE-2026-109618 and CVE-2026-109619) – PHP critical vulnerab

Wed, 21 Oct 2026 12:43:48 -0200

Introduction

Two critical security vulnerabilities affecting PHP have been identified that result in unauthenticated remote code execution (RCE) for any PHP application. The vulnerabilities have been assigned the CVE-2026-109618 and CVE-2026-109619 identifiers, but are also referred to using the php2shell nickname. Ubuntu has released fixes for the affected packages for all supported releases.

The two vulnerabilities both have a CVSS 4.0 score of 9.2, corresponding to a severity of CRITICAL.

The vulnerabilities have been responsibly disclosed and the PHP Foundation has engaged in coordinated vulnerability disclosure (CVD) with distributors, establishing a public disclosure date of 22 October 2026 at 14:00 UTC. However, due to a public leak, the disclosure date has been moved forward to 21 October 2026 14:00 UTC.

Which Ubuntu releases are affected by php2shell?

ReleasePackage NameRemediation statusTrusty (14.04)php5Fixed in 5.5.9+dfsg-1ubuntu4.29+esm18Xenial (16.04)php7.0Fixed in 7.0.33-0ubuntu0.16.04.16+esm22Bionic (18.04)php7.2Fixed in 7.2.24-0ubuntu0.18.04.17+esm14Focal (20.04)php7.4Fixed in 7.4.3-4ubuntu2.29+esm5Jammy (22.04)php8.1Fixed in 8.1.2-1ubuntu2.28Noble (24.04)php8.3Fixed in 8.3.6-0ubuntu0.24.04.13Resolute (26.04)php8.5Fixed in 8.5.4-0ubuntu1.5Stonking (26.10)php8.5Fixed in 8.5.9-0ubuntu2.1
How to check if you are impacted by php2shell

You can verify the versions of any packages installed matching the PHP interpreter package name with the following command:

Code:
apt list '?installed ?name(^php[0-9.]+$)'

Impact of php2shell

The two vulnerabilities affect any PHP application. An unauthenticated attacker with network access to the web application can trivially achieve arbitrary remote code execution with the PHP application’s credentials on the target system.

How to apply fixes for php2shell

We recommend you upgrade all packages:

Code:
sudo apt update && sudo apt upgrade

If this is not possible, the affected component can be targeted:

Code:
sudo apt update && sudo apt install --only-upgrade '?name(^php[0-9.]+$)'

The application that uses the PHP interpreter would likely need to be restarted. For example, for an application using apache2 with mod_php, restarting the apache daemon is required:

Code:
sudo systemctl restart apache2

Alternatively, the system can be rebooted to ensure that all applications use the updated components:

Code:
sudo reboot

The unattended-upgrades feature is enabled by default for Ubuntu 16.04 LTS onwards. This feature:

Applies new security updates every 24 hours automatically.
If you have this enabled, the patches above will be automatically applied within 24 hours of being available, but the affected applications would still need to be restarted or the system rebooted.

[Ubuntu News] eMudhra CA compromise fixes available

Tue, 20 Oct 2026 21:45:09 -0200

Introduction

The private keys of the eMudhra Certificate Authority (CA) have been demonstrated on 20 October 2026 to have been compromised. The Ubuntu Security Team has released updates to the system PKI (Public Key Infrastructure) root CA store in the ca-certificates package.

While the eMudhra CA is not directly trusted as a root on Ubuntu, two other root CAs have cross-signed the eMudhra CA: emSign Root TLS CA – G3 and Comodo AAA Certificate Services. These two roots have been removed from the Ubuntu trusted root store in the ca-certificates package to ensure that the compromised eMudhra CA is no longer trusted. Any legitimate certificate which is ultimately trusted by either of these two root CAs would no longer be trusted. It is unlikely, but this may result in some hosts being unreachable, due to their use of the revoked certificate. The AAA Certificate Services CA had previously been removed from the CA bundles in Ubuntu 22.04 (Jammy Jellyfish) and newer releases.

Which Ubuntu releases are affected?

ReleasePackage NameRemediation statusTrusty (14.04)ca-certificatesFixed in 20230311~14.04.1~esm3Xenial (16.04)ca-certificatesFixed in 202402031~16.04.1~esm3Bionic (18.04)ca-certificatesFixed in 202402031ubuntu0.18.04.1+esm3Focal (20.04)ca-certificatesFixed in 20240203~20.04.1ubuntu0.1~esm2Jammy (22.04)ca-certificatesFixed in 20260816ubuntu0.22.04.1Noble (24.04)ca-certificatesFixed in 20260816ubuntu0.24.04.1Resolute (26.04)ca-certificatesFixed in 20260816ubuntu0.26.04.1Stonking (26.10)ca-certificatesFixed in 20260816ubuntu0.26.10.1

How to check if you are impacted

You can verify the version of the ca-certificates package with the following command:

Code:
dpkg -l 'ca-certificates' | grep ^ii

Impact of the CA Compromise

An unauthorized third party would be able to sign fraudulent X.509 certificates; these would pass validation by a TLS implementation (commonly TLS clients) that trusts the eMudhra CA. Mitigations such as public key pinning or DNS Certificate Authority Authorization (CAA) records do provide the ability to detect such fraudulent certificates, but depend on the TLS application making use of the mitigations and are not widely used.

This could lead to the identity impersonation of a TLS endpoint and could allow an attacker-in-the-middle to intercept and compromise the confidentiality and integrity of TLS connections, irrespective of the CA that the authentic TLS endpoint uses, unless mitigations are employed.

How to apply fixes

We recommend you upgrade all packages:

Code:
sudo apt update && sudo apt upgrade

If this is not possible, the affected component can be targeted:

Code:
sudo apt update && sudo apt install --only-upgrade ca-certificates

The unattended-upgrades feature is enabled by default for Ubuntu 16.04 LTS onwards. This feature:

Applies new security updates every 24 hours automatically.
If you have this enabled, the patches above will be automatically applied within 24 hours of being available.

Ubuntu 26.10, 26.04 LTS, 24.04 LTS, and 22.04 LTS receive these fixes as part of standard support. If you are using Ubuntu 20.04 LTS or older, you can apply this fix with an Ubuntu Pro subscription via the Expanded Security Maintenance (ESM) service. Ubuntu Pro is free for up to 5 machines, or up to 50 machines for community members. Ubuntu Pro also provides access to Landscape which enables you to control the roll-out of security fixes across your estate. Learn more.

Note for Ubuntu Desktop users

On Ubuntu Desktop, the most common TLS client would be a browser. They are typically installed as snap packages on Ubuntu desktop, and do not use the system trust store provided by the ca-certificates package. Snap packages are refreshed four times a day by default. If you have disabled automatic updates, ensure that you refresh your snaps manually.

References

[Ubuntu News] How to lower Android™ development costs by removing hardware from the c

Fri, 16 Oct 2026 07:50:26 -0200

As an Android developer, you’ll almost always have access to a device. However, when handling hardware, the device that you actually need often happens to be already in use, set up incorrectly, stored in another lab, or simply waiting to be reset. That’s when Android development costs start to increase.

Because it’s not just the device itself that generates expenses, it’s everything around it: procurement, provisioning, maintenance, remote access, lab capacity, and, worst of all: your engineering time. A developer waiting for the right dev environment still constitutes a cost.

So, how can you solve that problem?

Do my tests actually need hardware?

We all know that hardware still plays a big role in Android development. If you need to validate sensors, peripherals, real target performance, the hardware integration itself, or even the genuine user experience, you’re going to need the physical target device.

But most workloads competing for those devices can run elsewhere.

When building Android, testing an application, reproducing a bug, or even running regression tests, there’s absolutely no need for any physical device. So instead of asking yourself if a specific target device is available, the question you should ask is whether you need a device at all.

The distinction is important here, because hardware labs are obviously much harder to scale than software.

More developers often means more builds, more tests, and more configurations. That typically means a higher need for devices, benches, and more infrastructure to have enough capacity for peak times when relying on hardware-first. As you can see, Android development costs aren’t only a result of the gear itself, but the effort to run it, and the engineering time lost when access becomes a bottleneck.

Android infrastructure operations

When moving workloads away from hardware, Android environments can then be provisioned when needed, integrated into Continuous Integration and Continuous Delivery/Deployment (CI/CD) pipelines, run in parallel, and discarded afterwards. A cloud-first approach is much simpler than a hardware one. Just request your environment, run your tests, and safely release it.

The secret trick is to be wise when choosing the appropriate execution environment for the job you want to run: use containers when you need app density and scale, virtual machines if you need to run a custom Android image, and physical devices for when the tests truly depend on physical components.

With Anbox Cloud, these cloud environments can co-exist in exactly the same development workflow. Developers can continue using familiar tools such as Android Debug Bridge (ADB), Android Studio, their existing test frameworks, and usual CI/CD systems.

Let’s take the example of a support or validation team that needs to reproduce issues across many Android configurations. In a hardware-first setup, that means finding the right device, checking its software version, reserving it, reconfiguring it, and setting up remote access before debugging even starts.

With cloud-based Android environments, the same team can keep predefined images for common configurations and start them on demand. Several engineers can work in parallel, while physical devices are reserved for cases that truly require hardware validation.

In this instance, costs are lowered not simply because there is one less phone on a shelf. It is the time spent finding, preparing, and sharing that phone and the extra capacity required to make sure one is available when demand peaks. A device sitting idle is inefficient. An engineer sitting idle because the right device isn’t available is even more expensive.

Where Android development costs actually come from, and how to reduce your expenses

Generally, there are three cost areas worth looking at: the first obvious cost is hardware, then operations (setup, maintenance, and so on), and, last but not least: engineering time. The impact of that last element is easy to underestimate.

If fewer workloads depend on dedicated devices, teams need less hardware capacity to support the same level of development activity. Here is how using Anbox Cloud helps you to improve these three cost areas:

Hardware cost: fewer devices, benches, and supporting infrastructure need to be provisioned for peak demand
Operational cost: less manual setup, maintenance, and environment management
Engineering-time cost: less waiting for shared resources and more opportunities to run workloads in parallel

If ten tests need to run, they should not necessarily queue behind the same physical bench. If an issue needs to be reproduced, an engineer should not have to spend time rebuilding the right configuration manually. Software-defined environments can be created specifically for the workload and removed afterwards.

That also means that the customized hardware you do have can then be reserved for the tests that can’t do without it. Reducing Android development cost therefore becomes more than reducing hardware spending. It becomes a way to get more engineering work from the infrastructure, as well as getting back the engineering time you already have.

Take hardware out of the critical path

As I like to say, the point here is not to completely get rid of physical devices. The goal is to make sure to only use your expensive hardware because the test requires it, not because the workflow was built around it.

That means running software-driven workloads early, running more of them in parallel, and keeping those physical benches for the validation or certification work where they provide actual value.

Instead of scaling Android development by continuously adding devices, scale the environments around them. Less wait, more scaling, faster iterations.

Stop running after devices. Run Android in the cloud.

Further reading

Learn more about Anbox Cloud or contact our team to discuss your use case

Android is a trademark of Google LLC.

Anbox Cloud uses assets available through the Android Open Source Project.

The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in theCreative Commons 3.0 Attribution License.

[Ubuntu News] Canonical releases Ubuntu 26.10 Stonking Stingray

Thu, 15 Oct 2026 10:16:02 -0200

The latest interim release of Ubuntu previews privacy conscious speech-to-text, enables post-quantum package signing, completes the rollout of Rust coreutils, and improves enterprise identity integration.

October 15, 2026

Today Canonical announced the release of Ubuntu 26.10, codenamed “Stonking Stingray,” available to download and install from ubuntu.com/download.

Building on previous releases, Ubuntu 26.10 advances enterprise security features, completes the rollout of the Rust-based

Code:
uutils coreutils

, and strengthens integrations for user authentication using Microsoft Entra ID. Ubuntu 26.10 also introduces post-quantum package signing, demonstrating that interim releases both build on established ground, and look towards the future.

Quote:Earlier this year, we set out a roadmap for AI on Ubuntu. Stonking Stingray delivers the first milestone through the integration of Myna: a speech-to-text agent that utilizes on-device LLMs. We’ve led Ubuntu’s first AI integration with accessibility to ensure that cutting-edge features are available to all users from day one.

Users will also benefit from enhanced security features. Ubuntu 26.10 completes the migration to Rust-based coreutils, and broadens device support for TPM-backed FDE. Stonking Stingray is symbolic of Ubuntu’s journey to not just build up, but also build out.

Jon Seager, VP of Ubuntu Engineering at Canonical

Download Ubuntu 26.10 for free
Register for Ubuntu Summit 26.10 ›

Elegance and accessibility with new speech-to-text agent

Stonking Stingray brings us the debut of Myna: Ubuntu’s speech-to-text agent. Named after the Myna bird (known for its ability to mimic human speech), Myna is an opt-in feature in Ubuntu 26.10, designed to provide speech recognition with clear visual feedback while you speak. Based on local models, Myna offers speech-to-text, without sacrificing privacy. Myna will continue to evolve and as Ubuntu 28.04 LTS approaches, it will be included by default with Ubuntu.

Myna marks the first step towards a more natural, intent-driven Ubuntu Desktop experience that will enable users to express what they want to achieve, rather than manually navigate applications and settings. For example, a developer could simply say, “Help me investigate why my tests are failing,” and Ubuntu could analyze test results, locate relevant code, and prepare a workspace with the tools and information needed to troubleshoot the issue.

Ubuntu 26.10 also ships with GNOME 51, bringing a smoother, more responsive desktop, better display handling, improved accessibility, and refinements across core applications. In addition, the Ubuntu App Center now provides a more consistent experience for managing snaps and debs.

Users of assistive technology will benefit from improved support for Flutter applications, with assistive technologies like Orca (screen-reader) now able to better parse and understand the content included in Flutter applications.

This release also brings reliability enhancements to the desktop userspace layers. Ubuntu 26.10 adopts dbus-broker as the default D-Bus implementation, replacing legacy message queuing between apps with strict per-app message accounting, ensuring a single app can’t stall the desktop. Additionally, desktop OOM (out-of-memory protection) scoring has been adjusted to better manage–memory pressure in userspace.

Security for present and future threats

Ubuntu Desktop now integrates more naturally with Microsoft identity services, including password with Multi-Factor Authentication (MFA), and passwordless authentication. This ensures devices can authenticate securely by default, and under the same security umbrella as Windows devices in the same organization.

TPM-backed full-disk encryption, which was rolled out in Ubuntu 26.04 LTS, has been expanded to encompass hardware models lacking a Hardware Root of Trust, with users being able to require a PIN or passphrase. These features ensure that users can use Ubuntu with best practice security enabled by default.

Ubuntu 26.10 delivers post-quantum ready package signing, by replacing GnuPG with Sequoia PGP to verify APT repository signatures. Sequoia brings Rust’s memory-safe practices to package signing and acts as a barrier to the threat of quantum cryptographic attack attempts. Ubuntu 26.10 introduces quantum-safe token support via openCryptoki, providing robust PKCS #11 V3.2 coverage across multiple token types, including Soft, EP11, and CCA tokens with ML-DSA and ML-KEM integration.

A new kernel. The latest hardware.

Ubuntu 26.10 brings Linux kernel 7.3, which facilitates hardware enablement for the latest silicon, such as Intel Xe3P (Nova Lake), AMD Zen 6, and NVIDIA 615. As heterogeneous platforms like these span CPU cores, GPUs, and media decoders, the latest kernel brings the direct rendering management and power management hooks needed for these components to perform.

Kernel 7.3 also enhances the way data is handled at the software level, through out-of-the-box support for Lustre, a parallel distributed file system designed to transfer massive datasets simultaneously across thousands of corporate nodes.

Ubuntu 26.10 continues the tradition of delivering architecture-focused enhancements. Stonking Stingray will launch with a dedicated installer for amd64v3 hardware, ensuring that users with modern platforms get an optimized experience. For RISC-V users, Ubuntu 26.10 brings desktop images, complementing the work that had already been done to do so with Server images. This includes support for the first RVA23-enabled RISC-V hardware, the SpacemiT K3, ensuring that developers can meet the new standard with confidence on a stable OS. Together, these enhancements streamline setup for developers building on cutting-edge silicon.

Quote:2026 is the year of RVA23 silicon, so I’m thrilled to see desktop image support arrive for RISC-V in Ubuntu 26.10. It brings the power of the RVA23 profile to everyday applications including productivity, online meetings, video streaming and software development.

Andrea Gallo, CEO of RISC-V International

A speedy path to AI and software development

Beyond hardware enablement, Stonking Stingray also delivers enhanced support for running accelerated AI workloads. Ubuntu 26.04 LTS brought ROCm (AMD’s AI enablement stack for AMD hardware) into the Ubuntu archive. Ubuntu 26.10 upgrades that to the latest major version with support for ROCm 10.0. ROCm 10.0 adds support for new GPU architectures and serving frameworks like vLLM and SGLang.

Ubuntu 26.10 also distributes the latest developer toolchains from upstream, including LLVM 22.1.6, GCC 15.2.0, Python 3.14.7, Rust 1.97.1, Zig 0.16, and Go 1.27. Spring AI is also available on Ubuntu Desktop for the first time, through the devpack for Spring, a snap that bundles the latest features and versions of Spring. For those developing in Rust, Ubuntu 26.10 coincides with the release of the devpack for Rust, bringing a batteries-included setup experience complete with flexible version management and robust IDE support.

Get started today

Download Ubuntu 26.10 for free
Register for Ubuntu Summit 26.10 ›

About Canonical

Canonical, the publisher of Ubuntu, provides open source security, support and services. Our portfolio covers critical systems, from the smallest devices to the largest clouds, from the kernel to containers, from databases to AI. With customers that include top tech brands, emerging startups, governments and home users, Canonical delivers trusted open source for everyone.

Learn more at canonical.com

[Ubuntu News] Fixes available for CVE-2026-92392 and other curl vulnerabilities

Wed, 14 Oct 2026 14:48:02 -0200

Introduction

On 7 October 2026, Daniel Stenberg published a blog post describing a plan to release a new version of curl on 14 October 2026 in order to address 22 known security vulnerabilities. These vulnerabilities have varying severities, with a single vulnerability assessed as high (CVE-2026-92392), while the others have a low or medium severity. The curl maintainer has coordinated with downstream vendors, including Ubuntu, under embargo and the vulnerabilities have been publicly disclosed on the planned date. All operating systems that distribute curl are affected, including Linux distributions. Ubuntu has released updates that address all vulnerabilities for all affected releases: USN-8927-1 and USN-8932-1. CVE-2026-92392 only impacts Ubuntu 26.04 LTS (Resolute Raccoon).

The vulnerabilities do not have CVSS scores assigned. CVE-2026-92392 was assessed by the Ubuntu Security Team to have a CVSS 3.1 score of 8.1, corresponding to a severity of HIGH (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).

The vulnerabilities affect both the curl command-line utility and the libcurl library. The following are the identifiers associated with the vulnerabilities:

Which Ubuntu releases are affected?

ReleaseSource package nameRemediation statusTrusty (14.04)curlFixed in 7.35.0-1ubuntu2.20+esm24
Not affected by CVE-2026-92392Xenial (16.04)curlFixed in 7.47.0-1ubuntu2.19+esm21
Not affected by CVE-2026-92392Bionic (18.04)curlFixed in 7.58.0-2ubuntu3.24+esm15
Not affected by CVE-2026-92392Focal (20.04)curlFixed in 7.68.0-1ubuntu2.25+esm10
Not affected by CVE-2026-92392Jammy (22.04)curlFixed in 7.81.0-1ubuntu1.30
Not affected by CVE-2026-92392Noble (24.04)curlFixed in 8.5.0-2ubuntu10.16
Not affected by CVE-2026-92392Resolute (26.04)curlFixed in 8.18.0-1ubuntu2.8
Affected by CVE-2026-92392
How to check if you are impacted

You can verify the versions of any packages installed from the curl source package with the following command.

Code:
apt list '?installed ?source-package(^curl$)'

Impact of CVE-2026-92392

CVE-2026-92392 is known to allow remote code execution. Successful exploitation requires a malicious server, so this issue can be mitigated by only contacting trusted servers. The conditions required to reach and exploit this issue are complex.

Impact of the other vulnerabilities

CVE-2026-92388 is also a use-after-free vulnerability, the same class as CVE-2026-92392. This class of vulnerabilities is typically considered to lead to remote code execution in conservative assessments. However, CVE-2026-92388 does not affect the curl command-line utility and is only applicable if an application using the libcurl library uses the FTP functionality in a certain way. The vulnerability has therefore been assessed by the curl project with a low severity.

The other CVEs include leaking authentication credentials to incorrect connections through a variety of protocols and proxies (including Kerberos tickets); protocol state machine problems with TFTP and IMAP that could lead to denial-of-service or information disclosure issues; HTTP servers able to wipe or truncate cookie jars; HSTS expiration and durability issues; SSH host key checking issues; a data leak in the GnuTLS version; memory exhaustion leading to denial-of-service; two issues for TLS backends we do not support.

How to apply fixes

We recommend you upgrade all packages:

Code:
sudo apt update && sudo apt upgrade

If this is not possible, the affected component can be targeted:

Code:
sudo apt update && sudo apt install --only-upgrade '?source-package(^curl$)'

The unattended-upgrades feature is enabled by default for Ubuntu 16.04 LTS onwards. This service:

Applies new security updates every 24 hours automatically.
If you have this enabled, the patches above will be automatically applied within 24 hours of being available.

Ubuntu 26.04 LTS, 24.04 LTS, and 22.04 LTS receive these fixes as part of standard support. If you are using Ubuntu 20.04 LTS or older, you can apply this fix with an Ubuntu Pro subscription via the Expanded Security Maintenance (ESM) service. Ubuntu Pro is free for up to 5 machines, or up to 50 machines for community members. Ubuntu Pro also provides access to Landscape which enables you to control the roll-out of security fixes across your estate.

Learn more >

Further reading

[Ubuntu News] Myna speech-to-text is now available as a technology preview

Mon, 12 Oct 2026 14:44:43 -0200

A few months ago, we introduced Myna, our project to bring private, local speech-to-text dictation to Ubuntu Desktop. Named after the speech-mimicking myna bird, Myna is an optional Ubuntu 26.10 feature that offers real-time visual feedback during speech recognition.

Since then, Myna has grown into something you can install and use on your desktop.

Today, we’re making it available as a technology preview to the wider Ubuntu community. Whether you regularly rely upon speech-to-text dictation, or only use it for certain use cases, we want to hear your feedback.

Myna is still under active development, so you should expect some rough edges. The core experience is there: press a shortcut, speak, and Myna transcribes directly into the application you’re using.

Local speech-to-text

Speech recognition runs entirely on your machine. Once a model has been downloaded, no internet connection is required for transcription, and your audio is not uploaded or stored.

Myna supports several speech recognition engines, including Parakeet, Whisper, and FunASR, each with different trade-offs in language support, accuracy, and hardware requirements.

Trying Myna

Myna is currently available on Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, and Ubuntu 26.10, on amd64 and amd64v3, using GNOME on Wayland.

To install the preview, run:

Code:
sudo add-apt-repository ppa:canonical-desktop-team/myna

Code:
sudo apt install myna-config

Then open Myna settings from Activities and follow the setup.

If you have a supported NVIDIA GPU, Myna can also offer a GPU-accelerated engine. Support for additional accelerators is planned.

Once setup is complete, put the cursor in a text field, press the configured hotkey, and start talking.

What we’d like you to try

Use Myna with the applications you normally use, in your native language or any language with your natural accent.

We’re particularly interested in feedback on:

Transcription quality
Responsiveness
Language and accent support
Application compatibility
Setup and onboarding
Anything that feels awkward or unexpected

Different machines and microphones are useful too, as we want to understand how well the current models and defaults behave across a broad range of Ubuntu systems.

For now, Myna is deliberately focused on dictation. It is not a voice assistant and does not control the desktop through voice commands.

Get involved

Myna is developed in the open at github.com/canonical/myna.

You can:

If speech-to-text is something you rely on, we’re especially interested in hearing about your experience and what is still missing.

Thanks to everyone who has already tested Myna and shared feedback with us.

Share your feedback

[Ubuntu News] What’s new in security for Ubuntu 26.10?

Tue, 06 Oct 2026 12:19:19 -0200

Ubuntu 26.10 “Stonking Stingray” arrives at a time when AI tools are accelerating vulnerability discovery. Patching faster is essential, but the resilience of the underlying operating system must also limit what an attacker can achieve before a fix is available.

To respond to this new threat landscape, Ubuntu 26.10 continues the work of previous releases by reducing the code exposed to attack: replacing memory-unsafe implementations while preserving confinement as components change. Security doesn’t just relate to security features; it informs the approach we take wherever we innovate. Let’s take Myna, Ubuntu’s new desktop dictation feature. Its speech recognition runs locally through a sandboxed inference snap, so audio does not need to be sent to a cloud service for transcription.

In this blog, we’ll look through what’s changed in security for Ubuntu 26.10, the protection each change provides, and what you need to check before upgrading. Here’s a quick rundown if you want to find something specific:

A signed, slimmed down GRUB with a reduced attack surface
TPM-backed encryption on machines without a hardware root of trust
Core utilities that are now entirely in Rust
OpenSSL 4.0, OpenSSH 10.5 and certificate revocation with upki
dbus-broker as the default message bus, with AppArmor mediation intact
ntpd-rs, a memory-safe time daemon, available for testing
authd support for Microsoft MFA and identity-provider-based accounts, plus hardware-token VPN sign-in in NetworkManager
On-device speech recognition
Linux 7.3

A smaller Secure Boot path

GRUB is part of Ubuntu’s early boot chain. In the usual UEFI Secure Boot configuration, the firmware first loads shim, which then validates and loads GRUB. It contains parsers for filesystems, image formats, and partition layouts that, over the years, have been a steady source of Secure Boot bypass vulnerabilities.

In Ubuntu 26.10, signed GRUB builds retain only what Ubuntu needs to boot:

/boot on ext4, FAT, and ISO9660 remains supported, along with squashfs for snaps.
Filesystem drivers for Btrfs, HFS+, XFS, and ZFS have been removed from the signed build, as have JPEG and PNG image loading and Apple partition tables.
/boot on LVM, software RAID other than RAID1, and LUKS encryption are no longer supported under Secure Boot.

This reduces the potential attack surface during the boot sequence. These changes affect only the boot path, with LVM, RAID, LUKS, Btrfs, and ZFS continuing to work in the running system. The full feature set also remains available with Secure Boot disabled. Check any customized /boot layout against the supported list before upgrading.

Fewer parsers running before the kernel means fewer ways to break the chain of trust. We deliberately made this change directly after a long-term supported release (in this case, Ubuntu 26.04 LTS), so that anyone who depends on the removed features can stay on Ubuntu 26.04 LTS until May 2041 with Ubuntu Pro and the Legacy add-on.

Encrypting /boot alone does not authenticate its contents or establish a trusted boot chain. Ubuntu’s TPM-backed full disk encryption combines boot-chain protections with measured boot and a policy governing when the disk-unlocking key can be released. Let’s dive into that now.

TPM-backed encryption on more machines

TPM-backed full disk encryption protects data at rest and ties automatic disk unlocking to the system’s measured boot state. The TPM releases the disk-unlocking key only when those measurements satisfy the configured security policy. In Ubuntu 26.10, TPM-backed full disk encryption reaches systems without a hardware root of trust. Ubuntu cannot verify the firmware automatically on these machines, so they require a PIN or passphrase at installation.

Administrators can remove the PIN later. However, without it, the system is no longer protected against firmware tampering. Machines with a hardware root of trust, which covers most PCs made since 2021, continue to unlock automatically.

The firmware update flow has also changed. fwupd now asks for a recovery key only when the running system uses TPM-backed encryption and a firmware update could affect the measurements used to unlock the disk, rather than prompting unnecessarily on systems where the update does not affect the TPM-backed unlock policy. This fix has also been backported to Ubuntu 26.04 LTS.

Core utilities, now entirely Rust

Ubuntu 26.04 LTS made the Rust-based uutils coreutils the default, but it retained the GNU implementations of cp, mv, and rm for compatibility. Ubuntu 26.10 migrates those remaining tools. The default core utilities now run entirely on Rust.

These are commands that scripts, packages, and administrators use all day, every day. Safe Rust prevents classes of memory-safety errors, including use-after-free and out-of-bounds memory access through compile-time checks and runtime checks where necessary. This reduces the scope for memory-corruption vulnerabilities, although it does not prevent logic errors or vulnerabilities in unsafe code and dependencies.

We encourage everyone to test their scripts that depend on subtle command behaviour against the new defaults, particularly privileged workflows that copy, move, or delete files.

OpenSSL 4.0 and OpenSSH 10.5

A sufficiently powerful quantum computer could break widely deployed public-key algorithms, such as RSA and elliptic-curve cryptography, which we use today to secure connections and verify signatures. Post-quantum algorithms are designed to withstand that threat. Ubuntu is adding them because data encrypted today could be collected and decrypted in the future.

Ubuntu 26.10 moves to OpenSSL 4.0 (OpenSSL is the global standard for internet encryption), the first new major version since OpenSSL 3.0. This builds on the post-quantum foundations of Ubuntu 26.04 LTS. Like Ubuntu 26.04 LTS, Ubuntu 26.10 makes ML-KEM, ML-DSA, and SLH-DSA available to users, with hybrid post-quantum key exchange being preferred by default in OpenSSL’s TLS configuration when supported by the peer. OpenSSL 4.0 adds the curveSM2MLKEM768 hybrid key-exchange group, the ML-DSA-MU pseudo-digest, and the cSHAKE function.

It also introduces support for Encrypted Client Hello (ECH). When enabled by compatible applications and servers, ECH protects the inner TLS ClientHello, including the requested server name. It does not hide the destination IP address or prevent all traffic analysis, and installing OpenSSL 4.0 does not automatically enable ECH for every application.

Ubuntu 26.10 also introduces upki, a system-level approach to certificate revocation. Linux command-line tools have historically lacked the browser-grade revocation infrastructure used by browsers such as Firefox and Chromium, which means an application can successfully validate a certificate chain without necessarily knowing that a certificate has since been revoked.

upki uses locally cached CRLite revocation data so applications can check certificate revocation without making a separate online request to a certificate authority for every connection. In Ubuntu 26.10, this is integrated with curl, allowing HTTPS connections made through curl to detect revoked certificates as part of certificate verification. The revocation data is updated periodically in the background.

Several legacy interfaces and algorithms have been removed or restricted:

The ENGINE interface has been removed in favor of providers.
SSLv3 support has been removed.
Support for deprecated elliptic curves in TLS and for explicit elliptic-curve parameters is disabled.
Certificate and revocation checks have been tightened, including additional authority-key-identifier checks when strict X.509 verification is enabled.

If you rely on OpenSSL engines for HSMs, PKCS#11 tokens, or TPM-backed keys, now is the time to switch to the equivalent provider: OpenSSL’s newer plug-in interface. Check that a suitable provider exists for your hardware and workflows, and test the migration. These changes reduce legacy code and extend cryptographic capabilities, but they can require application and configuration changes.

Ubuntu 26.10 also ships OpenSSH 10.5. Hybrid post-quantum key exchange remains the default. This includes fixes introduced in OpenSSH 10.3 for certificate and command-line handling:

When checking certificates through the authorized_keys principals= option, an empty certificate principals list no longer acts as a wildcard.
sshd correctly enforces restrictions on which ECDSA algorithms it accepts.
Validation of command-line user names happens earlier, addressing cases where shell metacharacters could otherwise be expanded through configuration tokens in ssh_config.

dbus-broker replaces dbus-daemon

D-Bus lets applications and services communicate, whether they are connecting to Wi-Fi or mounting a USB drive. It is a trust boundary because unprivileged processes use it to reach privileged ones. Ubuntu uses AppArmor to control which D-Bus interfaces snaps and critical packages can access.

Ubuntu 26.10 replaces dbus-daemon, used in Ubuntu since 2004, with dbus-broker. The replacement uses an event-driven architecture with better accounting, reliability, and scalability. Both the system bus and every user session bus will change on fresh installations and upgrades.

The switch to dbus-broker preserves AppArmor’s control over which D-Bus messages applications can send and receive. This keeps existing confinement policies enforced as Ubuntu replaces the message bus implementation. Ubuntu 26.10 also includes further fixes to this AppArmor integration.

Memory-safe time synchronization, ready for testing

Accurate time underpins TLS certificate validation, Kerberos, reliable log timestamps, and audit trails. If a system clock is significantly wrong, valid certificates can appear expired or not yet valid, Kerberos authentication can fail because of clock skew, and security logs can become difficult to correlate reliably across systems. Ubuntu 26.10 includes an updated version of ntpd-rs, a memory-safe NTP implementation, in the archive for testing, and the goal is to make it the default in Ubuntu 27.04.

To accelerate this transition, Canonical has become a Gold Sponsor of the Trifecta Tech Foundation and is funding aspects of ntpd-rs development. The funding supports feature parity with chrony, including multi-threaded NTP servers and GPSd support, as well as AppArmor and seccomp confinement.

Time daemons run for long periods and face the network. Memory-safe code reduces the risk of memory-corruption vulnerabilities, while confinement limits the damage a compromised daemon can cause. Both matter as Ubuntu prepares for the transition.

Enterprise authentication from sign-in to VPN

Ubuntu’s authd service lets users sign into their Ubuntu machines with an account managed by a cloud identity provider using OpenID Connect. In Ubuntu 26.10, authd adds support for signing in with a Microsoft password and completing multi-factor authentication through Microsoft Authenticator.

Separately, authd now derives user and group IDs directly from identity-provider attributes, keeping those IDs consistent across machines in a fleet. This helps ensure that shared files retain the correct ownership and permissions. Administrators can also disable local password authentication for these accounts, requiring users to authenticate through their identity provider.

For VPN access, NetworkManager gains PKCS#11 and smart-card support. Users can authenticate with hardware tokens, such as YubiKeys, through the standard desktop interface. These changes help organizations extend their existing identity, MFA, and hardware-token policies to Ubuntu sign-in and VPN access, without exceptions to explain to auditors.

On-device speech recognition

Ubuntu 26.10 introduces Myna, a desktop speech-to-text feature. It’s designed to bring cutting-edge accessibility, without compromising security.

Myna performs speech recognition locally through an inference snap. Once the required models are installed, dictation works without an internet connection. Audio is processed in memory, discarded after use, and is not uploaded to an external transcription service.

This privacy protection applies to speech recognition. The resulting text is inserted into the application you are using, whose own storage and network behaviour still applies.

Where AI sends data is a critical security question, and Myna addresses this through local inference and confinement of its snap components, without requiring cloud-based transcription.

Linux kernel 7.3

Ubuntu 26.10 ships with Linux kernel 7.3, following Ubuntu’s policy of shipping the latest upstream kernel available at release freeze. As a result, users receive the newest upstream hardening and hardware security enablement as early as possible.

This cycle’s security work includes updates to the Landlock, AppArmor, SELinux, and Smack security modules. There are also TPM driver updates and BPF verifier fixes that prevent pointer leaks on speculative execution paths. NTFS3 received security hardening, and Rust support in the kernel now extends to PowerPC. The release candidates also carried a large batch of memory-safety fixes, many of them found by fuzzing, for use-after-free and overflow bugs across networking, filesystems, and virtualization.

Towards 28.04 LTS

Interim releases give us room to make substantial changes ahead of an LTS, so that the next long-term release can benefit from both security and stability improvements. Ubuntu 26.10 sets the direction for Ubuntu 28.04 LTS with less code in privileged components, from GRUB to OpenSSL, and more memory safety across the system. Hardware-backed encryption comes with explicitly documented trade-offs. Enterprise identity policies extend from sign-in to VPN, while Myna keeps speech recognition local.

Ubuntu 26.10 is supported until July 2027. Test it against your workloads, and tell us what you find. Your feedback shapes Ubuntu 28.04 LTS.

Further reading

[Ubuntu News] Devpack for Rust: Zero to Rust in seconds

Mon, 05 Oct 2026 19:16:26 -0200

One of the best things about Rust is how easy it is to get started. It takes just a second to

Code:
snap install rustup; rustup default stable

, and from there you have a whole toolchain ready to compile Rust code. But with this ease of use comes a giant ecosystem, and with this giant ecosystem comes confusion: What IDE (integrated development environment) should I use? What command-line tooling is there, and which ones are worth using?

Today, we’re announcing Devpack for Rust, the next entry in our devpack series. The Rust devpack is a snap with a collection of tools making it easy to get started with Rust: your favorite Rust version via Rustup, an IDE, and your choice from a suite of Rusty command-line utilities and tooling. It’s all in one command and runs anywhere snap does. Beginners to Rust will appreciate the curated list of options, and Rust veterans might discover some tools they hadn’t known about.

Install the Devpack for Rust with:

Code:
sudo snap install devpack-for-rust --classic

Use the arrow keys (or HJKL) to navigate the tree, and use space/enter to choose which programs to install. The tool will then automatically install Rustup and then use it to compile many of the tools (with some of them coming directly from the Snap store).

What tools come with the devpack? Your author’s most-used program here is

Code:
ripgrep

, which recursively searches the filesystem for files containing a string. In a close second place is

Code:
fd

, which recursively searches the filesystem based on the files’ names instead of their contents. Both of them are rewrites of classic C tools (

Code:
grep

and

Code:
find

), using Rust’s fearless concurrency and its higher-level ergonomics for a better user experience. In a similar vein, we use

Code:
just

internally quite a lot, when we have complicated command-line recipes but don’t need the additional complexity and cruft of

Code:
make

.

Are there any Rusty tools that you wish were here? Open an issue or a pull request! Devpack for Rust is open source at https://github.com/canonical/devpack-for-rust/.

Get in touch with us
Read our Rust documentation ›

[Ubuntu News] Securing open source software dependencies in the public cloud

Mon, 05 Oct 2026 10:00:00 -0200

I recently recorded a Lightboard presentation on securing open source software dependencies in the public cloud. This blog summarises, and expands upon, some of the key elements from that presentation:

I think about this topic through two lenses: software supply chains and updating software dependencies while maintaining stability.

Software supply chains

Software supply chains are the process of converting your source code to a software artefact like a package. In most cases, that will incorporate third-party dependencies. The package you create will also likely be a dependency in a later stage of the build process. Every step of this build process introduces a potential vulnerability or an avenue for exploitation.

One example of this was the SolarWinds supply chain attack. SolarWinds had reportedly been installed in numerous critical organisations, including Microsoft and US government departments. SolarWinds stated:

Quote:The vulnerability was not evident in the Orion Platform products’ source code but appears to have been inserted during the Orion software build process.

SolarWinds Update on Security Vulnerability, as archived 27 September 2021

The takeaway from this incident is that reviewing the source code is not enough. Even if you have reviewed the source code for security vulnerabilities, you need to ensure that you trust the build process. That means either bringing the source code back into your build environment or having confidence in the build process of the organisation or company that builds it.

Updating software dependencies with stability

When building software, you will nearly always incorporate dependencies to save rewriting everything yourself. In modern code bases, these are very likely open source dependencies. Using open source dependencies is normally a great idea, as many people can share the development effort of the functionality you need. The challenge is that these dependencies are their own separate projects with their own upstream maintainers and release timelines. It is unlikely that the upstream maintainers will keep their project on a release timeline that aligns with your software project.

If one of your dependencies has a security vulnerability, you have three main options:

ignore it (which is not normally a real option);
allocate sufficient developer time to incorporate the fixes safely; or
use Extended Security Maintenance.

Ignore it

In 2017, Equifax relied on the Apache Struts framework. A security vulnerability was found in the framework and Apache Struts released a fixed version. Unfortunately, Equifax did not roll that fixed version out to its production systems in the months that followed. The result was a data breach that exposed nearly 150 million individuals’ personal data and led to a $575m settlement. Ignoring security vulnerabilities in your dependencies is probably the wrong option.

Allocate developer time

A second option is to allocate your development teams sufficient time to solve this problem. They need to monitor the upstream projects for relevant security vulnerabilities and carefully review the fixes to determine the best approach to incorporate them into your software project. The two main approaches there are:

pulling in the latest version of the dependency; or
vendoring the dependency and trying to backport important security fixes yourself.

Developers will often take the latest version of the dependency to address a security vulnerability. They may pull this from the upstream repository or an ecosystem package (e.g. pip or npm). The challenge, however, is that many open source software projects will mix security fixes, bug fixes and new features in new versions. That may mean that, in addition to the security fix that your team needs, bringing in the latest version also brings in a change to the API or the dependency’s behaviour. This means that you should put the revised combination through quality assurance, and potentially user acceptance tests with your key customers, each time you update a dependency in this way.

An alternative “do it yourself” approach is to bring selected fixes back from the upstream into your codebase. This means your team then carries the maintenance burden of this “vendored” dependency and fixes. It can become a challenge to determine whether or not future vulnerabilities affect your unique, vendored version of that dependency. Generally speaking, the more people using, finding and fixing bugs in open source the better. That means uniqueness also carries stability risks, as nobody else is using the exact same code as you.

It is possible to keep your dependencies up-to-date with sufficient investment of developer time. Investing this time, however, can reduce the time that the team can invest in more valuable activities like new features. There is also the risk that the friction of doing it yourself creates a disincentive to roll out new security fixes to production systems.

Expanded Security Maintenance (ESM)

Canonical provides a useful third option to customers trying to solve this problem, called “Expanded Security Maintenance” or “ESM”. ESM gives developers thousands of packages in the main and universe repositories of Ubuntu. These packages span the full spectrum of tools, language ecosystem packages and libraries that developers build on.

Each time a high or critical security vulnerability emerges in the up to 15 years following release, Canonical’s security team will create a patched package. They will put that fix back through the same trusted build process that you are using for all of your other Ubuntu packages, meaning that you are not increasing your exposure to software supply chain vulnerabilities. They will also run some tests on the package and ultimately produce a drop-in replacement package for the dependency you are using.

This replacement package will contain just the security fix, maintaining API stability and not changing functionality. This makes it easier for your team to take the updated combination through quality assurance and user acceptance testing. Importantly, fewer changes and easier testing means you can push the fix into production as quickly as possible.

This approach becomes even more valuable the longer that your software stays in production. That is because the difference between your version of the dependency and the latest (security-patched) upstream will grow. There are likely to be a lot of changes to a dependency in 15 years. ESM gives you a unified security maintenance commitment, for the same set of packages and versions, for the same period of time.

Obtaining ESM in the public clouds

ESM is available as part of Ubuntu Pro. For datacenter use cases, Canonical makes ESM available with Ubuntu Pro tokens that you attach in each machine or instance. We have worked with the three biggest public clouds, however, to make using Ubuntu Pro as easy as possible. Ubuntu Pro on these clouds will launch with entitlements attached automatically and ESM turned on by default out-of-the-box. These are also billed via the public cloud, avoiding the need for a separate procurement relationship. See how to launch these or upgrade your instances to Ubuntu Pro on AWS, Azure or Google Cloud Platform. Oracle or IBM Cloud users should contact us.

Conclusion

Creating stable and secure software is about more than just the code that your developers write. You need to be confident that the build system that your code uses meets your requirements for security. If you are using dependencies, open source or otherwise, your team needs to have a plan for when there is inevitably a vulnerability in those dependencies. Your team needs to ensure that it either budgets the time to incorporate security fixes into your software, with the security and stability requirements that you have, or perhaps you should take a look at ESM.

Further reading:

Learn how to take advantage of ESM

A guide to open source vulnerability management

Ubuntu updates, releases and repositories explained

Ubuntu Pro FAQ

[Ubuntu News] Confidential computing in the real world: finding your use case

Fri, 02 Oct 2026 09:59:10 -0200

Confidential computing is essential when an organization needs to process sensitive data on infrastructure where the operators should not have access to it. You might have seen this requirement before: it appears commonly in public cloud deployments (where organizations want to prevent the cloud vendor seeing data), but also when hospitals evaluate proprietary AI models on premises (to keep patient info from being seen by IT managers) or when businesses analyse data together without disclosing their underlying records.

Intel develops the hardware technologies that isolate workloads from the infrastructure running them, while Canonical works on the Ubuntu software needed to use those protections. Together, we examine where confidential computing is useful and the engineering needed to support it.

What confidential computing protects

Encryption at rest and in transit protects stored data and network traffic. However, during processing, applications need access to plaintext, which traditional virtualization leaves accessible to sufficiently privileged host software. Confidential computing protects data during this stage by processing it inside a hardware-isolated environment, commonly called a trusted execution environment, or TEE.

How Intel TDX works

Our examples are inspired by a webinar we ran with Intel. The examples use Intel Trust Domain Extensions (TDX) to explain how this protection works at the virtual-machine level. With Intel TDX, the protected environment is a virtual machine called a Trust Domain. A virtual machine is a software-defined computer running its own operating system and applications. The hypervisor is the host software that creates and manages those machines.

The hardware and the TDX module enforce protections that would otherwise depend on the host hypervisor. The TDX module is Intel’s security software that works with the processor to manage and isolate Trust Domains. Together, they prevent the host hypervisor from directly reading or modifying the VM’s protected memory.

Before sending sensitive data to that VM, a data owner also needs to check what environment they are trusting. Remote attestation supplies cryptographic evidence of the platform’s security state and the VM’s measured configuration. A verifier checks that evidence against an agreed policy: a key service can then release decryption keys only to an approved environment.

For an enterprise, this changes the conditions under which a workload can be outsourced. The infrastructure provider can operate the host without its hypervisor having ordinary access to the protected guest’s memory. The guest operating system and application remain inside the trust boundary.

The role of the guest side in confidential computing

Hardware isolation protects the VM from the infrastructure, but the software running inside the guest determines what happens to the data once it arrives. The “guest” is the operating system and applications inside the VM, as distinct from the host that runs it. At Canonical, this includes the Ubuntu guest operating system and its boot and runtime security.

That software must preserve the protections the deployment relies on. Teams also need workable processes for managing confidential VMs, including updates and recovery, while data owners need to understand what the attestation evidence actually establishes.

A VM’s initial attestation does not automatically cover every application it will load or every action it will take, but there are additional mechanisms you can use to gather more information. The boot process can record additional software measurements in TDX runtime measurement registers (RTMRs), allowing a verifier to check more of the boot chain. Filesystem integrity mechanisms such as dm-verity can help ensure that an approved filesystem has not been altered. These checks need to be connected to the policy used to release secrets.

Runtime controls remain necessary, even on the guest side. An administrator with access inside the guest may still be able to read application data, and an update can change the software that was previously approved. Therefore, the deployment needs to define which administrative operations are permitted and how new software versions become trusted.

Data owners need this because proof that a VM is genuine doesn’t tell them what the VM will do with their data. Before releasing data, a data owner might want to know that the VM won’t persist it, that it has no known critical CVEs, and that someone they trust has audited the code and found no backdoors. Attestation alone cannot establish all of those properties, and needs to be combined with software review, vulnerability information and controls on application behaviour.

Transparency logs help with the audit question. They are append-only records of published software, so anyone can check efficiently whether a given build is included and verify that later versions of the log preserve its earlier entries.

Four common patterns for deploying confidential workloads

The webinar groups confidential computing deployments into four common patterns to help you identify where confidential computing could fit your organization. They differ mainly in whose data or software needs protection, and who should be prevented from accessing it. A deployment can combine more than one pattern.

Protected outsourcing

A company runs a sensitive workload on infrastructure it doesn’t control, usually a public cloud, and uses confidential computing to keep the provider and its administrators away from the data. Regulation, sovereignty requirements, and concern about malicious insiders are the usual reasons for this approach.

Proximus, Belgium’s largest communications provider, uses a tiered design of this kind, with open data in standard cloud deployments, internal confidential data in confidential VMs, and GDPR-regulated subscriber data in confidential deployments that add application isolation and geographic controls.

Multi-party analysis

Several organizations want to derive insights from their data without giving one another access to the underlying records. Examples include detecting money laundering across banks and identifying insurance fraud. They authorize an agreed application to process the data inside a confidential environment and control which results it can release. The application can read the records to perform the calculation while the participating organizations receive permitted outputs, such as aggregate statistics, rather than unrestricted access to each other’s raw data.

BeeKeeperAI takes this approach with Novartis for rare disease research, where the relevant data is spread across hospitals with restrictions on moving or disclosing patient records. Another example is from an Intel case study, which describes a deployment in which the analysis runs next to each hospital’s data and updates a shared model, and neither Novartis nor BeeKeeperAI staff see the records.

Secure SaaS

A software provider uses confidential computing to offer a service, often an AI model, to customers who don’t want to expose their data to the provider, while the provider doesn’t want to expose its model. Here, the customer is using someone else’s application. The design must protect customer inputs from the service operator while also protecting the provider’s software or model from the customer.

Gemini on Google Distributed Cloud illustrates this requirement for a managed AI service deployed on customer premises. Google describes support for Intel TDX on CPUs and NVIDIA confidential computing on GPUs. These protections help customers process sensitive data while protecting Google’s proprietary model.

Protected end-user applications

A service provider uses confidential computing to process users’ personal data in a protected environment, where the provider’s administrators cannot directly inspect it. This allows the provider to deliver the service while restricting its own access to the contents of users’ requests.

The focus here is the relationship between an individual and the service they use, rather than organizations contributing datasets to a joint analysis. The user should be able to obtain a result without giving the operator unrestricted access to the contents of their request.

Apple’s Private Cloud Compute is one example. Apple has announced an expansion onto Google Cloud using Intel TDX and NVIDIA GPUs. Its design combines confidential computing with restrictions on privileged access and verifiable software transparency to support its privacy commitments. Those commitments depend on the complete service architecture, including how requests are handled and data is retained.

AI as the main source of new demand for confidential computing

AI workloads can fit any of the four patterns. An organization outsourcing model training needs protection from infrastructure operators; hospitals evaluating a model across their datasets face a collaboration problem; a commercial inference service may need to protect both customer prompts and proprietary model weights.

The hardware isolation and attestation described earlier can protect the environments that perform training, fine-tuning, or inference. Federated learning is a related deployment approach: each participant trains on its own data and shares model updates instead of pooling raw records. Confidential computing is necessary because keeping data local does not, by itself, prevent privileged software from accessing it or stop shared updates from revealing information. Confidential computing can protect local processing and the aggregation of updates.

In healthcare, MLCommons demonstrated MedPerf on Google Cloud Confidential Space to evaluate a brain tumour segmentation model developed at Duke University, working with the FeTS community. The MedPerf confidential environment on Google Cloud protects patient data and model weights during evaluation and helps protect benchmark integrity. This is an example of the multi-party analysis pattern: institutions can contribute to an evaluation while controlling access to their private assets.

Getting started

You can now use the four patterns covered in this blog to identify a workload where access to data is preventing a deployment or collaboration. Establish who owns the sensitive inputs, which software must process them, and which operators should be excluded from access. That gives you a concrete basis for choosing the isolation boundary and deciding what must be verified before data is released.

Good candidates include a workload held back from cloud migration by concerns about provider access, or an analysis that requires data from organizations unable to disclose their records to one another. The examples in the session show how confidential computing can address those barriers and where additional software controls are needed.

Watch the webinar

For a full rundown of confidential computing use cases, check out our pre-recorded webinar. The full session, including the customer examples and a closer look at attestation, is available on demand.

Watch Confidential computing in the real world on demand

To discuss your own use case, get in touch with our confidential computing team.

[Ubuntu News] Android™ belongs in your CI/CD pipeline

Thu, 01 Oct 2026 07:24:20 -0200

How on-demand Android environments turn validation into a repeatable pipeline stage

In the first article, we looked at automation: how Android environments can be created and managed programmatically. In the second, we looked at scaling: how shared infrastructure can make those environments available to more developers, tests, and workloads.

This third article looks at the next step: integrating those environments directly into CI/CD.

A CI/CD system may already automate much of the software delivery process, from producing an application or Android image to triggering tests and reporting results. The Android execution environment, however, can still sit outside that workflow. Consider the following disconnects:

An application may be built automatically, but someone must connect a device before validation can begin.
A pull request reaches a manual stage because the required Android environment is not available to the pipeline.
A test passes on one workstation and fails on another because the underlying environment has changed.

This is the gap CI/CD integration closes. With Anbox Cloud, the Android execution environment becomes another resource the pipeline can request when needed. The workflow can request the necessary environment, deploy the artifact, initiate validation, collect results, and release resources once the task is completed.

Instead of treating Android as a separate component of the pipeline, the environment is integrated into the automated software delivery process.

In this article, “Android execution environment” refers to the Android instance in which the application or system is run and validated, including the Android image, configuration, allocated resources, and test setup.

Make Android part of the workflow

CI/CD pipelines are built around repeatability. A change produces an artifact, tests run against defined inputs, and the pipeline records enough information to understand the result.

The execution environment is part of that process. CI/CD pipelines already provision temporary resources such as containers, virtual machines, databases, and services as part of a job. With Anbox Cloud, the Android execution environment can become another resource requested by the pipeline when needed.

Instead of treating a physical device or local emulator as a prerequisite, the pipeline requests an Android environment with a known image and configuration. It deploys the artifact, performs the required validation, collects the evidence, and releases the resources.

Anbox Cloud does not build the Android application or platform. That remains the responsibility of the existing build system. Its role is to provide the Android environment required for validation through a programmable and repeatable lifecycle.

A typical Android pipeline

The exact tooling varies, but the workflow is typically consistent. The pipeline first produces or retrieves the artifact to validate. For an application team, that may be an APK. For a platform team, it may be a complete Android or Android Automotive OS image.

Usually, after requesting the predefined environment, the process can then deploy the artifacts, get the test data ready, and establish a connection (using ADB, for instance). Once that is done, and before deleting the environment, test reports, logs, screenshots, crash data, and performance metrics are gathered.

Every stage of the process should be explicit. The pipeline should know which artifact was tested, which Android environment was used, which configuration was applied, and which outputs were produced.

Without that context, automation may speed up testing but not improve the reliability of the results.

Reproducibility matters more than automation alone

Being able to start Android automatically is useful, but starting the same environment consistently is way more valuable.

When the Android version changes between runs, a setting is manually changed, cached data influences the outcome, or an older application is still installed, the results are difficult to trust. Making those inputs explicit in the CI/CD workflow reduces manual configuration errors and improves reproducibility.

The Android image, application artifact, instance resources, display settings, test inputs, and expected outputs can all be associated with a specific execution. The workflow can also wait for known states instead of relying on arbitrary delays or assumptions about when an environment is ready.

A script says, “Start Android and run this test.” A reproducible pipeline says, “Run this version of the test against this artifact, in this defined environment, with these inputs, and preserve enough evidence to explain the result.”

That second model is what teams need when a failure blocks a release.

Preserve evidence, not unnecessary infrastructure

Disposable environments allow every run to begin from a clean state, but removing an environment should not mean losing the information required for debugging.

When validation fails, the pipeline should collect the relevant diagnostics before releasing the resources. It may also record the environment definition so that an engineer can recreate the same conditions later. In selected cases, preserving an instance temporarily for interactive investigation may be useful.

The goal is not to retain every failed environment indefinitely. A better principle would be to preserve the evidence by default and preserve the environment when it adds value.

This keeps the workflow efficient while giving teams enough information to understand and reproduce failures.

One operating model, different Android workloads

Application and platform teams validate different artifacts, but the operational model remains the same.

An application pipeline may install an APK and run instrumentation, UI, compatibility, or integration tests. A platform pipeline may validate a complete Android system image, an Android Automotive OS configuration, platform services, or a custom OEM build.

The execution environment may differ as well. Application-oriented workloads may benefit from containerized Android when density and startup time matter. Complete system workloads may require virtualized Android with a full virtual-machine boundary.

Those are implementation choices. The pipeline story remains consistent: a change produces an artifact, the workflow requests the appropriate Android environment, and validation begins without waiting for someone to prepare hardware.

Keep people and hardware where they add value

Not every validation decision can be automated. Developers may need to inspect a graphical issue, QA engineers may need to review a visual difference, and platform engineers may need to investigate system behavior interactively. A pipeline-created environment can still be recreated, streamed, or shared temporarily for that work.

Physical hardware remains essential for validating sensors, peripherals, radios, drivers, power consumption, thermal behavior, and final production performance. But it does not need to carry the full weight of the development process. Programmable environments can provide earlier feedback and broader parallel validation before software reaches the final hardware stage.

A balanced strategy would be to run every change, validate broadly in the cloud, and finally prove it on target hardware.

Android should no longer be the manual exception

Automation makes Android environments programmable. Scaling makes that capacity available when workflows need it. CI/CD brings both capabilities into the software delivery process at the point where feedback is most valuable.

The pipeline can request an environment, deploy the artifact, run validation, collect evidence, and release the resources without waiting for someone to connect a device or prepare a test machine.

Android becomes part of the workflow rather than an external dependency on it. Physical hardware remains the final proof, but routine Android feedback no longer needs to wait for it.

That is the broader transformation explored throughout this series: Android moves from a scarce physical asset to programmable engineering infrastructure.

Further reading

Read Part 1: Android development shouldn’t start with a physical device

Read Part 2: Scaling Android development without scaling hardware

For any questions, feel free to get in touch with the Anbox team.

[Ubuntu News] Realtime transaction fraud detection – with an LLM?

Wed, 30 Sep 2026 04:58:49 -0200

Conversational AI with a chatbot is great for drafting emails or debugging code, but it’s less ideal for real-time application middleware. If you’re trying to inspect a financial transaction for potential fraud in the middle of a checkout loop, you don’t need an LLM to write you an essay about why a credit card transaction looks suspicious – you just need a probability score, and you need it as fast as possible.

To this end, TypeSafe AI recently released Jev, a cloud-based service that uses modified generative AI models for classification tasks. Naturally, the open weight model community has responded with similar, publicly accessible models that you can run yourself. Instead of generating natural language, these AI large language models bypass text generation entirely. They read the context you provide them with, evaluate all your typed questions in a single parallel pass, and report back the probabilities.

The advent of this new LLM-based classification technique seemed to me to be, if nothing else, a great opportunity to demonstrate how to use Canonical’s open source MLOps stack to build a realtime transaction fraud detection system, based on an open weight, Jev-like model – the “system-one-qwen3.5-4b-scorer” model.

Sounds like fun? Good. Let’s start.

Open source MLOps

Canonical’s open source MLOps stack is pretty comprehensive, with integrated support for Kubeflow, Katib, Feast, MLFlow and KServe for doing everything from pre-training, to fine tuning and reinforcement learning, with a set of structured tools to help with the full project lifecycle from early research to production.

But for this project, we’ll just be using KServe. KServe is a Kubernetes based inference server control plane. It helps you to deploy AI models – including large language models – on Kubernetes, so that you can benefit from the resilience and automation that Kubernetes offers for production deployments. Before we begin in earnest, make sure you you can meet the prerequisites:

You’ll need to be running at least Ubuntu 24.04 LTS on your computer.
Your computer needs to have at least 32GB of RAM and a modern CPU to run everything comfortably.
I initially used the integrated graphics processor on my laptop’s CPU to accelerate the model’s processing, but to make this lab project more accessible, we will use your computer’s CPU. The model will just run slower.
A stable, high speed internet connection for downloads.
Some familiarity with Linux commands so that you can follow along.

Install KServe and set up the lab project

First up, let’s prepare the system. Open up your terminal and make sure you’ve got the base software installed. Run the following commands:

Code:
[code]sudo snap install microk8s --channel 1.34-strict/stable
sudo microk8s enable storage dns
sudo microk8s enable metallb 10.64.140.43-10.64.140.49
sudo snap install juju --channel 3.6/stable
sudo microk8s.config | juju add-k8s my-k8s
sudo snap install terraform
sudo apt install git -y
git clone https://github.com/canonical/charmed-kubeflow-solutions.git
pushd charmed-kubeflow-solutions
git checkout track/1.11
pushd terraform/products/kubeflow[/code]

Congratulations, you’ve just installed a one-node, super-compact Kubernetes cluster running Canonical’s MicroK8s, with Canonical’s operations management engine Juju, and with Terraform.

Now let’s launch Charmed Kubeflow. We’re only going to enable Kubeflow and KServe, so we’ll disable all the other modules like Katib, MLFlow, TensorBoard, federated login and the Canonical Observability Stack. You can always enable them if you want, but they aren’t needed for the purposes of this demo.

Code:
[code]DEX_USERNAME=username
DEX_PASSWORD=password
terraform init
terraform apply -auto-approve -var dex_static_username="${DEX_USERNAME}" -var dex_static_password="${DEX_PASSWORD}" -var enable_feast=false -var enable_katib=false -var enable_kserve=true -var enable_training_v2=false -var enable_training_v1=false -var enable_observability=false -var enable_tensorboard=false
popd
popd[/code]

Give it 10-15 minutes for things to come up on the Kubernetes node. You can monitor how close things are getting to completion with the command `juju status -m kubeflow`. When everything is saying “idle/active”, we’re ready to go further with this lab project.

I’ve prepared the scripts needed to successfully complete this project and put them up on GitHub. The next step will be to clone the git repository to your local system. Run the following command:

Code:
[code]git clone https://github.com/grobbie/realtime-transaction-fraud-detection-with-an-llm.git
pushd realtime-transaction-fraud-detection-with-an-llm[/code]

Now let’s install the development tools that we’re going to need. Make sure not to skip these steps.

Code:
[code]sudo apt update && apt install -y python3-venv python3-pip
python3 -m venv .venv
source .venv/bin/activate
.venv/bin/pip3 install -r requirements.txt[/code]

Model crush

The model we’re using isn’t the biggest, but it’s still big enough to crash a laptop – or rather, to crash the Kubernetes pod it’s going to run inside. So there are a couple of tricks we’re going to use to make it work much more efficiently on your computer, even without a high power GPU.

The model we’re using is actually a derivative model using a LoRA adapter architecture. Low rank adaptation (LoRA) is a model fine-tuning technique that allows you to adapt a large language model to a specific task, without modifying the original model at all. However, for our purposes this approach adds additional overheads – every request has to pass through both the base model and the adapter paths simultaneously. This is good if you want to hot-swap model specialisms on a base model in real-time. But we just want a compact, efficient model that’s going to do classification tasks, so we’ll merge the LoRA weights into the base model.

The other trick we’re going to use is Activation-aware Weight Quantization (AWQ). This is a 4-bit post-training quantization technique that compresses the model with minimal loss of accuracy. With AWQ, we can squash the amount of VRAM the model needs down by up to 75%. While this technique is really designed and optimized for accelerating models that are running on GPUs, it does also work on the CPU. So for our Qwen3.5-4b derivative model, we should be able to get the model’s VRAM needs down from about 18GB all-in to around 5GB. Not too bad and definitely enough of a squeeze for you to be able to reliably run it on a laptop or similar without crashing, and yielding decent performance.

Run the following command to download a calibration dataset and prep it, and then merge the model weights and quantize:

Code:
[code].venv/bin/python3 quantize_awq.py[/code]

This downloads the model weights from Hugging Face Hub, runs the merge and quantization, and produces a `./system-one-4bit-awq` directory containing all the necessary model artifacts. The task could take a while to complete – expect it to take around 6 hours on a laptop because of the calibration that we need to do during quantization.

Run the model on vLLM

Now we’ve got the model, we need a way to run it. We’ll run it on the industry standard vLLM model server, using KServe as a means to set everything up nicely on Kubernetes.

To deploy the vLLM serving pod and service, you can use the manifests from my git repository. Before you run the commands, be sure to edit the file `kserve_deployment_cpu.yaml` to adjust the path to the model. Make sure the path is set to wherever the `system-one-4bit-awq` directory is on your system.

Code:
[code]microk8s.kubectl create namespace modelserving
microk8s.kubectl apply -f kserve_deployment_cpu.yaml
microk8s.kubectl apply -f kserve_service_lb.yaml[/code]

It’ll take a fair bit of time for vLLM to start up, load the weights into memory, and get ready to serve on your CPU. You might be waiting as long as 5 minutes for this depending on the specs of your system. Obviously, it almost goes without saying that if we were doing this for real we’d use GPU acceleration and the whole experience would be a lot more performant.

To verify the pod is running, you can try the following command:

Code:
[code]microk8s.kubectl get inferenceservice -n modelserving[/code]

Eventually, if all goes well the output will show that the health checks are good, and you’ll be ready to try out some classification tasks with your new specialized artificial brain.

Run some predictions

Obviously the goal of all of this, besides learning, is to run some transaction fraud detection with an LLM. So we want to try that, right? Of course. Let’s try that now and see if it works.

First we’ll try with a terminal command, and then we can try with a little web app I put together. To make sure the model is running accurately, we’re going to send it a web request using the `curl` command in the terminal, and see how it responds. We can use this one-liner command to find the right IP address for the vLLM model server:

Code:
[code]KSERVE_IP=$(kubectl get services -n modelserving | grep system-one | grep private | awk '{ print $3 }')[/code]

Now let’s send a request to the vLLM endpoint and see what we get back:

Code:
[code]curl -s -X POST http://${KSERVE_IP}:8080/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/model",
    "prompt": "<|im_start|>user\nSystem One Fraud Risk Decision Query:\n\nTarget Transaction Profile:\nTRANSACTION PROFILE:\n- Type: TRANSFER\n- Transaction Amount: $100,000.00\n- Sender Initial Balance: $100,000.00\n- Sender Post-Transaction Balance: $0.00 (Delta: $100,000.00)\n- Recipient Initial Balance: $0.00\n- Recipient Post-Transaction Balance: $100,000.00 (Delta: $100,000.00)\n\nQuestion: What is the fraud risk classification for this transaction?\nOptions: 0: LOW_RISK, 1: MEDIUM_RISK, 2: HIGH_RISK_FRAUD<|im_end|>\n<|im_start|>assistant\nAnswer: ",
    "max_tokens": 1,
    "temperature": 0.0,
    "logprobs": 3
  }' | .venv/bin/python3 -m json.tool[/code]

The request contains the context – a transaction record, showing the transaction type, amount, the sender’s initial balance, the sender’s balance after the transaction, the recipient’s initial balance, and the recipient’s post-transaction balance. It also contains a structured JSON object containing the question: “What is the fraud risk classification for this transaction?”, and it contains the options that the model can use – “LOW_RISK”, “MEDIUM_RISK”, and “HIGH_RISK_FRAUD”. Each option has a short description. You could actually ask a few of these structured questions, and they should all be processed in parallel by the model.

If everything goes correctly, then when you run the command you’ll get some output back pretty quickly. It should look something like the listing below which is a response giving the model’s prediction.

Code:
[code]{
  "id": "cmpl-84ef1f97a3cc8d37",
  "object": "text_completion",
  "created": 1789839558,
  "model": "/model",
  "choices": [
    {
      "index": 0,
      "text": "2",
      "logprobs": {
        "text_offset": [0],
        "token_logprobs": [-1.5500739812850952],
        "tokens": ["2"],
        "top_logprobs": [
          {
            "2": -1.5500739812850952,
            "1": -1.7219489812850952,
            "0": -2.0422616004943848,
          }
        ]
      },
      "finish_reason": "length"
    }
  ],
  "usage": {
    "prompt_tokens": 182,
    "total_tokens": 183,
    "completion_tokens": 1
  }
}[/code]

It can be a bit tricky to interpret, but basically the bits to look for are the value of `text` and `top_logprobs`. “text” indicates the predicted classification (“text”: “2”). The model selected option token “2”, which corresponds to HIGH_RISK_FRAUD.

Looking back at the transaction record we sent, the transaction was a wire transfer of $100,000 to an empty bank account that completely drained the sender’s account. Definitely a risky transaction highly likely to be fraudulent. So if your model responded with “text”: “2”, then it got it right.

Not as much fun using the terminal though, so let’s start up that web app I promised you, which you’ll find in my repo. Start it by running the following command:

Code:
[code].venv/bin/python app.py[/code]

The interactive web UI should be accessible at http://localhost:8000/ for you to play with.

Take it further

This has just been a lab project, but you can definitely take this further. Open weight models and open source software enable you to run AI behind the firewall in your own, self-governed environment – without needing to use cloud services. And with some optimizations the investment involved to run this technology doesn’t need to be out of reach – especially for enterprise use cases like this one. Of course, the whole process from quantization of the model to running the model could be accelerated with only a modest investment in GPUs; but if you want to run this kind of workload in production with low milliseconds response times across a huge number of concurrent real time transactions, then you might need a more substantial setup.

In any case, Canonical’s MLOps stack is there to support your use case.

Discover the full capabilities of Charmed Kubeflow
Want us to manage the infrastructure so you can focus on the models? Sign up for Managed Kubeflow on Azure

[Ubuntu News] Upgrade your desktop: Ubuntu 26.04.1 LTS is now available

Tue, 29 Sep 2026 09:16:20 -0200

Whether you’re a first-time Linux user, experienced developer, academic researcher, or enterprise administrator, Ubuntu 26.04 LTS Resolute Raccoon is the best way to benefit from the latest advancements in the Linux ecosystem on a stable foundation.

As with all LTS releases of Ubuntu, Ubuntu 26.04.1 LTS represents the consolidation of fixes and improvements identified during the initial launch of Ubuntu 26.04 LTS. It’s available to download and install from our download page.

Download for free

Users of Ubuntu 24.04 LTS will shortly be prompted to upgrade to 26.04 LTS directly from their desktop, either automatically or as part of a scheduled update. If you missed our press release, don’t worry. We’re summing up the most exciting developments in this post to get you ready to upgrade.

User experience and performance enhancements

With the GNOME 50 desktop environment and a modernized set of default applications, Ubuntu 26.04 LTS fully embraces Wayland, completing the upstream shift from X.org. This shift delivers smoother visuals, per-monitor scaling, native touch and gesture support, removes screen tearing and optimizes performance across platforms, including support for the latest NVIDIA production drivers. Fractional scaling and variable refresh rate (VRR) are no longer experimental, and GNOME 50 brings faster animations and a cleaner workspace.

New default applications include the Papers document viewer, the Loupe image viewer, the Ptyxis terminal, and the Resources system monitor, along with a broad set of accessibility fixes across the Shell and default applications to ensure compliance with global regulations. The App Center now provides a unified software management experience, with debs and snaps displayed side-by-side in a single place.

Your development and AI tools, right at home on Ubuntu

As the target platform for open source software vendors and community projects, Ubuntu 26.04 LTS ships with the latest toolchains for Python, Rust, Ruby, Go, PHP, and Perl, and users get first access to the latest updates for key libraries and packages.

In fields such as data science and machine learning, Ubuntu is the operating system (OS) of choice for many of the most popular frameworks. This includes OpenCV, TensorFlow, Keras, PyTorch, and Kubeflow.

Ubuntu 26.04 LTS is the first Ubuntu release to natively distribute NVIDIA CUDA as part of its software repositories, and NVIDIA DOCA-OFED for high-performance networking is available through an official PPA starting with this release. The AMD ROCm software platform is also now available in Ubuntu’s repositories – an open software ecosystem for hardware-accelerated AI, machine learning, and HPC workloads on AMD Instinct and AMD Radeon GPUs.

Get development environments that just work, with Workshop

Launch sandboxed development environments that are composable and repeatable with a single command. Innovate with agentic workflows while keeping your host system isolated.

Learn more

Security and compliance features for enterprises

Ubuntu 26.04 LTS builds on the resilience-focused improvements introduced in interim releases, bringing security and compliance enhancements that shrink the attack surface and harden the OS against unauthorized or malicious entry attempts.

TPM-backed full-disk encryption is now generally available in the Ubuntu installer. By tying encryption to the TPM security chip, disk encryption is bound to a specific device, significantly raising the bar for physical access attacks while improving the user experience. As part of this release, the Security Center becomes a control plane for platform protections. Through the Security Center, administrators can inspect and manage TPM-backed encryption state, recovery mechanisms, Secure Boot status, and disk protection configuration after deployment.

Ubuntu 26.04 LTS is the first LTS to expand the number of memory safe system components. In practice, this means new kernel drivers and subsystems written in Rust, as well as

Code:
sudo-rs

and

Code:
uutils

coreutils, bringing memory-safe reimplementations of foundational system tools such as

Code:
sudo

and

Code:
ls

while GNU implementations remain available for compatibility.

Cryptographic defaults in Ubuntu 26.04 LTS are post-quantum aware: hybrid post-quantum key exchange is enabled by default, and legacy cipher support has been fully retired. Ubuntu 26.04 LTS provides host and guest support for confidential computing on Intel Trust Domain Extensions and AMD SEV, extends Canonical Livepatch to Arm64 for the first time, and delivers an updated WSL experience with cloud-init and Ubuntu Pro for WSL.

Read what’s new in security for Ubuntu 26.04 LTS >

Finally, for enterprises requiring strict identity management,

Code:
authd

enables authentication against cloud identity providers such as Entra ID, Google IAM and any OIDC-compliant service from the official repositories.

Enterprise identity management for Ubuntu Server and Desktop

Best practices for securing access to Ubuntu in large enterprises

Read our whitepaper

More value for enterprises with Ubuntu Pro

Running the latest OS offers new features and enhanced performance, which is a good choice for new deployments. However, organizations also prioritize stability, security, and support, whether it’s for a fleet of workstations or established production systems.

Canonical’s Ubuntu Pro subscription caters to these needs. As with other long term supported releases, 26.04 LTS not only includes five years of standard security maintenance on the main Ubuntu repository, but that coverage is extended to 10 years and tens of thousands of packages with Ubuntu Pro. An additional 5 years of support can be purchased through our Legacy Support add-on, giving you a 15 year commitment on this release and going back to 14.04 LTS.

This .1 update to Ubuntu 26.04 LTS Resolute Raccoon brings additional stability to our release, making it the ideal choice for your enterprise.

Get started today

[Ubuntu News] Creating a private 5G network

Mon, 28 Sep 2026 12:13:43 -0200

Private 5G networks are dedicated cellular systems delivering ultra-reliable low-latency communication, massive IoT connectivity, and customized security for enterprises undergoing digital transformation. Private 5G subsumes advantages of both public and non-public networks, offering unified connectivity, optimized services, and customized security within a defined area. Private 5G empowers enterprises to control and secure their own information, optimize networks for exclusive requirements, and flexibly reconfigure infrastructure as business objectives evolve.

Private 5G has evolved from an experimental concept into critical industrial infrastructure. The success of private 5G hinges on a fundamental architectural shift: replacing heavyweight, legacy virtualization stacks with agile, softwarized infrastructure that slashes operational expenditure (OpEx) and accelerates service delivery.

However, deploying private 5G at the edge introduces additional challenges. The edge is constrained by power, cooling, space, and it is physically vulnerable. And, increasingly, the edge needs to meet high localized AI processing demands. Solving these challenges requires a cohesive software stack spanning from the immutable Operating System (OS) up to model-driven automation, capable of bridging the gaps between telco requirements and cloud-native IT.

The virtualization dilemma

Historically, deploying a mobile core required racks of servers, substantial power consumption, and heavyweight virtualization stacks like traditional OpenStack. In contrast, private 5G scenarios, where the infrastructure might live in a factory closet or an outdoor enclosure, require lightweight virtualization instead. The user plane function (UPF) of the 5G core, and often the virtualized radio access networks (vRAN) and/or open RAN (O-RAN) components, need to run on a fraction of the footprint.

For years, the industry narrative faced a binary choice: either stick with traditional, resource-heavy virtual machines (often managed by enterprise hypervisors), or move entirely to application containers (managed by Kubernetes). At the enterprise edge, neither extreme is perfect on its own. Legacy hypervisors consume too much compute overhead, inflating OpEx and hardware costs. Conversely, although modern 5G Core and vRAN components are shifting to cloud-native network functions (CNFs) that demand near-bare metal performance, many enterprises still rely on legacy virtual network functions (VNFs) or security appliances that require strict kernel-level isolation.

As a consequence, the industry is increasingly embracing lightweight, hybrid edge virtualization. Architectures built on system containers deliver similar packet performance to bare metal for 5G UPFs while using lean KVM virtual machines (VMs) only when strict kernel boundaries are mandated. This hybrid footprint keeps edge compute efficient, low-touch, and cost-effective.

This is where MicroCloud changes the game for private 5G.

MicroCloud is a low-touch, automated private cloud designed specifically for the edge. Instead of deploying a massive, bloated cloud infrastructure, MicroCloud combines lightweight LXD system containers and virtual machines, distributed storage via MicroCeph, and software-defined networking via MicroOVN into a single automated tool. MicroCloud allows you to deploy a lightweight cluster that can run on as few as three to four physical nodes with 32 GB of RAM each for production high availability deployments.

The OS at the core: determinism, hardware acceleration, and immutability

In private 5G deployments, the OS is the foundational layer through which the network stack accesses compute, networking, scheduling, and hardware acceleration capabilities. For latency-sensitive workloads, a real-time kernel such as real-time Ubuntu, which incorporates PREEMPT_RT, can make task execution more predictable by reducing scheduling latency and providing more deterministic response times. High-throughput UPF workloads, meanwhile, can use technologies such as Data Plane Development Kit (DPDK) for efficient userspace packet processing, while Extended Berkeley Packet Filter (eBPF) and Express Data Path (XDP) provide programmable, high-performance processing within the Linux networking stack.

As private 5G architectures increasingly converge radio processing, edge computing, and AI inference, the OS must expose the hardware primitives needed to allow diverse workloads to share infrastructure predictably and securely. Non-Uniform Memory Access (NUMA) awareness, hugepages, CPU affinity and isolation, device passthrough and Single Root Input/Output Virtualization (SR-IOV) can enable network functions and AI workloads to approach bare metal performance while maintaining resource boundaries through the virtualization and container stack.

Where the threat model requires protection from a potentially compromised host or hypervisor, confidential computing technologies can add hardware-assisted isolation for workloads. The OS therefore needs to provide not just hardware abstraction, but the mechanisms through which higher-level platforms can translate application requirements (e.g., latency, throughput, isolation, and locality) into enforceable resource policies.

Security and lifecycle management are equally important at the physically distributed edge. An OS for private 5G should establish a chain of trust from boot through runtime, combining secure boot, hardware-rooted trust, disk encryption, application confinement, and least-privilege controls with transactional software updates and reliable rollback. Ubuntu Core is an example of this security and lifecycle model, with application confinement, full-disk encryption (FDE), and transactional updates designed for devices that may operate remotely for long periods.

For larger private 5G deployments, vulnerability remediation must also minimize operational disruption. Linux Kernel Livepatch can address supported critical and high-severity kernel vulnerabilities without rebooting, reducing maintenance downtime as a result. In addition to this, Ubuntu Pro provides 10 years of security coverage, which can be extended to 15 years with the Legacy add-on. These capabilities are particularly valuable in environments where infrastructure is expected to remain security-maintained, predictable, and supportable for many years.

Edge AI inference in private 5G deployments

Private 5G networks can generate substantial uplink traffic, such as telemetry, video feeds, sensor data, and more. Sending all raw data to a centralized cloud can increase backhaul requirements, latency, and data and security exposure. Localizing AI inference at the edge can enable very low and more predictable end-to-end latency by keeping data close to where it is generated. A local 5G UPF can provide a direct user-plane path into an edge computing environment, allowing applications such as computer vision, defect detection, autonomous mobile robot trajectory planning, or to process data streams in milliseconds.

In emerging AI-RAN architectures, this convergence can extend to sharing accelerated compute infrastructure between RAN functions and AI workloads. GPUs and other accelerators can potentially support both radio processing and enterprise AI, with spare capacity made available to additional workloads when RAN demand permits. Industry demonstrations have already shown RAN and AI workloads running concurrently on shared GPU-accelerated platforms.

To integrate AI efficiently, the infrastructure must support containerized workloads seamlessly alongside network functions. Ubuntu Server provides the OS foundation for Private 5G and edge AI, with hardware enablement, security maintenance, and long-term enterprise support. For appliance-style edge deployments, Ubuntu Core offers a more minimal, immutable, and transactional model with secure boot, application confinement, and Over-the-Air (OTA) updates. MicroCloud can add lightweight infrastructure virtualization through LXD containers and VMs, while Canonical Kubernetes provides orchestration for cloud-native 5G Core and AI workloads.

This stack enables enterprises to run private 5G alongside edge AI workloads such as computer vision and robotics, while maintaining the performance, security, isolation, and lifecycle management required for industrial environments.

Conclusion

Private 5G can become more than a dedicated connectivity layer: it can provide the connectivity foundation for distributed vertical computing and AI. The strongest architectures will combine trusted OS foundations, efficient infrastructure virtualization, and cloud-native orchestration, so that compute resources can support both network functions and emerging workloads such as computer vision, robotics, and industrial AI. The objective should be to create an infrastructure platform that can evolve as radio, networking, compute, and AI requirements change, while retaining consistent security and lifecycle management across the estate.

Next steps

Learn how Canonical solutions provide a stable, validated, and open foundation for telco workloads.

[Ubuntu News] How a missing kernel flag broke FIPS-certified containers in managed Ku

Mon, 28 Sep 2026 07:59:02 -0200

A customer building a FedRAMP-compliant deployment found that Ubuntu Pro 22.04 FIPS container images were silently failing on standard, mainline Linux kernels, the kind used by managed Kubernetes environments such as AWS EKS and Fargate. The fix required a patch that preserved FIPS compliance without triggering months of recertification. This post explains what happened, why it matters for anyone running FIPS workloads in containerized cloud environments, and what Canonical changed as a result.

The problem: a kernel flag that doesn’t exist in the cloud

The customer was in the middle of a large FedRAMP migration across multiple platforms. Their containerized workloads relied on Ubuntu Pro 22.04 FIPS images, and the containers were failing in ways that pointed to a fundamental incompatibility rather than a configuration mistake.

The root cause was a hard dependency in libgcrypt20-fips on GRND_RESEED_ONLY, an Ubuntu-specific kernel flag introduced as part of Canonical’s FIPS implementation. The flag does not exist in standard mainline Linux kernels. Managed Kubernetes offerings from major cloud providers run mainline kernels, not Ubuntu FIPS kernels. When libgcrypt20-fips attempted to call getrandom() using GRND_RESEED_ONLY, the syscall returned an error on those kernels, and the container failed.

This wasn’t a misconfiguration. A fully FIPS-compliant host, a correctly built container, and an image identical to one working on a Jammy FIPS kernel would still fail, because the package was calling a syscall the underlying kernel didn’t support.

The customer arrived at this diagnosis themselves, supported by public bug reports and their own internal testing. They came to Canonical with specific package names, specific error conditions, and specific references, including bug 2055825.

Why this matters beyond one customer

This is a common architecture for any organisation under FedRAMP, FISMA, or DoD compliance requirements running Ubuntu Pro FIPS images on managed Kubernetes environments with mainline kernels. The assumption that a FIPS-certified image behaves consistently regardless of the underlying kernel is reasonable; before this fix, it wasn’t reliably true.

Escalation and investigation

Canonical Support escalated to the Canonical FIPS team, and Matthew, a Canonical support engineer, led the technical investigation.

The core challenge was finding a fix that did two things simultaneously:

Made libgcrypt20-fips, gnutls28, and ubuntu-fips work correctly on standard kernels without the GRND_RESEED_ONLY flag
Preserved FIPS compliance without requiring a full recertification cycle

FIPS certification is not a property you can alter lightly. Changes to cryptographic packages can invalidate certification, requiring months of revalidation through NIST’s (National Institute of Standards and Technology) CMVP (Cryptographic Module Validation Program) process. Any fix that broke certification would simply trade one blocker for another for customers with active compliance obligations.

Matthew’s patch resolved both constraints. It modified the packages’ behaviour when GRND_RESEED_ONLY was unavailable, allowing them to fall back correctly without compromising the cryptographic guarantees that underpin FIPS compliance.

Testing and release

Canonical provided the patched packages to the customer via a private PPA for validation. The customer tested the containers against their target environments and confirmed the fix worked.

Canonical then released the packages to the jammy-fips-updates and noble-fips-updates repositories. Customers running Ubuntu Pro 22.04 or 24.04 FIPS container images on standard cloud kernels should ensure their systems are pulling from jammy-fips-updates or noble-fips-updates respectively.

What this means for FIPS container deployments

No single layer told the full story here: the container looked correct, the host was FIPS-compliant, and the failure only showed up in the gap between a package assumption and a kernel that didn’t support it. That’s the part worth remembering: FIPS compliance in cloud-native environments depends on the interaction between certified packages and the underlying kernel, not just on using certified images.

Canonical Support provides access to expert engineers across the full open source stack, including the FIPS team. If you are working through a FIPS or FedRAMP deployment and running into compatibility issues, contact us or visit our Support page.

How a missing kernel flag broke FIPS-certified containers in managed Kubernetes

A customer building a FedRAMP-compliant deployment found that Ubuntu Pro 22.04 FIPS container images were silently failing on standard, mainline Linux kernels, the kind used by managed Kubernetes environments such as AWS EKS and Fargate. The fix required a patch that preserved FIPS compliance without triggering months of recertification. This post explains what happened, why it matters for anyone running FIPS workloads in containerized cloud environments, and what Canonical changed as a result.

The problem: a kernel flag that doesn’t exist in the cloud

The customer was in the middle of a large FedRAMP migration across multiple platforms. Their containerized workloads relied on Ubuntu Pro 22.04 FIPS images, and the containers were failing in ways that pointed to a fundamental incompatibility rather than a configuration mistake.

The root cause was a hard dependency in libgcrypt20-fips on GRND_RESEED_ONLY, an Ubuntu-specific kernel flag introduced as part of Canonical’s FIPS implementation. The flag does not exist in standard mainline Linux kernels. Managed Kubernetes offerings from major cloud providers run mainline kernels, not Ubuntu FIPS kernels. When libgcrypt20-fips attempted to call getrandom() using GRND_RESEED_ONLY, the syscall returned an error on those kernels, and the container failed.

This wasn’t a misconfiguration. A fully FIPS-compliant host, a correctly built container, and an image identical to one working on a Jammy FIPS kernel would still fail, because the package was calling a syscall the underlying kernel didn’t support.

The customer arrived at this diagnosis themselves, supported by public bug reports and their own internal testing. They came to Canonical with specific package names, specific error conditions, and specific references, including bug 2055825.

Why this matters beyond one customer

This is a common architecture for any organisation under FedRAMP, FISMA, or DoD compliance requirements running Ubuntu Pro FIPS images on managed Kubernetes environments with mainline kernels. The assumption that a FIPS-certified image behaves consistently regardless of the underlying kernel is reasonable; before this fix, it wasn’t reliably true.

Escalation and investigation

Canonical Support escalated to the Canonical FIPS team, and Matthew, a Canonical support engineer, led the technical investigation.

The core challenge was finding a fix that did two things simultaneously:

Made libgcrypt20-fips, gnutls28, and ubuntu-fips work correctly on standard kernels without the GRND_RESEED_ONLY flag
Preserved FIPS compliance without requiring a full recertification cycle