With these goals in mind, the Institute of Software, Chinese Academy of Sciences (ISCAS), launched the open source openRuyi Project to support the RISC-V software ecosystem across the entire stack. Built on a continuously evolving Linux system, openRuyi provides an operating system reference platform for early exploration and efficient validation of new RISC-V standards and features. The project aims to make a ready-to-use system environment a vehicle for putting specifications into practice and validating hardware and software together: new specifications and hardware features are implemented across firmware, kernels, toolchains, and application environments, then exercised with real workloads in AI inference, storage and networking, cloud native computing, and desktop graphics to assess how well the components work together and enable the hardware's full capabilities. Working with vendors and upstream communities, the project addresses the compatibility and performance issues revealed through this process, supporting RISC-V development from pre-silicon to post-silicon stages and building an engineering foundation for solving long-term ecosystem challenges.

As of September 30, 2026, openRuyi had published seven monthly rolling releases[1], bringing together ongoing work from firmware interfaces and kernels to application software stacks. Alongside adapting and integrating components within the system, the project improves its build and test environments through supporting projects such as RuyiRepo, RuyiCI, Ruyifirmware, development tools, and infrastructure. Multiple rounds of validation and iteration have produced a series of releases supporting early hardware validation, software development, and application deployment.

How openRuyi brings ecosystem development efforts together

Four Core Strengths​

Ready to Use: Getting RISC-V Hardware Up and Running Faster​

openRuyi works across the stack to make RISC-V systems usable out of the box, helping users move from receiving hardware to development and everyday use more quickly. To meet the differing needs of servers, desktops, development boards, and FPGAs, the project adapts firmware, operating systems, and application environments together, supporting both standard interfaces and customized boot solutions. openRuyi Zero targets system bring-up and kernel development for CPUs and SoCs, particularly in pre-silicon FPGA prototyping environments. It provides the software needed for validation and supports using custom kernels and modules. For development board users, Ruyifirmware provides open firmware together with build, flashing, and recovery procedures, simplifying boot environment deployment and debugging.

openRuyi release artifacts designed for different use cases

Putting Specifications into Practice: Supporting New Upstream Standards as They Evolve​

openRuyi tracks new upstream RISC-V specifications and provides a runnable, verifiable system platform for their implementation and evolution. To connect firmware development with system adaptation, the project actively contributes to extending and validating tests for the RISC-V BRS specification. It has also developed the openRuyi RISC-V Firmware Interface Specification[2] based on practical system requirements, translating upstream boot and hardware description requirements into interface contracts and system validation. For instruction set architecture testing, the team continuously contributes to upstream ACT development and maintenance, expands test coverage, and works to integrate an ACT development environment into openRuyi, providing software support for developing and running tests.

Upstream Collaboration: Keeping Pace with Technology and Sharing Validation Results​

openRuyi continuously contributes enablement patches, fixes, and regression tests to key upstream projects, and takes on or participates in RISC-V architecture maintenance responsibilities in projects such as DPDK, ISA-L, and Go. To address device support, IOMMU requirements, hardware errata, and related needs, the project integrates 207 patches ahead of upstream inclusion in its kernel based on the latest release, and 766 in its kernel based on the latest LTS release.

RuyiCI prioritizes critical dependencies in major software stacks, including storage and networking, virtualization, and AI. The team has provided natively integrated RISC-V CI capabilities for projects such as OpenSSL, ISA-L, rust-vmm, and Cloud Hypervisor. It continues to maintain these environments and run regression tests on real hardware, reporting compatibility and performance changes. The team also carries out ongoing RISC-V CI adaptation and execution validation for important projects such as PyTorch and Rust, tracking the latest upstream changes and identifying issues affecting RISC-V.

DPDK testing exposed a GCC sign-extension bug that caused an infinite loop; the fix and regression test have been merged into GCC mainline

Joint Validation with Vendors: Turning Platform Experience into Shared Software Improvements​

openRuyi collaborates with major RISC-V vendors and organizations, including the Beijing Institute of Open Source Chip, ZTE, T-Head (DAMO Academy), SpacemiT, SOPHGO, and Lanxin Computing. Together, they adapt, validate, and optimize the software environments supporting hardware platforms, turning platform experience into system improvements that others can share. The project works with the XiangShan team on joint validation of system operation on FPGAs and Java workloads, continuously improving boot, kernel, and application compatibility. Java optimization patches contributed by ZTE have also been merged into openRuyi and are delivered to users through system releases.

Computational performance validation on a V100 using XSCC-based openRuyi

Building Software Stacks Around Ecosystem Challenges​

Missing functionality, runtime failures, and performance bottlenecks in real applications often involve hardware and software beyond the application itself. Resolving them requires tracing dependencies to identify root causes and working with vendors and upstream communities on fixes and optimizations.

AI: Host Compatibility Issues in GPU Inference​

Although inference computation runs on GPUs, successful operation depends heavily on the compatibility of the RISC-V host software stack. During the ROCm port to RISC-V, runtime memory access faults required fixes to kernel memory management. While adapting core components such as HIP and ROCr, the team also reviewed the dependencies among compilers, compute libraries, and runtimes, organizing the complex stack into a maintainable, deployable set of components. openRuyi integrates ROCm and its supporting software to provide an environment for running models and deploying inference on validated combinations of RISC-V hosts and AMD GPUs.

An inference demonstration using vLLM with ROCm on RVA23 hardware

Storage and Networking: Are RVV Optimizations Actually Taking Effect?​

While building a Ceph storage validation environment for RISC-V, the team found that defects in underlying firmware, kernels, or compilers could cause incorrect data writes and service stalls. Container configurations could also prevent existing vector optimizations from taking effect. Starting with real storage workloads, openRuyi follows Ceph's dependencies to validate I/O frameworks, acceleration libraries, toolchains, and deployment environments. The project works with vendors to identify hardware and software issues and contributes RISC-V fixes and regression tests upstream.

openRuyi's RISC-V software ecosystem work supporting Ceph

Virtualization and Cloud Native Computing: How Close Is RISC-V KVM to Cloud Platform Deployment?​

RISC-V KVM is no longer marked experimental upstream, but deployments on real hardware in some cloud platform scenarios still reveal issues such as stalled virtual machine startup, restrictions on container execution, and missing software dependencies. The team uses Kubernetes to validate container orchestration and application deployment, and Cloudpods to test virtual machine creation, startup, and management. By following actual execution flows, it traces integration problems across firmware, QEMU, kernels, and foundational software. openRuyi also works with hardware vendors on diagnosis and validation, continuously improving system configuration, component dependencies, and deployment procedures while contributing improvements upstream.

Adapting and deploying openRuyi with Cloudpods on a K3 RISC-V server

Desktop: Having a GPU Does Not Always Mean Having Graphics Acceleration​

Incomplete open source driver support for some GPUs has long been a known issue in the RISC-V desktop ecosystem. The team works with Imagination and the Mesa community on using Zink to translate OpenGL calls into Vulkan, while improving the integration between rendering and display so that more existing graphics applications can benefit from GPU acceleration through open source drivers. The team has run complex graphics applications on real hardware, and the resulting fixes and adaptations are being merged into upstream Mesa.

openRuyi provides a full KDE desktop experience on RISC-V and continuously improves runtime efficiency

openRuyi turns ecosystem challenges into concrete application requirements and uses them to design validation methods. By tracing hardware and software dependencies, it identifies problems and works with vendors and upstream communities on adaptation, fixes, and optimization. The project continuously contributes patches and regression tests upstream, incorporates validated improvements into the system through rolling integration, and uses hardware tests to track compatibility and performance changes in subsequent versions. System environments, build and test facilities, and validation results are open to the community, enabling others to reuse this accumulated engineering work.

Long-Term Ecosystem Development Goals​

Grounded in engineering practice, the openRuyi Project continues to build an open platform for collaboration and research serving RISC-V hardware vendors, upstream software developers, and researchers. It shares system environments, engineering infrastructure, and validation results, while pursuing long-term research on the following questions to guide ecosystem development:

• How can a standardized compatibility baseline support targeted optimization for different RISC-V hardware, balancing software reuse across platforms, the use of distinctive hardware capabilities, and the cost of adaptation and maintenance?
• How can structured knowledge, reusable automated workflows, and feedback from hardware testing reduce repeated exploration and rework in RISC-V ecosystem development, improving the efficiency and reliability of AI-assisted software adaptation and maintenance?
• How can RISC-V chip validation methods be transferred across development stages and hardware platforms, allowing continued reuse of test cases and issue reproduction procedures, reducing repeated adaptation work, and shortening the time needed to diagnose and fix hardware-software compatibility issues?
• How can continuous validation and comparative evaluation of emerging RISC-V software stacks provide an engineering basis for component selection, integration, and optimization in next-generation operating systems developed in China?

As this work progresses, openRuyi will publish a series of articles sharing its approach to ecosystem development in key areas and offering insights for the broader RISC-V community.

Related Links​

[1] openRuyi release announcements: https://www.openruyi.cn/news/

[2] openRuyi RISC-V Firmware Interface Specification: https://www.openruyi.cn/docs/guide/recommended-practices/openruyi-risc-v-firmware-interface-specification/standard-server-platform-firmware-interface-specification/

Ruyi Firmware has been validated on SpacemiT K3 Pico ITX hardware, demonstrating the complete process of booting openRuyi from firmware through to a running desktop environment.

01 / ECOSYSTEM FOUNDATION

Building an Open, Maintainable RISC-V Firmware Stack​

Firmware is essential infrastructure connecting hardware and the operating system. It initializes hardware and hands control to the next stages of the boot process, and its implementation also affects operating system porting and maintenance. As the RISC-V ecosystem develops, hardware platforms have adopted different firmware architectures and boot flows, including U-Boot-based boot processes and UEFI environments provided by EDK2.

These differences increase the work required to support an operating system across platforms. When porting an operating system, developers often need to adjust device trees, boot parameters, and firmware configurations for the target hardware, while also learning the corresponding flashing and recovery procedures. When a system fails to boot, troubleshooting may require examining firmware initialization, OpenSBI, the bootloader, and the operating system in turn, making diagnosis and ongoing maintenance more complex.

To address these challenges, openRuyi introduces Ruyi Firmware. Through an open firmware build process and a consistent environment for software adaptation, the project aims to make RISC-V platform development, porting, and validation more accessible, while providing developers with an open, customizable, and maintainable firmware foundation.

02 / UEFI COMPATIBILITY

Improving UEFI Graphics Compatibility During RISC-V Boot​

One of the key capabilities in Ruyi Firmware 20261015 is compatibility with x64 UEFI graphics components. Some PCIe expansion devices, including graphics cards, rely on UEFI graphics drivers during startup, and some of these components are compiled for the x64 architecture. Because RISC-V and x86 use different instruction sets, these x64 UEFI components cannot execute directly on RISC-V, which may affect device initialization during the UEFI stage.

This release integrates MultiArchUefiPkg. Its optional x64emu component allows a RISC-V UEFI environment to execute certain x64 UEFI graphics components, providing a compatibility solution during device startup.

x64emu has been tested with the AMD Radeon RX 6400, validating compatibility with x64 UEFI graphics components in a RISC-V boot environment.

In addition, because the K3 platform does not support DMA32, it cannot properly use the RX 550 graphics card's built-in option ROM. This release integrates an AMD AArch64 option ROM EFI component as an alternative, resolving display compatibility issues for the RX 550 during the EDK2 stage. The firmware also supports the K3 platform's native display controller driver, enabling display output during the EDK2 stage.

03 / OPEN FIRMWARE

An Open Source Firmware Architecture and Complete Build Process​

Ruyi Firmware is openRuyi's open firmware solution for RISC-V platforms. It combines coreboot, OpenSBI, and EDK2, with a publicly available build and packaging process that developers can use to build and extend the firmware from source.

The architecture covers the complete firmware flow, from hardware initialization to the UEFI boot environment, providing a common firmware foundation for openRuyi porting and development. coreboot contributes to the underlying firmware, OpenSBI provides the SBI runtime services required by RISC-V systems, and EDK2 supplies the UEFI environment. Developers can use the published source code and build configurations for customization, debugging, and feature validation, without being limited to prebuilt firmware.

Ruyi Firmware boot screen

The firmware provides a UEFI setup interface, a boot menu, and an interactive shell. These tools allow users to adjust firmware settings, select boot entries, inspect devices, and troubleshoot issues before the operating system starts.

UEFI Boot Manager menu

04 / FLASH & RECOVERY

Complete Firmware Update and Recovery Procedures​

Unlike ordinary software updates, flashing firmware directly affects how a device boots. Reliable update and recovery mechanisms are therefore an essential part of delivering firmware.

This release provides two types of images: normal-spi.bin and recovery-bootrom.bin. Firmware can be flashed over USB Fastboot, and the documentation also describes how to use BootROM to enter the recovery boot process. Normal firmware updates preserve UEFI variables, reducing the need to reconfigure boot entries. After flashing, readback verification confirms the result.

For developers who need to test firmware repeatedly, these procedures cover the main steps from compilation and flashing to recovery. This helps developers iterate on firmware more safely and speeds up RISC-V platform adaptation and troubleshooting.

05 / RELEASE PACKAGE

Build Configurations for Everyday Use and Debugging​

To meet the needs of different development stages, Ruyi Firmware provides RELEASE and DEBUG builds, resulting in two firmware packages.

DEBUG builds are intended for firmware debugging. The default configuration is suitable for scenarios that do not require x64 emulation; the graphics emulation driver must be enabled manually. These build and configuration choices provide flexibility for development validation, system tuning, and everyday use.

This update also adds CPU mode configuration support. UEFI Setup allows users to select among X100 only (default), X100 + A100, and A100 only modes. A100 only mode supports vector extensions, providing a test environment for validating system operation with a vector length (VLEN) of 1024 bits.

Ruyi Firmware 20261014 CPU mode settings

Ruyi Firmware 20261015 Platform Settings screen

The build repository is licensed under MIT, pins component versions through Git submodules, and uses GitHub Actions for automated builds. Release packages also include checksums, build information, and flashing instructions to help users verify files, reproduce environments, and trace issues.

06 / HARDWARE DEMO

Hardware Demonstration: Running openRuyi Creek​

Ruyi Firmware has been validated on the SpacemiT K3 Pico ITX platform and supports booting and running openRuyi Creek. Using this firmware, openRuyi Creek successfully boots into a Wayland desktop environment and runs the glmark2-wayland graphics benchmark. The demonstration also shows OpenGL rendering information and system status, offering a direct view of the system's graphics stack in operation.

openRuyi@SpacemiT K3 Pico ITX

openRuyi Creek in operation: Wayland desktop, glmark2-wayland, and system information

The project has also published a hardware demonstration video, "SpacemiT K3 EDK2 with openRuyi," showing the complete process from firmware startup to a running openRuyi system on the K3 platform.

Hardware demonstration on Bilibili:

https://www.bilibili.com/video/BV1pdpZ6hEnF

Download and Contribute​

Ruyi Firmware's source code, build instructions, and firmware release packages are publicly available. You are welcome to download and try the firmware, report issues through the project repository, or contribute to future improvements.

Ruyi Firmware releases:

https://github.com/openRuyi-Project/ruyifirmware/releases

Project repository and build instructions:

https://github.com/openRuyi-Project/ruyifirmware

RVA23: Improving Build, Data Plane, and Container Support​

The RVA23 improvements in this release cover three areas: BCLR code generation fixes, RVV-based data-plane paths, and container hardware probing. On the compilation side, the release fixes a BCLR code generation problem that could break correctness. On the runtime side, OpenJDK and DPDK gain vectorized optimization paths. On the container side, allowing riscv_hwprobe lets programs inside containers read real CPU capabilities and choose the matching optimization branch.

Compilers and Data Plane​

Container Hardware Probing: Measured on SpacemiT V100​

Measured inside a container on SpacemiT V100 (RVA23): after allowing riscv_hwprobe, OpenSSL 3.6.3 recognizes and enables vector-crypto extensions such as Zvkned, Zvknhb, and Zvksed, and zlib-ng enables the Zbc-accelerated crc32. Verified with openssl, python3 zlib, and pigz.

Cloudpods 4.0.3: A Multi-Cloud and Private-Cloud Platform in the Distribution​

Users can install the Cloudpods core components from the openRuyi repository, targeting high-availability multi-node and bare-metal deployment forms.

• The build-time dependency closure completed around it consists mainly of Go source packages: containernetworking-plugins (a runtime package providing the CNI binaries and a DHCP systemd unit), the Kubernetes KMS API, the konnectivity client, the etcd v3 client and raft, cloud provider SDKs, and client libraries such as Vault and VictoriaMetrics. These are build-time dependencies and do not include the corresponding server programs.

Ceph and SPDK: Block Storage and User-Space Storage Backends​

SPDK can directly attach to local io_uring and Ceph RBD backends and enables a remote management agent; Ceph service accounts, mgr modules, and CephFS components are available.

SPDK (25.09, enabling --with-uring --with-rbd --with-sma)​

• Adds an io_uring bdev module (local asynchronous block device).
• Adds a Ceph RBD bdev module (attaching to Ceph backends).
• Enables SMA (Storage Management Agent, remote storage management).
• Fixes spdk-tools dependencies: adds python-configshell-fb and upgrades python-grpcio-tools to 1.82.1 to match protobuf 7.

Ceph (21.3.0+git20260917.35ae586), updated to an upstream main-branch development snapshot (v21.3.0-3295-g35ae586)​

• Switches to systemd-sysusers to create the ceph and cephadm users; the previous %pre called shadow's useradd without declaring the dependency, which left /var/lib/ceph owned by root.
• Adds cherrypy and pyyaml for mgr modules, so the prometheus module can be enabled.
• Backports fixes for ceph-fuse@.service, cephfs-shell, and ceph-crash.

Measured on SpacemiT V100 (RVA23) with a 3-mon / 9-OSD (NVMe) three-replica cluster​

• RBD (librbd / krbd / rbd-nbd), CephFS (kernel and FUSE clients, snapshots, quotas, subvolumes), and RGW (S3 multipart / versioning / lifecycle) all passed functional verification.
• Erasure coding isa / jerasure / clay and snappy / zstd / lz4 / zlib compression are available.
• Common mgr modules can be enabled; prometheus and ceph-exporter export metrics, and monitoring is provided through the CLI and Prometheus; cephadm can bootstrap a single node and manage mon / mgr.
• SPDK io_uring bdev and RBD bdev run on RISC-V; the SMA gRPC interface (device creation, volume attachment, QoS) is verified as usable.

Graphics Stack: NVK Included in the Build, Vulkan SDK Unified at 1.4.357.0​

NVK, the open-source NVIDIA Vulkan driver, is included in the build for the first time.

• Mesa 26.2.2, with NVK included in the build (-Dvulkan-drivers=...,nouveau). NVK is produced together with mesa-vulkan-drivers. Hardware runtime and CTS verification will follow in a later release.
• Nine Vulkan SDK components are upgraded to 1.4.357.0 in unison.
• Adds vkmark: a lightweight Vulkan benchmark suite supporting X11, Wayland, KMS, direct display, and headless modes; backports a lavapipe crash fix.
• glmark2 enables GBM variants (headless/DRM scenarios); adds assimp and glm (3D graphics development).
• Qt 6 Base enables the Accessibility API.

Go 1.27: Cloud-Native and Observability Build Environment​

Solutions such as Cloudpods, MinIO/KES, Kubernetes, OpenTelemetry, and multi-cloud SDKs can now resolve dependencies, build offline, and be maintained as a coherent set on openRuyi.

• Go toolchain: 1.27.0 → 1.27.1.
• September added 325 Go source packages and updated 203 Go source packages (of which 30 were both added and updated within September, and 173 were updated only).
• Go 1.27 compatibility fixes: #1254 fixes 11 modules, #1271 fixes several modules, and #1279 fixes go-honnef-go-tools 0.8.1, gonum/plot, go4, and the Azure AD MSAL x/sync dependency.
• The solutions these modules serve (grouped by PR):
  • MinIO/KES object storage: #1243, #1247, #1248, #1259, #1262, #1266, #1267.
  • Prometheus v3.13.1 observability: #994, #1117–#1126 (layered by dependency DAG), #1242.
  • Kubernetes and containers: konnectivity-client, go-k8s-kms, CRI, api-machinery, kube-openapi, structured-merge-diff, CNI, containerd, Moby, OpenShift API, etcd raft.
  • Multi-cloud and secrets: Azure SDK/Storage/Key Vault, GCP Storage/Compute/Logging/Monitoring/IAM/Secret Manager, AWS SDK, HashiCorp Vault/Consul, DigitalOcean/Linode/Vultr.
  • gRPC/Protobuf: gRPC, protobuf, Envoy control-plane, xDS, protovalidate, CEL, JSON Patch.
• Monthly routine update volume for verification: #1257 touches 72 Go packages, #1263 touches 80, and #1280 touches 32.

Software Supply Chain: Repository GPG Signature Verification and Security Updates​

Packages in the repository enable GPG verification by default, so the install and upgrade paths can validate signatures; affected packages moved to upstream versions that contain the fixes.

• openruyi-repos ships RPM-GPG-KEY-openruyi and RPM-GPG-KEY-openruyi-obs, and writes gpgcheck=1 and gpgkey=file://.../RPM-GPG-KEY-openruyi* into the repo file.
• rpm adds a gnupg runtime dependency.
• openruyi-minimal adds gnupg to its recommended dependencies.

Security Updates​

KDE Desktop​

• 64 KDE Frameworks components updated to 6.29
• 13 KDE Gear components updated to 26.08.1: dolphin, konsole, kate, falkon, konqueror, kdialog, kio-extras, dolphin-plugins, kaccounts-providers, kaccounts-integration, baloo-widgets, kpmcore, signon-kwallet-extension

Experimental RVA20 Release​

This release also offers an experimental RVA20 build, available as Server, Container, and Desktop; Zero is not provided for this variant. you can try it from the: openRuyi RVA20 release site.

Download link​

openRuyi continues to provide four builds for different scenarios: Server, Container, Desktop, and Zero (BSP validation). You can download this release from the openRuyi release site.

Existing users can complete the upgrade by simply running dnf update.

We welcome community testing and feedback on this release.

Changelog​

For the full package-level change details, see the complete changelog below, organized into updated and added packages.

The release delivers a security-heavy package refresh, advances RISC-V and RVA23 integration, expands cloud-native and accelerated-computing capabilities, and updates the kernel, toolchain, scientific stack, and KDE desktop.

Highlights​

• Toolchain, runtime, and build infrastructure: We updated GCC 16 from 16.1.0 to 16.2.0, glibc from 2.43 to 2.44, and Rust from 1.95.0 to 1.97.1. Distribution engineering work also reduces unnecessary static LLVM build dependencies and fixes compatibility fallout from the glibc transition.

• Kernel and core platform refresh: We updated the mainline kernel from 7.1.4 to 7.2 and the LTS kernel from 6.18.39 to 6.18.46. This release also introduces a kernel production and conversion workflow built around kernel-team-tools: downstream changes for both kernel branches are tracked, selected, and organized against their upstream baselines, then exported as ordered patch series and kernel configurations for x86_64, generic RISC-V, and RVA20, and published as reusable archives for RPM builds. The initial migration covered 244 mainline patches, 560 LTS patches, and two sets of multi-architecture configurations. The refreshed kernels further broaden RISC-V platform support across SpacemiT, Sophgo, T-Head, and UltraRISC systems, spanning PCIe, USB, storage, networking, display, and other SoC integration areas. Dracut also moved from 111 to 112, incorporating an upstream fix that improves compatibility with glibc 2.44.

• RISC-V and RVA23 integration: LLVM 22 gained fixes for vectorization crashes and stack-probing register clobbering on RISC-V, while OpenBLAS now selects its ZVL128B target for RVA23 builds. The Rust QuickJS bindings also gained riscv64gc and riscv64a23 support, closing an architecture-specific gap without changing the shared LP64D ABI.

• Cloud-native, containers, and storage: openRuyi adds Kubernetes 1.35.5 and containerd 2.3.3, together with networking, storage, CRI, and cluster-validation tooling needed for a usable cloud-native stack.

• Scientific computing and HPC expansion: The release substantially expands the scientific Python environment around Jupyter and Dask, completing the dependency closure for distributed data processing, numerical computing, geospatial, astronomy, and image-analysis workloads. OpenMPI 5.0.10, together with its PMIx and PRRTE runtime components, also adds an MPI stack for distributed and high-performance computing.

• AI and accelerated computing: The release adds the ROCm 7.2.4 library stack and enables a ROCm backend in PyTorch 2.13.0. vLLM joins openRuyi with CPU and ROCm variants, backed by coordinated ABI and multibuild work across its compiler and vision dependencies.

• Desktop and graphical stack improvements: KDE Frameworks advances from 6.27.0 to 6.28.0, and KDE Plasma moves from 6.7.1 to 6.7.4. GIMP 3.2.0 joins the distribution with its image-processing dependency stack, broadening the user-facing graphical software selection.

Security Updates​

• curl was updated to 8.21.0, fixing the 18 published advisories that affected 8.20.0: CVE-2026-12064, CVE-2026-11856, CVE-2026-11586, CVE-2026-11564, CVE-2026-11352, CVE-2026-10536, CVE-2026-9547, CVE-2026-9546, CVE-2026-9545, CVE-2026-9080, CVE-2026-9079, CVE-2026-8932, CVE-2026-8927, CVE-2026-8926, CVE-2026-8925, CVE-2026-8924, CVE-2026-8458, CVE-2026-8286.

• openjdk-17, openjdk-21, openjdk-25, and openjdk-latest was updated to 17.0.20.8, 21.0.12.8, 25.0.4.7, and 26.0.2.10, respectively. The updates incorporate the July 2026 Java SE CPU fixes for CVE-2026-62574, CVE-2026-41254, CVE-2026-47063, CVE-2026-60147, CVE-2026-46968, CVE-2026-47027, CVE-2026-47021, CVE-2026-46917, CVE-2026-47059, CVE-2026-47010.

• dotnet10.0 was updated to 10.0.110, incorporating the .NET 10.0.10 security fixes for CVE-2026-50651, CVE-2026-50526, CVE-2026-50524, CVE-2026-50646, CVE-2026-50649, CVE-2026-50650, CVE-2026-56158, CVE-2026-47302, CVE-2026-50648, CVE-2026-50527, CVE-2026-47304, CVE-2026-50525, CVE-2026-57108, CVE-2026-50528, CVE-2026-50659, CVE-2026-47300, CVE-2026-47303.

• openssh was updated to10.5p1, incorporating upstream security fixes for agent-forwarding restrictions, remote file-copy path handling, authentication-delay enforcement, tunnel restrictions, denial-of-service conditions, and client memory-safety defects.

• php was updated to 8.5.9, fixing CVE-2026-14355, CVE-2026-17544, CVE-2026-9672, CVE-2026-17543, CVE-2026-7260.

• pcre2 was updated to 10.47, fixing CVE-2025-58050.

• libseccomp was updated to 2.6.1, addressing GHSA-4q85-33p6-j5g6, GHSA-46fr-jh49-xvhx, GHSA-2hqh-5c36-grrm.

• python-diffusers was updated to 0.38.0, fixing CVE-2026-44513, CVE-2026-44827, GHSA-7wx4-6vff-v64p.

• python-gradio-client was updated to 2.6.0 under a security-focused packaging change.

• python-hpack was updated to 4.2.0, addressing GHSA-8v8h-hg4w-mvq2.

• python-icalendar was updated to 7.2.2, addressing GHSA-cv84-9p8j-fj68.

• python-idna was updated to 3.18, fixing CVE-2026-45409.

• python-joserfc was updated to 1.7.4, fixing CVE-2026-49852, CVE-2026-48990.

• python-langsmith was updated to 0.11.0, addressing GHSA-f4xh-w4cj-qxq8.

• python-lxml was updated to 6.1.1, fixing CVE-2026-41066.

• python-msgpack was updated to 1.2.1, addressing GHSA-6v7p-g79w-8964.

• python-nltk was updated to 3.10.3, fixing CVE-2026-54293.

• python-protobuf was updated to 7.35.1, fixing CVE-2026-0994.

• python-pydantic-settings was updated to 2.15.0, addressing GHSA-4xgf-cpjx-pc3j.

• python-pyjwt was updated to 2.13.0, fixing CVE-2026-48522, CVE-2026-48523, CVE-2026-48524, CVE-2026-48525, CVE-2026-48526.

• python-python-multipart was updated to 0.0.32, fixing CVE-2026-40347, CVE-2026-42561, CVE-2026-53537, CVE-2026-53538, CVE-2026-53539, CVE-2026-53540.

• python-sagemaker-core was updated to 2.20.0, fixing CVE-2026-1777, CVE-2026-1778, CVE-2024-34072, CVE-2024-34073.

• python-starlette was updated to 1.6.0, fixing CVE-2026-48710, CVE-2026-48817, CVE-2026-48818, CVE-2026-54282, CVE-2026-54283.

• python-tornado was updated to 6.5.8, fixing CVE-2026-31958, CVE-2026-35536, GHSA-3x9g-8vmp-wqvf, GHSA-78cv-mqj4-43f7, GHSA-cx3h-4qpv-8hc9, GHSA-mgf9-4vpg-hj56, GHSA-pw6j-qg29-8w7f.

• python-wheel was updated to 0.48.0, fixing CVE-2026-24049.

We continue to provide four editions for different scenarios: Server, Container, Desktop, and Zero (BSP validation). You can download it from the openRuyi release site.

For existing users, simpily do dnf update and you're done!

We welcome the community to test, integrate, and provide feedback on this release.

Changelog​

For readers who need the complete package-level details, the full changelog is grouped below by updated and newly added packages.

In this release, openRuyi strengthens security across web and language runtimes, advances RISC-V platform integration, refreshes the kernel, desktop, Qt, ROCm, and build stacks, and adds substantial developer and publishing tooling.

Highlights​

• RISC-V toolchain and code generation: Go now selects the RVA23 profile through GORISCV64=rva23u64 for RVA23 builds while retaining a correct RVA20 fallback. GCC 15 gained a backported fix for incorrect NaN handling in auto-vectorized fmin() and fmax().

• Kernel and RISC-V platform integration: We updated the mainline kernel from 7.1.2 to 7.1.4 and the LTS kernel from 6.18.34 to 6.18.39. Patch and configuration refreshes broaden support across Sophgo, SpacemiT, T-Head, and UltraRISC systems, including PCIe, USB, storage, graphics, networking, ACPI, and board enablement.

• RISC-V cryptography and runtime performance: OpenSSL gained RISC-V backports for SHA-256 instruction scheduling and AES, SM4, and SM2 acceleration without a version change. jemalloc adds a RISC-V assembly path, while rocr-runtime corrects zicbom handling on RVA20 systems.

• Desktop and graphical stack improvements: We refreshed KDE Frameworks from 6.26.0 to 6.27.0, Plasma from 6.6.5 to 6.7.1, and Qt from 6.10.1 to 6.11.1. The coordinated update advances the Wayland-facing desktop stack and introduces a Plasma-native login manager, while package-level fixes display startup behavior.

• Accelerated computing and AI tooling: We updated the ROCm stack to 7.2.4 and aligned it with LLVM 22. New Triton and timm packages expand distribution-managed AI compilation and computer-vision workflows.

• Packaging, build, and virtualization infrastructure: RPM moved from 4.20.1 to 6.0.1, obs-build moved from 20250829 to 20260623, and the release adds virtiofsd.

• TeX and publishing stack integration: The release adds TeX Live 2026 together with a separately packaged data tree. The integration splits collections into manageable subpackages and enables LuaJIT support on RISC-V.

Security Updates​

• The python-aiohttp was updated to 3.14.1, fixing CVE-2026-54279, CVE-2026-34514, CVE-2026-34517, CVE-2026-54273, CVE-2026-54275, CVE-2026-34520, CVE-2026-54277, CVE-2026-34518, CVE-2026-54280, CVE-2026-34525, CVE-2026-54278, CVE-2026-34513, CVE-2026-47265, CVE-2026-54276, CVE-2026-34993, CVE-2026-34516, CVE-2026-50269, CVE-2026-34519, CVE-2026-34515, CVE-2026-22815, CVE-2026-54274.

• The python-authlib was updated to 1.7.2, fixing CVE-2026-41425, CVE-2026-44681.

• The python-beaker was updated to 1.14.1, fixing CVE-2013-7489.

• The python-curl-cffi was updated to 0.15.0, fixing CVE-2026-33752.

• The python-django was updated to 5.2.14, fixing CVE-2026-6907, CVE-2026-35192, CVE-2026-5766, CVE-2026-35193, CVE-2026-48587, CVE-2026-6873, CVE-2026-7666, CVE-2026-8404.

• The Go update was updated to 1.26.5, fixing CVE-2026-39822 in os.Root path handling and CVE-2026-42505 in TLS Encrypted Client Hello privacy protection.

• The NGINX update was updated to 1.31.3, fixing CVE-2026-42533.

• The libssh was update to 0.11.5, fixing CVE-2026-15370, CVE-2026-59843, CVE-2026-59844, CVE-2026-59845, CVE-2026-59846, CVE-2026-59847, CVE-2026-59848, CVE-2026-59849, CVE-2026-59850.

We continue to provide four editions for different scenarios: Server, Container, Desktop, and Zero (BSP validation). You can download it from the openRuyi release site.

For existing users, simpily do dnf update and you're done!

We welcome the community to test, integrate, and provide feedback on this release.

Changelog​

For readers who need the complete package-level details, the full changelog is grouped below by updated and newly added packages.

In this release, openRuyi strengthens security maintenance, desktop usability, RISC-V kernel support, virtualization and the package ecosystem.

Highlights​

• Security-focused package refresh: We refreshed a broad set of security-sensitive packages, including Avahi, PHP, and OpenSSL. The package refresh closes numerous documented CVE while also moving several network-facing tools to newer upstream maintenance releases.

• Toolchain, runtime, and build infrastructure: We updated Go, Rust, and LLVM. Rust now selects riscv64a23-unknown-linux-gnu for RVA23 builds, so the default Rust target follows the rva23 project profile instead of the older generic riscv64gc target. The release also improves LLVM default-package wiring, Rust RPM macros, and package-build tooling so developers can depend on stable, unversioned toolchain interfaces where appropriate.

• Kernel and RISC-V platform integration: We updated the mainline kernel from 7.0.10 to 7.1.2 and the LTS kernels from 6.18.33 to 6.18.34, following cleanup around flavored-kernel versioning, /lib/modules ownership, and safer kernel-install behavior. QEMU moved from 10.2.0 to 11.0.1 with RISC-V KVM ACPI-table fixes, while systemd gained a RISC-V UEFI compliance patch for systemd-boot.

• Desktop and graphical stack improvements: We updated KDE Frameworks, Plasma, and KDE Applications. The release also strengthens the Wayland desktop base through Labwc and wlroots updates and adds the Fcitx 5 input method stack for a more complete desktop experience.

• Virtualization, storage, and observability: We updated Ceph, Cloud Hypervisor, and added Kata Containers with Cloud Hypervisor support on RISC-V. The release also adds bpftrace and expands Prometheus service-discovery Go dependencies, improving low-level tracing, storage, and cloud-native integration.

• AI, data, and packaging quality: The release adds user-facing AI and data packages such as PaddlePaddle, Paddle2ONNX, and the OpenAI Python SDK, while keeping lower-level language dependencies in the Changelog. Packaging reliability also improves through TMT, rpminspect, setuptools compatibility fixes, and broader BuildSystem modernization.

• Installation and provisioning experience: Install ISO images now support cloud-init and automatic root filesystem expansion, improving unattended installation and VM or cloud deployment workflows.

Security Updates​

• linux was updated to 7.1.2, bringing the latest 7.1 stable kernel fixes, including mitigation for CVE-2025-10263 and follow-up hardening around CVE-2026-43500 and CVE-2026-46300.

• perl-IO-Compress was updated to 2.220, fixing CVE-2026-48959, CVE-2026-48961, CVE-2026-48962.

• dropbear was updated to 2026.91, fixing CVE-2026-35385 and CVE-2019-6111.

• xz was updated to 5.8.3, fixing CVE-2026-34743.

• vim was updated to 9.2.0593, fixing CVE-2026-47162 and CVE-2026-47167.

• php was updated to 8.5.7, fixing CVE-2025-14177, CVE-2025-14178, CVE-2025-14179, CVE-2025-14180, CVE-2025-67899, CVE-2026-6104, CVE-2026-6722, CVE-2026-6735, CVE-2026-7258, CVE-2026-7259, CVE-2026-7261, CVE-2026-7262, CVE-2026-7263, CVE-2026-7568, CVE-2026-29078, CVE-2026-29079, CVE-2026-42371, CVE-2026-44927, CVE-2026-44928.

• musl was updated to 1.2.6, fixing CVE-2025-26519.

• iperf was updated to 3.21, fixing CVE-2025-54349, CVE-2025-54350, and CVE-2025-54351.

• openssl was updated to 3.6.3, fixing CVE-2026-45447.

• ffmpeg was updated to 8.1.2, fixing CVE-2026-8461.

• avahi was updated to 0.9~rc4, fixing CVE-2025-68471, CVE-2025-68468, CVE-2026-24401, CVE-2025-68276, CVE-2021-3468, CVE-2024-52616, CVE-2024-2699, CVE-2026-34933, CVE-2024-52615.

• cockpit was updated to 364, fixing CVE-2026-4802 and CVE-2026-4631.

• cpp-httplib was updated to 0.48.0, fixing CVE-2026-54919.

• go was updated to 1.26.4, fixing CVE-2026-4250, CVE-2026-42507, CVE-2026-27145.

We continue to provide four editions for different scenarios: Server, Container, Desktop, and Zero (BSP validation). You can download it from the openRuyi release site.

We welcome the community to test, integrate, and provide feedback on this release.

Changelog​

For readers who need the complete package-level details, the full changelog is grouped below by updated and newly added packages.

This month, openRuyi continued to expand the desktop experience, core system stack, and package ecosystem for RISC-V platforms.

Highlights​

• KDE desktop environment: We have introduced a KDE-based desktop experience for openRuyi. This package now includes essential Plasma components and basic KDE applications, providing users with a more complete graphical desktop environment for daily use and development.

• Modern web browser: We added Firefox to openRuyi. This adds a modern browser option to the desktop image and improves the usability of openRuyi as a daily workstation.

• Kernel and platform updates: We updated the mainline kernel from 7.0.2 to 7.0.10 and the LTS kernel from 6.18.25 to 6.18.33. We also refreshed linux-tools and the kernel headers, raised NR_CPUS to 256 to better support high-core-count RISC-V server platforms, and tuned memory management options to improve process and memory performance.

• Toolchain updates: We updated GCC from 15 to 16 and binutils from 2.45 to 2.46. We also added LLVM version 22, which improves the availability of the compiler for package maintainers and developers.

• Storage, virtualization, and server stack improvements: We updated Ceph to 20.2.1 and applied patches to resolve full test suite issues. We also added libvirt, corosync, pacemaker, and related packages, strengthening openRuyi’s virtualization, clustering, and server-side capabilities.

Security Updates​

We delivered multiple security updates this month.

• curl was updated to 8.20.0, including fixes for multiple newly disclosed vulnerabilities.

• expat was updated to 2.8.1, addressing CVE-2026-45186, a denial-of-service issue in crafted XML input handling.

• python-django was updated to 5.2.13, addressing several Django security issues, including CVE-2026-3902, CVE-2026-4277, CVE-2026-4292, CVE-2026-33033, and CVE-2026-33034.

• libarchive was updated to 3.8.7, bringing security and bug fixes for several archive parsing paths.

• freerdp was updated to 3.26.0, including fixes for high-severity CVEs.

• nginx was updated to 1.31.1, including fixes for CVE-2026-9256, CVE-2026-42926, CVE-2026-42945, CVE-2026-42946, CVE-2026-40460, and CVE-2026-40701.

• rsync was updated to 3.4.3, including fixes for CVE-2026-43617, CVE-2026-43618, CVE-2026-43619, CVE-2026-43620, CVE-2026-45232, and CVE-2026-29518.

• unbound was updated to 1.25.1, including fixes for CVE-2026-33278, CVE-2026-42944, CVE-2026-42959, CVE-2026-32792, CVE-2026-40622, CVE-2026-41292, CVE-2026-42534, CVE-2026-42923, CVE-2026-42960, CVE-2026-44390, and CVE-2026-44608.

• postgresql was updated to 18.4, including fixes for CVE-2026-6476, CVE-2026-6638, CVE-2026-6637, CVE-2026-6473, CVE-2026-6474, CVE-2026-6479, CVE-2026-6475, CVE-2026-6478, CVE-2026-6477, CVE-2026-6575, and CVE-2026-6472.

• The Linux kernel was updated with fixes for several notable CVEs, including CVE-2026-31431, CVE-2026-43284, CVE-2026-43494, CVE-2026-43500, CVE-2026-43503, and CVE-2026-46333.

• We also updated components such as gnutls, nss, libtasn1, openldap, nghttp2, ruby, and vim, bringing in related security fixes and improvements.

We continue to provide four editions for different scenarios: Server, Container, Desktop, and Zero (BSP validation). You can download it from the openRuyi release site.

We welcome the community to test, integrate, and provide feedback on this release.

Changelog​

For readers who need the complete package-level details, the full changelog is grouped below by updated and newly added packages.

Based on the openRuyi Documentation Center guide, "Enable Secure Boot on openRuyi"^[1], this article uses the openRuyi UEFI firmware and the openRuyi Server edition QCOW2 image as examples to outline the main steps for configuring Secure Boot in a QEMU environment. The process begins with preparing the firmware and system image.

1. Prepare the UEFI Firmware and System Image​

Before enabling Secure Boot, prepare the openRuyi UEFI firmware and the openRuyi Server edition QCOW2 system image. The UEFI firmware can be obtained from the ovmf package in the openRuyi package repository^[2]. Extracting the package produces the .fd files.

wget https://boat.openruyi.cn/stable/rva23/riscv64/ovmf-202602-11.3.or.riscv64.rpm
rpm2cpio ovmf-202602-11.3.or.riscv64.rpm | cpio -idmv
cp ./usr/share/ovmf/*.fd ./

The openRuyi Server edition QCOW2 system image used in this article can be obtained from the openRuyi releases page^[3].

Note: If the ovmf package or system image has been updated by the time you follow this guide, use the latest files available in the openRuyi package repository and releases page, and update the filenames in the scripts below accordingly.

2. Create a QEMU Quick-Start Script​

After preparing the firmware and system image, create a QEMU startup script named start_or.sh and make it executable:

touch start_or.sh
chmod +x start_or.sh

Write the following content to start_or.sh:

#!/usr/bin/env bash

# The script is created for starting a riscv64 qemu virtual machine with specific parameters.

RESTORE=$(echo -en '\001\033[0m\002')
YELLOW=$(echo -en '\001\033[00;33m\002')

## Configuration
vcpu=2
memory=8
drive="openRuyi-2026.04-Server-cloud.qcow2"
fw1="virt_code.fd"
fw2="virt_vars.fd"
ssh_port=12055

cmd="qemu-system-riscv64 \
  -nographic -machine virt,pflash0=pflash0,pflash1=pflash1,acpi=off \
  -cpu rva23s64,sv39=on \
  -smp "$vcpu" -m "$memory"G \
  -blockdev node-name=pflash0,driver=file,read-only=on,filename="$fw1" \
  -blockdev node-name=pflash1,driver=file,filename="$fw2" \
  -drive file="$drive",format=qcow2,id=hd0,if=none \
  -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-vga \
  -device virtio-rng-device,rng=rng0 \
  -device virtio-blk-device,drive=hd0 \
  -device virtio-net-device,netdev=usernet \
  -netdev user,id=usernet,hostfwd=tcp::"$ssh_port"-:22 \
  -device qemu-xhci -usb -device usb-kbd -device usb-tablet"

echo ${YELLOW}:: Starting VM...${RESTORE}
echo ${YELLOW}:: Using following configuration${RESTORE}
echo ""
echo ${YELLOW}vCPU Cores: "$vcpu"${RESTORE}
echo ${YELLOW}Memory: "$memory"G${RESTORE}
echo ${YELLOW}Disk: "$drive"${RESTORE}
echo ${YELLOW}SSH Port: "$ssh_port"${RESTORE}
echo ""
echo ${YELLOW}:: NOTE: Make sure ONLY ONE .qcow2 file is${RESTORE}
echo ${YELLOW}in the current directory${RESTORE}
echo ""
echo ${YELLOW}:: Tip: Try setting DNS manually if QEMU user network doesn\'t work well. ${RESTORE}
echo ${YELLOW}:: HOWTO -\> https://serverfault.com/a/810639 ${RESTORE}
echo ""
echo ${YELLOW}:: Tip: If \'ping\' reports permission error, try reinstalling \'iputils\'. ${RESTORE}
echo ${YELLOW}:: HOWTO -\> \'sudo dnf reinstall iputils\' ${RESTORE}
echo ""

sleep 2

eval $cmd

This script starts an openRuyi virtual machine using qemu-system-riscv64 and specifies parameters including the RISC-V virt machine, UEFI pflash devices, QCOW2 disk, virtio devices, and SSH port forwarding. Here, drive points to the openRuyi Server QCOW2 image, fw1 and fw2 correspond to virt_code.fd and virt_vars.fd, and ssh_port configures SSH port forwarding.

Run the startup script to enter the openRuyi environment:

./start_or.sh

After the system starts, log in using either of the following accounts:

root / openruyi
openruyi / openruyi

3. Install the Tools Required for Secure Boot​

After entering the system, install the tools required to configure Secure Boot:

dnf install -y efibootmgr efitools grub-unsigned mokutil sbsigntools shim wget

After installation, copy grub.cfg and grubriscv64.efi to the /boot/efi/EFI/openruyi directory:

cp /boot/efi/EFI/BOOT/grub.cfg /boot/efi/EFI/openruyi/
cp /lib/grub/riscv64-efi/monolithic/grubriscv64.efi /boot/efi/EFI/openruyi/

4. Download the Secure Boot Helper Scripts​

From this point onward, all commands in this section must be run as the root user. If you are logged in as the openruyi user, add sudo before each command.

wget https://github.com/wxjstz/secureboot-setup/archive/refs/heads/main.tar.gz
tar xvf main.tar.gz
cd secureboot-setup-main

The repository mainly contains three scripts:

1.gen_keys          # Generate PK, KEK, db, and MOK keys
2.import_mok        # Initiate MOK enrollment through mokutil
3.import_uefi_cert  # Import PK, KEK, and db into the UEFI variable store

Note: After completing Secure Boot key enrollment, continue using the same virt_vars.fd file. QEMU stores UEFI variables in this file. Replacing it with a new virt_vars.fd will cause the system to lose the enrolled keys.

5. Confirm That the Firmware Is in Setup Mode​

Before creating or importing keys, confirm that the firmware is in Setup Mode:

mokutil --sb-state

The expected output is:

SecureBoot disabled
Platform is in Setup Mode

If the firmware is not in Setup Mode, restart QEMU with a clean virt_vars.fd, or enter the BIOS/UEFI interface and clear the Secure Boot keys.

6. Generate Secure Boot Signing Keys​

After confirming that the firmware is in Setup Mode, generate the keys and certificates required for Secure Boot:

./1.gen_keys

When the script runs, it prompts you to enter the certificate owner name. This name is written to the Common Name field of the generated certificate. Press Enter to use the default value.

After the script finishes, it generates the following directory structure:

secureboot/
├── cert/       # Private keys, certificates, and MOK.der
├── esl/        # EFI Signature Lists
└── keystore/   # Signed .auth files for UEFI enrollment

Backup Reminder​

Back up the entire secureboot/ directory, especially the private key files under secureboot/cert.

7. Sign the Key Files in the Boot Chain​

Secure Boot is not simply a matter of enabling a boot option. More importantly, the key files in the boot chain must carry valid signatures.

UEFI firmware → trust through db → shim → trust through MOK → MokManager / GRUB / Linux kernel

This workflow uses the following signing strategy:

• Use the db key to sign shim.
• Use the MOK key to sign MokManager, GRUB, and the Linux kernel.

Before signing, back up the original files:

mkdir -p orig

cp /boot/linux orig/
cp /boot/efi/EFI/openruyi/shimriscv64.efi orig/
cp /boot/efi/EFI/openruyi/mmriscv64.efi orig/
cp /boot/efi/EFI/openruyi/grubriscv64.efi orig/

Use the db key to sign shim:

sbsign \
    --key secureboot/cert/db.key \
    --cert secureboot/cert/db.crt \
    --output /boot/efi/EFI/openruyi/shimriscv64.efi \
    orig/shimriscv64.efi

Use the MOK key to sign MokManager, GRUB, and the Linux kernel:

sbsign \
    --key secureboot/cert/MOK.key \
    --cert secureboot/cert/MOK.crt \
    --output /boot/efi/EFI/openruyi/mmriscv64.efi \
    orig/mmriscv64.efi

sbsign \
    --key secureboot/cert/MOK.key \
    --cert secureboot/cert/MOK.crt \
    --output /boot/efi/EFI/openruyi/grubriscv64.efi \
    orig/grubriscv64.efi

sbsign \
    --key secureboot/cert/MOK.key \
    --cert secureboot/cert/MOK.crt \
    --output /boot/linux \
    orig/linux

8. Enroll the MOK Certificate​

Before importing the UEFI certificates, enroll the MOK certificate. shim will use MOK to trust the signed MokManager, GRUB, and kernel.

Run the following command to initiate the MOK enrollment request:

./2.import_mok

During this process, you need to set an enrollment password. After rebooting into MokManager, use this password to confirm the enrollment.

reboot

After the system restarts, MokManager opens the blue Mok Management interface. Complete the enrollment as follows:

1. Select Enroll MOK → Continue.
2. Enter the password you just set.
3. Select Yes to confirm the enrollment.
4. Select Reboot.

After the second reboot, use the following command to confirm that the MOK certificate has been enrolled:

mokutil --list-enrolled

9. Import the UEFI Certificates​

After enrolling the MOK certificate, import PK, KEK, and db into the UEFI variable store:

./3.import_uefi_cert

After the import completes, check each UEFI key database:

mokutil --pk
mokutil --kek
mokutil --db

After confirming that the command output includes the certificates generated earlier, reboot the system again:

reboot

10. Verify That Secure Boot Is Enabled​

After the system restarts, run:

mokutil --sb-state

If the output is:

SecureBoot enabled

Secure Boot has been successfully enabled on openRuyi.

Summary​

This guide enables developers to walk through the complete Secure Boot configuration process in an openRuyi QEMU environment. From firmware preparation and QEMU startup to key generation, boot-file signing, and MOK and UEFI certificate enrollment, the workflow demonstrates how Secure Boot works on openRuyi.

For developers interested in RISC-V system security, UEFI firmware adaptation, and boot-chain verification, this is not only a hands-on Secure Boot configuration exercise, but also an introduction to the trusted boot mechanism of RISC-V systems.

Related Links​

[1] openRuyi Secure Boot Guide: https://openruyi.cn/zh-Hans/docs/guide/enable-secure-boot/

[2] openRuyi Package Repository: https://boat.openruyi.cn/stable/rva23/

[3] openRuyi Releases: https://releases.openruyi.cn/

Contact Us​

If you are interested in openRuyi, follow the project on GitHub, visit the openRuyi Documentation Center for more information, or join the Discord community to participate in discussions. The team is continuously recruiting full-time employees, part-time contributors, and interns. Please send your resume to Jingwei Wang at wangjingwei@iscas.ac.cn.

DPDK MAINTAINERS update

DPDK is a widely deployed user-space high-speed data plane framework, covering key scenarios such as telecommunications networks, cloud data centers, virtual switching, and load balancing. It is also a core dependency of high-performance networking and storage projects such as SPDK, OVS-DPDK, and VPP. Having long-term contributors to RISC-V optimization take on architecture maintenance means that patch review, CI maintenance, and release work for this architecture will move into a more stable cadence, further promoting the large-scale adoption of RISC-V in data center and network infrastructure scenarios.

Long-Term Investment in RISC-V and Deeper Involvement in the Maintenance Framework​

Since the second half of 2023, RISC-V-related submissions in the DPDK community had, for a time, remained under review for a prolonged period, and the overall merge pace slowed down. Since 2025, Yuechi Sun has promoted a series of patches around V extension detection, runtime dispatching, and RVV vectorization of core lookup data structures such as lpm and fib. This work became the first batch of RISC-V optimization achievements to enter the DPDK mainline in nearly three years.

During the same period, he joined DPDK MAINTAINERS as the RVV subsystem maintainer. As his continued investment and community collaboration deepened, he further took on maintenance responsibilities for the entire RISC-V architecture.

openRuyi’s Plan to Advance DPDK​

DPDK support for RISC-V is a key part of openRuyi’s systematic efforts to advance the high-performance software stack. In addition to promoting the upstreaming of RVV optimizations into DPDK, the RuyiSDS initiative is also building distribution packaging, runtime validation, and continuous integration capabilities for DPDK in the openRuyi operating system.

These capabilities will allow every RISC-V-related upstream change to receive fast feedback on real RISC-V server hardware, reducing the risk that patches are left pending or maintenance stalls due to insufficient hardware resources.

Around RISC-V optimization for DPDK, openRuyi has carried out and will continue to advance the following work:

• Instruction extension detection framework: Unified detection of extension capabilities such as V at both compile time and runtime, laying the foundation for future optimized dispatch.
• RVV optimization of core data structures: RVV vectorization has been completed for lookup and routing hot paths such as fib and lpm, with notable performance improvements.
• Build and test infrastructure: Improvements to build and unit testing related to the V extension on RISC-V platforms, ensuring DPDK stability on RISC-V.
• Continuous expansion: Exploration of RVV optimizations for modules such as mem, node, and acl is underway and will be gradually pushed upstream.

At the same time, an increasing number of developers from China and abroad, including contributors from ZTE and ByteDance, have been participating in RISC-V adaptation in the DPDK community. Related work currently under review and discussion covers multiple areas, including support for Z-series extensions such as Zbc and Zicbop, hwprobe detection, RVV vectorization of core libraries such as hash, rte_memcpy optimization, and memory and prefetch operations for I/O devices. Yuechi Sun will work with community contributors to advance the review and merging of this work, continuously expanding the scope of RISC-V optimization in DPDK.

The RISC-V Storage Stack Around Ceph: openRuyi’s Next Step​

On the RISC-V platform, storage stack optimization depends on a bottom-up component chain: the upper-layer Ceph distributed storage system depends on foundational components such as the SPDK user-space block storage stack, the ISA-L data acceleration library, OpenSSL, and zstd; SPDK, in turn, depends on DPDK for runtime facilities such as high-performance memory pools, polling, and lock-free queues.

The main line of work in the RuyiSDS initiative is to systematically advance along this dependency chain:

• Low-level acceleration libraries: Working with upstream communities to promote RVV vectorization and riscv64 adaptation for Ceph dependencies such as ISA-L, zstd, and OpenSSL. For example, ISA-L v2.32, released earlier this year, officially supports riscv64 and covers RVV implementations of core operators such as erasure coding, CRC, and compression checks.
• Runtime and block storage: Using DPDK maintenance work as a foothold to further advance the adaptation and improvement of SPDK on RISC-V, and gradually enable the DPDK/SPDK path for Ceph on RISC-V platforms.
• Integration validation: After the related work is completed, the full Ceph CI will first be run in openRuyi, with the goal of making openRuyi the industry’s first RISC-V distribution with complete Ceph support.
• Performance tuning: On the basis of functional completeness, openRuyi will gradually integrate and validate the high-performance and next-generation OSD paths in Ceph that depend on DPDK/SPDK. Some of these capabilities are still experimental upstream, and openRuyi will continue to track their progress.

openRuyi RISC-V software stack

As the RVA23 standard is officially implemented and server-class RISC-V platforms gradually mature, system-level optimization of networking and storage stacks is moving from “point-by-point adaptation” to a new stage of “end-to-end collaboration.” With DPDK maintenance as a foothold, openRuyi will collaborate with upstream and downstream components such as SPDK, ISA-L, Ceph, and OVS to build a RISC-V software stack that connects infrastructure and distributed applications.

Building the Ecosystem Together​

In the future, the RuyiSDS initiative will continue to invest in upstream collaboration for RISC-V in high-performance networking and distributed storage, promote more optimizations into core projects such as DPDK, SPDK, and Ceph, and rely on openRuyi to provide a stable development, build, and validation environment. These efforts will help key infrastructure software in the RISC-V server ecosystem reach production readiness sooner.

We sincerely invite more developers, chip vendors, and system vendors to join us and work with openRuyi to advance the evolution of the RISC-V networking and storage software stack.

Contact Us​

If you are interested in openRuyi, you can follow our GitHub open-source project, visit the openRuyi documentation center for more information, and join our Discord community for discussion. The team is continuously recruiting full-time employees, part-time contributors, and interns. Please send your resume to wangjingwei@iscas.ac.cn (Jingwei Wang).

openRuyi is a native Linux distribution for the RISC-V architecture, with a focus on performance, security, AI, and cloud-native workloads. The rolling-release version of openRuyi tracks the latest upstream baseline and is committed to building best practices for cutting-edge standards and software applications on RISC-V.

As AI infrastructure continues to evolve rapidly, the AI ecosystem on RISC-V has long faced challenges such as fragmented software stacks, high configuration barriers, and limited support from upstream communities. To address these issues, the openRuyi team at the Institute of Software, Chinese Academy of Sciences has been continuously advancing related work, gradually improving adaptation and integration from the low-level GPU computing stack to upper-layer application tools. In this update, openRuyi brings three AI-related improvements: performance gains with ROCm 7.1.1, ready-to-use local inference with Ollama, and integration of the PicoClaw AI assistant.

1. ROCm: Significantly Improved LLM Inference Performance and Support for More GPUs​

ROCm (Radeon Open Compute platform) is AMD’s fully open-source GPU computing platform. It covers a complete set of components including drivers, runtime, and operator libraries, and is one of the more mature non-NVIDIA GPU computing solutions in the open-source ecosystem. openRuyi has completed full-stack ROCm porting and adaptation on the RISC-V platform, and in this update, the integrated version has been upgraded to the newer ROCm 7.1.1.

According to test results, on the RX 7900 XTX platform with llama.cpp b6029, the llama 8B Q4_K - Medium model shows performance improvements across multiple test items:

These results indicate that openRuyi’s ROCm adaptation on RISC-V has reached a good level of practical usability and has achieved further improvement in inference performance. At the same time, this update also adds support for mainstream RDNA4 series GPUs (RX90xx), further expanding RISC-V platform support for heterogeneous AI hardware.

Upstreaming ROCm: Making RISC-V a First-Class Citizen in the Open-Source AI Ecosystem​

In addition to performance improvements, the openRuyi team is also actively promoting the upstreaming of RISC-V support for ROCm. The relevant patches that have not yet been upstreamed can currently be found in the openRuyi SPECS repository^[1]. Going forward, the team will continue to push these patches upstream, with a focus on maintaining patches related to the base toolchain and ROCm runtime, further improving RISC-V support in the ROCm ecosystem.

2. Ollama: Run Local LLMs with a Single Command​

Ollama is a popular tool for managing and running local large language models. It supports one-command download and local inference for mainstream open-source models such as Llama, Qwen, Mistral, and DeepSeek. With no complex configuration required, it is widely used by individual developers and researchers for deploying local LLMs.

Previously, newer versions of Ollama did not support the riscv64 architecture. To address this issue, the openRuyi team fixed the compilation problems of Ollama on riscv64 and enabled GPU acceleration with ROCm 7.1.1, allowing RISC-V users to leverage AMD GPU computing power for local model inference^[2].

On openRuyi, using Ollama only requires the following commands:

sudo dnf install ollama
# Or use other local models, such as qwen3
ollama run deepseek-r1

No manual compilation or additional environment variable configuration is required. After installation, it can be used directly. This further lowers the barrier to deploying local LLMs on RISC-V and makes local inference more convenient.

Performance of running the deepseek-r1:8b model locally with Ollama

3. PicoClaw: A Fully Local AI Agent​

Beyond model runtime capability, openRuyi is also improving support for AI application tools aimed at real-world development scenarios.

PicoClaw is a lightweight open-source autonomous AI agent. It has now been integrated into openRuyi, and installation also requires only a single command:

sudo dnf install picoclaw

After installation, users can follow the official PicoClaw getting-started documentation to complete the initial configuration and begin using it^[3].

Based on openRuyi’s pre-integrated Ollama + ROCm 7.1.1 backend, users can switch PicoClaw’s inference backend to the local Ollama service, enabling the following capabilities:

• Fully local inference: models run on the local AMD GPU, and data does not need to pass through any external server.
• No network connection required: AI assistance remains available even in offline environments.
• GPU acceleration: ROCm 7.1.1 enables higher inference speed on RISC-V + AMD GPU platforms.

This shows that openRuyi’s AI capability development on RISC-V has moved beyond basic model inference and is now extending into agent scenarios.

PicoClaw runs through a local Ollama backend, enabling high-performance localized AI assistance

4. openRuyi AI Stack Roadmap: What Comes Next​

The current integration of Ollama and PicoClaw is only the starting point for openRuyi’s AI capability development. According to the project roadmap, the openRuyi AI stack will continue to evolve in the following roadmap:

• Near-term priorities: expand support for more GPU models. Based on the currently verified RX 7900 XTX, more AMD Radeon GPU models will be tested and supported in the future; continue promoting ROCm upstreaming by contributing RISC-V support patches to projects such as ROCm and llama.cpp, and gradually push related support into the mainline.
• Mid-term priorities: complete the full vLLM inference pipeline, enabling distributed LLM inference services based on PyTorch and vLLM on RISC-V + AMD GPU platforms, while exploring multi-GPU distributed LLM training capabilities; improve edge-side inference support by integrating llama.cpp optimized with RISC-V Vector Extension (RVV), covering mainstream RISC-V processors such as SOPHGO SG2044, SpacemiT K3, and Xuantie C950, so that lightweight models can also run in CPU-only environments without a GPU; expand model validation coverage beyond language models, gradually advancing validation for vision models (YOLO), multimodal models, and more on the RISC-V platform; explore deployment solutions for edge-side agent applications by adapting and running mainstream agent frameworks such as LangChain on RISC-V, combined with local model inference capabilities.
• Long-term priorities: explore adaptation of domestic acceleration hardware on RISC-V hosts, promote a fully domestic “RISC-V + domestic accelerator” end-to-end solution, and lay the foundation for future AI ecosystem adaptation and application expansion; based on openRuyi’s software-hardware co-design capabilities, further explore agent applications for specific industry scenarios and build a complete agent runtime and development experience on RISC-V.

Conclusion​

The work on ROCm, Ollama, and PicoClaw further improves openRuyi’s local AI software stack for the RISC-V platform and lowers the barrier to deploying and using local LLMs. Going forward, openRuyi will continue to improve AI support on RISC-V through performance optimization, tool enhancement, ecosystem adaptation, and upstream collaboration.

Related Links​

[1] openRuyi SPECS repository:
https://github.com/openRuyi-Project/openRuyi/tree/main/SPECS

[2] Ollama adaptation and packaging files in openRuyi:
https://github.com/openRuyi-Project/openRuyi/tree/main/SPECS/ollama

[3] Official PicoClaw getting-started documentation:
https://docs.picoclaw.io/zh-Hans/docs/getting-started/

Contact Us​

If you are interested in openRuyi, you can follow our GitHub project, visit the openRuyi documentation center for more information, and join our Discord community for discussion and collaboration. The team is also continuously recruiting full-time employees, part-time contributors, and interns. Please send your resume to wangjingwei@iscas.ac.cn (Jingwei Wang).

openRuyi made steady progress across the kernel, boot stack, package ecosystem, and build infrastructure for RISC-V platforms in this release.

Highlights​

• Kernel and platform updates: We updated mainline kernel to 7.0.2, and LTS kernel to 6.18.25. We also refreshed a large set of RISC-V related patches and configurations.

• Secure Boot / UEFI enablement: We expanded the boot chain by continuing work on key components such as shim, ovmf, and grub, thereby improving overall Secure Boot and UEFI support.

• Faster ecosystem growth: We added and updated packages across desktop, multimedia, containers, AI, and server-side development. Representative additions and updates include vlc, opencv, buildah, and fastapi.

Other Improvements​

• We improved build compatibility and toolchain integration, including fixes related to the glibc 2.43 / C23 transition.

Security Updates​

We delivered multiple security updates this month, including a fix for Ruby CVE-2026-41316 and fixes for OpenSSH CVE-2025-26465 and CVE-2025-26466. We also updated several other important components, including openssl, openjdk, and vim.

We continue to provide four editions for different scenarios: Server, Container, Desktop, and Zero (BSP validation). You can download it from here.

We welcome the community to test, integrate, and provide feedback on this release.

The majority of packages in this release are compatible with the rva23u64 target, featuring LTO enabled and using -mtune=generic-ooo as the default tuning option.

Core Components & Toolchains​

• Kernel (mainline): 6.19.9

• Kernel (LTS): 6.18.19

• gcc: 15.2.0 with RVA23 support

• binutils: 2.45

• glibc: 2.42

• grub: 2.14

• systemd: 259

• coreutils: 9.9

• util-linux: 2.41.3

Other​

• Openresty LuaJIT: v2.1-20260114 with riscv64 support

• zlib-ng: 2.3.3 with riscv-hwprobe support

• labwc: 0.9.3

• wayland: 1.24.0

• mesa: 26.0.1

Images​

We offer four editions tailored for different scenarios:

• Server: Designed for use on bare-metal servers.

• Container: For both public and private cloud environments.

• Desktop: Proudly uses labwc as our premier desktop solution.

• Zero (BSP validation): Special Edition for SoC bringup and kernel development, especially in the pre-Silicon stage.

You can download it from here.

We welcome the community to test, integrate, and provide feedback on this release.