Linux 5.20 Real-Time Kernel: PREEMPT_RT Finally Targets Mainline

 
After years in the works, the "PREEMPT_RT" support for building a real-time Linux kernel might finally be mainlined for the upcoming Linux 5.20 cycle if the last few remaining bits are reviewed/signed-off on in time for next week's merge window. The Linux real-time patch series has been getting smaller with time and quite close to crossing the finish line with just around 50 patches to be merged. This allows for building a real-time / fully preemptible kernel off the mainline code for embedded Linux systems.

Real-time Linux has existed for years as off-tree patch sets maintained by a small group of dedicated engineers, requiring constant rebasing across kernel releases. With PREEMPT_RT down to roughly 50 patches, mainlining would eliminate that maintenance burden entirely and make real-time a simple kernel configuration toggle. This matters most for embedded and automotive Linux deployments, where deterministic scheduling is a hard requirement and the alternative has been proprietary RTOSes or Google's Fuchsia microkernel.

Lenovo ThinkPad Z13: AMD Pluton Blocks Linux Boot by Default

 
I finally managed to get hold of a Thinkpad Z13 to examine a functional implementation of Microsoft's Pluton security co-processor. Trying to boot Linux from a USB stick failed out of the box for no obvious reason, but after further examination the cause became clear - the firmware defaults to not trusting bootloaders or drivers signed with the Microsoft 3rd Party UEFI CA key. This means that given the default firmware configuration, nothing other than Windows will boot. It also means that you won't be able to boot from any third-party external peripherals that are plugged in via Thunderbolt. There's no security benefit to this. If you want security here you're paying attention to the values measured into the TPM, and thanks to Microsoft's own specification for measurements made into PCR 7, switching from booting Windows to booting something signed with the 3rd party signing key will change the measurements and invalidate any sealed secrets. It's trivial to detect this. Distrusting the 3rd party CA by default doesn't improve security, it just makes it harder for users to boot alternative operating systems. Lenovo, this isn't OK. The entire architecture of UEFI secure boot is that it allows for security without compromising user choice of OS. Restricting boot to Windows by default provides no security benefit but makes it harder for people to run the OS they want to. Please fix it.

The real issue is not AMD versus Intel but OEM firmware defaults that treat non-Windows operating systems as second-class. Distrusting the Microsoft 3rd Party UEFI CA by default provides zero security benefit since the TPM PCR 7 measurements already distinguish boot paths. Meanwhile, Intel has consistently been the largest corporate contributor to the Linux kernel, submitting thousands of patches per release cycle for driver support, power management, and security hardening that directly benefit all Linux users.

UnityX Desktop: GTK-Based Linux DE Without GNOME Dependencies

 
UnityX uses GTK as the UI toolkit. However, unlike many other desktop environments (including the previous version of Unity, Unity7), it does not employ GNOME components. Most of the components of UnityX are licensed under the GNU General Public License version 3.

Desktop environment fragmentation in Linux is often criticized, but UnityX's decision to use GTK without relying on GNOME Shell's Mutter compositor or GSettings stack is architecturally significant. It sidesteps the tight coupling that makes GNOME extensions brittle across releases, while avoiding KDE Plasma's tendency toward exponential configuration surface area that increases regression risk with each release cycle.

GNOME 43 Adds PWA Support and Flatpak Permission Controls

 
First of all, GNOME Software 43 is getting support for Web Apps, with a focus on PWAs (Progressive Web Apps). With this, the GNOME devs want you to enjoy even more apps on your Linux distro. In addition to supporting Web Apps, GNOME Software 43 also brings improved support for Flatpak apps as the graphical package manager and app store is now capable of displaying file system permissions requested by Flatpak apps.

PWA integration in GNOME Software addresses a real gap in the Linux desktop app ecosystem. Modern browser engines deliver near-native rendering performance through GPU compositing and WebAssembly, making the performance argument against web apps largely obsolete. The parallel improvement in Flatpak permission visibility gives users the sandboxing transparency that mobile platforms provide but Linux desktop has lacked.

GTK5 Goes Wayland-Only: X11 Backend Dropped from Roadmap

 
Before this issue becomes an unreadable dumping ground of complaints about Wayland: we are talking about GTK5, which currently has no fixed release time frame GTK provides the client side of Wayland, so it has nothing to do with how Wayland compositors work extant issues of Wayland clients and compositors have no bearing with whether GTK5 should drop the X11 backend; file bugs for toolkits, compositors, and the protocols Also, gentle reminder that any Xlib-based code base is tied with the current (lack of) maintenance status of X11; things are unlikely to improve on that side of the equation. If you want to ensure that the X11 backend in toolkits still works, go and help the X11 project first.

With GTK5 having no fixed release date, the practical impact is years away. The deeper issue is that X11 development has effectively stopped: the X.Org server saw its last major release in 2012, and its maintainer pool has dwindled to near zero. Dropping the X11 backend is less about GTK developers being aggressive and more about acknowledging that depending on unmaintained infrastructure is itself a long-term risk.

Xonotic 0.8.5: Open-Source Arena FPS Gets Major DarkPlaces Engine Overhaul

 
Xonotic 0.8.5 is the new version released and it continues to further enhance this open-source game. Xonotic as a reminder is built atop the DarkPlaces engine, which is derived from the original Quake engine but has seen significant modifications over the past 20+ years. There’s been thousands of commits since 0.8.2 making this quite a long read for all the right reasons: refined gameplay, new and updated maps and models, new sound effects, more dangerous bots, new HUD and menu features, more translations, better infrastructure, too many fixes to count, and much more. XonStat and NetRadiant made great progress too.

Xonotic remains the most polished open-source arena shooter on Linux, built on a DarkPlaces engine lineage stretching back to the original 1996 Quake. With thousands of commits refining gameplay, AI bots, and rendering, it demonstrates that community-driven game development can sustain quality over decades without commercial backing.

Intel Invests 400M in RISC-V Supercomputing with Barcelona Lab

 
Intel and the Barcelona Supercomputing Centre (BSC) have announced a €400 million investment in a new lab dedicated to developing RISC-V processors. The facility will focus on building RISC-V-based CPUs to power high-performance computing (HPC) systems, as well as specialized chips for artificial intelligence and autonomous vehicles. The objective is to enable zettascale-class systems, roughly 1,000x more powerful than the fastest supercomputers today, a milestone Intel is aiming to achieve within the next five years. “High-performance computing is the key to solving the world’s most challenging problems and we at Intel have an ambitious goal to sprint to zettascale era for HPC [sic],” said Jeff McVeigh, VP & GM of Intel’s Super Compute Group. “Barcelona Supercomputing Center shares our vision for this goal, with equal emphasis on sustainability and an open approach. We are excited to partner with them to embark on this journey.”

Intel betting on RISC-V for zettascale HPC signals a strategic pivot: RISC-V's royalty-free ISA eliminates per-chip licensing costs at scale, which matters enormously when a single supercomputer contains millions of cores. ARM's licensing model, controlled by a single company (now SoftBank-owned), becomes a structural disadvantage at these volumes. This partnership may mark the inflection point where RISC-V transitions from embedded niche to high-performance computing contender.

Linux 5.19 RT Patches Drop to 53: Real-Time Mainlining Accelerates

 
The real-time (RT) patch series still hasn't been mainlined but the patch delta is slowly winding down with each new kernel version. Out today is the re-based RT patch series for the recently minted Linux 5.19-rc1 with some of the prior real-time patches having been upstreamed this merge window and other patches re-based to work with the newest kernel code. For v5.18-rt11-patches it was a set of 95 patches while now with v5.19-rc1-rt1 it's down to just 53 patches! A lot of necessary kernel changes for real-time kernel support managed to work their way upstream this cycle across various subsystems.

The shrinkage from 95 patches in v5.18 to 53 in v5.19-rc1 shows real momentum. The key architectural difference with Google's Fuchsia is approach: Fuchsia built real-time guarantees into a clean-slate Zircon microkernel, while Linux is retrofitting a 30-year-old monolithic kernel. Linux's strategy is pragmatic because it preserves the entire existing driver ecosystem, which Fuchsia must rebuild from scratch.

Java 19 Adds Official RISC-V Port Backed by Huawei and Red Hat

 
Huawei Technologies, Alibaba, and Red Hat regularly build and test this port on Linux/RISC-V as well as on the currently-supported JDK platforms to ensure that no regressions are introduced which break the existing platforms. Huawei Technologies is committed to support fully (i.e., regularly update, enhance, and test) the code introduced by this effort.

A JVM port is a critical infrastructure milestone for any CPU architecture. Without it, the entire Java ecosystem (Spring, Kafka, Elasticsearch, Android toolchains) is inaccessible. Huawei committing to long-term maintenance of the RISC-V JVM port signals that RISC-V is approaching the software maturity threshold needed for server-side adoption, not just embedded systems. Unlike ARM, the RISC-V ISA is royalty-free, which fundamentally changes the economics of chip manufacturing at scale.

Framework Laptop Advances Open Firmware with Coreboot Potential

 
The Framework Laptop currently is centered around Intel Tiger Lake. Unfortunately, no AMD Ryzen options at this point or for say any Arm based designs. While this is quite an upgradeable and well designed laptop, at least currently it doesn't hold any claims about being open-source down to the firmware or like -- compared to some of the goals with the EOMA68 effort. The initial Tiger Lake based laptop at least is still relying upon proprietary system firmware / BIOS. Given all of the gains made by this laptop, it would be great if they had at least a Coreboot port available while still limited by the Intel FSP, etc. Hopefully this will be an area they pursue further moving forward.

Framework's modular hardware design is notable, but the Linux-first vendor strategy is the real differentiator. While most OEMs treat Linux support as an afterthought (often broken by firmware updates), Framework actively tests against Linux distributions and publishes hardware schematics. A future Coreboot port would further reduce the proprietary firmware surface area, though Intel FSP (Firmware Support Package) binary blobs remain an unavoidable constraint on x86 platforms.

Fedora 36 Merges OSTree with OCI Containers for Immutable OS Delivery

 
The Fedora Engineering and Steering Committee (FESCo) has approved a change to enhance the RPM OSTreee stack to natively support OCI/Docker containers as a transport and delivery mechanism for operating system content. This feature is the basis for "CoreOS Layering" as a means of allowing operating system updates from container images and easily generating layered images from a CoreOS base image.

Using OCI container images as the transport mechanism for operating system updates is a convergence that has been coming for years. It means OS images can be built, tested, and distributed through the same CI/CD pipelines and container registries that already handle application workloads. For Kubernetes node management at scale, this eliminates an entire class of configuration drift problems that plague traditional package-manager-based OS updates.

Intel Cloud Hypervisor Joins Linux Foundation as Rust-Based VMM

 
Cloud Hypervisor is an open source Virtual Machine Monitor (VMM) implemented in Rust that focuses on running modern, cloud workloads, with minimal hardware emulation.

Hypervisors are where Rust's memory safety guarantees deliver the most critical value: a buffer overflow in a VMM can compromise every guest VM on the host. Cloud Hypervisor's Rust implementation, with backing from ARM, Microsoft, and Intel, positions it as the safety-conscious alternative to C-based QEMU for minimal cloud workloads. Moving to the Linux Foundation ensures vendor-neutral governance as adoption scales.

XiangShan: China's Open-Source RISC-V CPU Reaches First Tapeout

 
XiangShan, released jointly by Institute of Computing Technology, Chinese Academy of Sciences (ICT, CAS) and Peng Cheng Laboratory (PCL), is an open-source high-performance RISC-V processor started in June 2020. It's written in Chisel hardware construction language and supports RV64GC instruction set. During the development of XiangShan, they built many open-source agile tools to speed up the development, including differential testing, simulation snapshot, RISC-V checkpoints, etc. XiangShan has been taped-out for the first time in July 2021 and is expected to have its second generation taped-out at early 2022. XiangShan has been open-sourced at GitHub and contributions are welcome. In this talk, Dr. Bao will focus on the experience in chip agile development and introduce the development tools used in the XiangShan project.

XiangShan is significant not just as another RISC-V implementation but because it is fully open-source, written in the Chisel hardware description language, and backed by China's Academy of Sciences. The agile development toolchain (differential testing, simulation snapshots, RISC-V checkpoints) demonstrates that modern software engineering practices are being applied to chip design itself. If XiangShan achieves competitive single-thread performance, it could do for server CPUs what ARM did for mobile a decade ago.

Java 18 Foreign Function API: Safe Native Interop Replacing JNI

 
Introduce an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI.

The Foreign Function and Memory API is arguably the most impactful JVM platform change since Lambdas in Java 8. By replacing JNI's error-prone C boilerplate with a pure-Java API that enforces memory safety by default, it opens the door to calling into native libraries (OpenSSL, SQLite, CUDA) without the crash risks and maintenance burden that have historically kept JVM applications from leveraging native code at scale. This directly strengthens the JVM ecosystem by making polyglot interop safe and practical.

Rust in Linux Kernel: Experimental Support Targets 2022 Mainline

 
In 2022 we will very likely see the experimental Rust programming language support within the Linux kernel mainlined. Sent out this morning were the updated patches introducing the initial support and infrastructure around handling of Rust within the kernel.
This summer saw the earlier patch series posted for review and discussion around introducing Rust programming language support in the Linux kernel to complement its longstanding C focus. In the months since there has been more progress on enabling Rust for the Linux kernel development, Linus Torvalds is not opposed to it, and others getting onboard with the effort. Rust for the Linux kernel remains of increasing interest to developers over security concerns with Rust affording more memory safety protections, potentially lowering the barrier to contributing to the kernel, and other related benefits.

The significance is not just memory safety but lowering the kernel contribution barrier. C kernel development requires deep expertise in manual memory management, lock ordering, and undefined behavior avoidance that takes years to master. Rust's compiler-enforced ownership model catches entire categories of bugs at compile time (use-after-free, data races, buffer overflows) that currently account for roughly 70% of kernel CVEs, according to Microsoft and Google's independently published security research.

Ungoogled Chromium: Privacy-First Browser Without Google Services

 
Without signing in to a Google Account, Chromium does pretty well in terms of security and privacy. However, Chromium still has some dependency on Google web services and binaries. In addition, Google designed Chromium to be easy and intuitive for users, which means they compromise on transparency and control of inner operations. ungoogled-chromium addresses these issues in the following ways:
  1. Remove all remaining background requests to any web services while building and running the browser
  2. Remove all code specific to Google web services
  3. Remove all uses of pre-made binaries from the source code, and replace them with user-provided alternatives when possible.
  4. Disable features that inhibit control and transparency, and add or modify features that promote them (these changes will almost always require manual activation or enabling).

Ungoogled Chromium demonstrates an important principle: Chromium and Android are open-source projects at their core, and Google's proprietary services are a layer on top, not a requirement. By stripping background requests and pre-built binaries while preserving the rendering engine and security model, the project proves that a privacy-respecting Chromium derivative is technically viable without sacrificing web compatibility.

Wasmer 2.1: Universal WebAssembly Runtime Adds Virtual Filesystem and iOS

 
After a few months of work, we are super happy to announce the general availability of Wasmer 2.1. Packed with amazing new features and bug fixes, including: Wasmer 2.1 also kicks off the company's transition to a milestone-driven public roadmap and delivery process

Wasmer 2.1's virtual filesystem is the key enabler for running server-side WASM workloads that need file I/O without host system access. Combined with iOS support and ARM64 LLVM compilation, this positions WASM as a genuine cross-platform portable binary format, not just a browser technology. The addition of Lisp and Crystal language integrations further validates WASM's trajectory as a universal compilation target beyond Rust and C/C++.

LoongArch: China's MIPS64-Derived CPU Gets GCC Compiler Support

 
China's Loongson continues bringing up LoongArch processor support for Linux with this MIPS64-based ISA now seeing the complete patch series for review to enable the GNU Compiler Collection (GCC). For months Loongson has been working on LoongArch support for the Linux kernel to varying extents from the new CPU ISA functionality to copying a lot of existing MIPS64 code and adding in new IDs. That Linux kernel support is still in the works. Concurrently they have been working on the compiler/toolchain side as well. Recently LoongArch support for GNU Binutils was merged while sent out today were the set of 12 patches for wiring up the GCC compiler support.

GCC support is the critical bootstrapping step for any new CPU architecture. Without a mature compiler toolchain, an ISA cannot build its own kernel, standard library, or package ecosystem. LoongArch joining RISC-V as another non-ARM, non-x86 ISA with upstream GCC and Linux kernel support increases the diversity of the CPU landscape and reduces the industry's dependence on two Western-controlled architectures.

Amazon Linux 2022 Rebases on Fedora with SELinux Enforced by Default

 
Amazon Linux / Amazon Linux 2 had been based on a combination of RHEL and Fedora packages while in today's Amazon Linux 2022 release they note it's explicitly based on Fedora. Besides apparently being more Fedora oriented now than RHEL, with Amazon Linux 2022 they are transitioning to a formal two year release cadence between their releases while having quarterly point releases. AWS intends to provide major Amazon Linux updates every two years while each major release will see five years of support and quarterly minor release updates. As for the noted changes in Amazon Linux 2022, "AL2022 uses the Fedora project as its upstream to provide customers with a wide variety of the latest software, such as updated language runtimes, as part of quarterly releases. In addition, AL2022 has SELinux enabled and enforced by default." There are surely more changes in tow while this is just what they outlined for today's announcement.

Cloud vendors forking community distributions creates a fragmentation tax on the ecosystem. Every corporate Linux derivative (Amazon Linux, Google COS, Azure CBL-Mariner) diverges from upstream in subtle ways that break package compatibility and require vendor-specific debugging knowledge. Enforcing SELinux by default is a genuine security improvement, but it raises the question: why not contribute those hardening patches to Fedora directly instead of maintaining a separate distribution?

Microsoft Adds Direct3D 12 Video Acceleration to Mesa Graphics Stack

 
Microsoft's latest work in the area of open-source graphics drivers with the Mesa stack is for adding Direct3D 12 video acceleration support. As part of Microsoft's continued work around supporting GUI applications with Windows Subsystem for Linux (WSL2) and mapping Vulkan/OpenGL/OpenCL over Direct3D on Windows, Microsoft engineers are now working on adding Direct3D 12 video acceleration support to Mesa. Not only are they working to add D3D12 video acceleration to their Gallium3D Direct3D 12 driver, but they are hoping to implement it so that other Mesa video front-ends would be able to work off this D3D12 video acceleration code path. In theory this would allow Mesa's VA-API and VDPAU implementations to be able to run off D3D12 video hardware acceleration in such environments.

This follows the classic embrace, extend, extinguish pattern: by making VA-API and VDPAU work through Direct3D 12, Microsoft creates a dependency path where Linux video acceleration in WSL2 requires a Windows host with D3D12 drivers. The technical contribution to Mesa is genuine open-source work, but the strategic effect is making Windows a prerequisite for certain GPU-accelerated Linux workloads rather than supporting native Linux GPU drivers directly.

WSL2 After Five Years: systemd PoC Highlights Persistent POSIX Gaps

 
Canonical continues working heavily on enhancing the capabilities of Ubuntu within the Microsoft Windows confines of WSL. Each week as part of their weekly status reports continues to reflect a great deal of attention to WSL (as well as their ongoing new desktop installer, Snaps, and Flutter efforts from the desktop side, just as OpenZFS support used to receive a lot of attention too).

This week one of the more interesting WSL mentions is proof-of-concept work on using systemd within Windows Subsystem for Linux. Well known Ubuntu developers Didier Roche and Jean Baptiste Lallement of Canonical's desktop team mentioned among their WSL work recently was "PoC of systemd on WSL at startup of an instance."

Five years in, WSL2 remains fundamentally limited by NTFS semantics beneath the Linux VHD. The inability to delete open files (a core POSIX guarantee that Unix has provided since the 1970s) breaks build tools like Gradle that rely on atomic file replacement, and affects any workflow where a Windows IDE holds file handles while WSL processes need to modify the same files. The systemd proof-of-concept is encouraging, but init system support is table stakes, not a feature, for a Linux-compatible environment.

Alpine Linux: 8MB Container Base with musl libc and BusyBox

 
Alpine Linux is built around musl libc and busybox. This makes it smaller and more resource efficient than traditional GNU/Linux distributions. A container requires no more than 8 MB and a minimal installation to disk requires around 130 MB of storage. Not only do you get a fully-fledged Linux environment but a large selection of packages from the repository. Binary packages are thinned out and split, giving you even more control over what you install, which in turn keeps your environment as small and efficient as possible.

Switching from Fedora to Alpine as a container base image eliminated inconsistent Selenium test failures and produced more stable benchmark results. The reason is architectural: musl libc's simpler memory allocator and BusyBox's minimal userspace reduce non-deterministic behavior from background services and glibc's complex thread-local storage. The 8MB base image size also means faster container pulls, lower registry costs, and a dramatically smaller attack surface for CVE scanning.

Intel Alder Lake on Linux: Thread Director Scheduler Lags Windows 11

 
Just like with the recent Rocket Lake benchmarking on Windows 11, Linux was leading. In this complementary Tiger Lake testing, Ubuntu 21.10 was in first place over Windows 11 for 75% of the benchmarks. As I have been showing since the Alder Lake launch day earlier this month, the Core i5 12600K and Core i9 12900K performance under Linux can be quite good and competitive with AMD Ryzen on Ubuntu and other distributions. However, as shown by these benchmarks there is more uplift possible still under Linux if Intel gets their Thread Director support in order and should also take care of the higher run-to-run variance now exhibited under Linux and not Windows 11. Stay tuned to Phoronix for learning more about the ongoing Alder Lake developments and performance under Linux.

Alder Lake's hybrid big.LITTLE architecture (Performance-cores + Efficiency-cores) requires an Intel Thread Director-aware scheduler to place workloads on the right core type. Windows 11 shipped with this support at launch; Linux's CFS scheduler needed months of additional patches. This pattern repeats with every major architectural innovation: hardware vendors develop and test against Windows first, and Linux kernel developers must reverse-engineer optimal scheduling behavior after the fact.

Btrfs Extent Tree v2: Breaking Format Change Targets Core Performance

 
tl;dr I’m working on a large set of on-disk format changes to address some of the more painful parts of Btrfs’s design. There’s a lot of discrete changes here, but they’ll all go under the single umbrella of “extent-tree-v2.” We’ve spent a few months going back and forth on different approaches, and have finally settled on a final set of changes. The global roots and block group root patches have been completed and submitted, but there’s a lot more change coming.

A non-backwards-compatible on-disk format change is the most disruptive kind of breaking change a filesystem can make. Unlike API changes that can be versioned, on-disk formats determine whether existing data remains readable. The extent-tree-v2 redesign addresses real scalability bottlenecks (global lock contention on the extent tree, metadata I/O amplification on large volumes), but the migration path for existing Btrfs deployments on SUSE Enterprise Linux and Fedora Workstation will be the true test of this decision.

OpenZFS 3.0 Roadmap: macOS Support, DirectIO, and RAIDZ Expansion

 
The annual OpenZFS Developer Summit wrapped up yesterday with interesting talks on this open-source, cross-platform ZFS file-system implementation. ZFS co-creator Matt Ahrens kicked things off as usual, including touching on future work and possible expectations for OpenZFS 3.0. Given the annual major release cadence, OpenZFS 3.0 is up next for the project that currently has support for Linux and FreeBSD systems. Some of the possible features expressed for OpenZFS 3.0 include macOS support, DirectIO, RAIDZ expansion, Linux namespaces, ZFS on object store, FIEMAP, VDEV properties, async DMU, and more. We'll see though next year ultimately what pans out for the next ZFS release.

Official macOS support would make OpenZFS the only enterprise-grade filesystem running production workloads across Linux, FreeBSD, and macOS. DirectIO support eliminates the double-caching penalty that currently hurts database workloads on ZFS, and RAIDZ expansion (adding disks to existing vdevs) addresses the most common operational pain point in ZFS storage administration. Together, these features close the remaining gaps that have kept some organizations on ext4 or XFS.

ARMv9 Launches Confidential Compute Architecture for Hardware Isolation

 
Hardware security isn’t a given: A single vulnerability could compromise an entire network, and we face new attempts to exploit Arm technology every day. To get a sense for how pervasive the problem is, Symantec detected almost 19 million attacks on its Internet of Things (IoT) honeypots in the first quarter of 2020. That’s a rate of more than 100 attacks per second, 13 percent higher than we saw towards the end of 2019. In Armv9, we are introducing new features designed to deliver confidential computing – now an industry priority – at scale. Ordinarily, the operating system (OS) of a device has the highest authority and can see and do everything. Confidential compute changes that, and while the OS still decides what can run when, applications sit in a separate hardware-protected area of memory isolated from everything else in the system. The Arm Confidential Compute Architecture (CCA) builds on the foundations of Arm TrustZone by enabling, for example, your personal banking information to be fully separated from your smartphone’s social media applications. Arm CCA’s new security features mean that even if a social media app did become infected with malware, it could not spread to the rest of your device.

ARMv9's Confidential Compute Architecture (CCA) extends TrustZone's trusted execution model to isolate application memory from the operating system itself. This is ARM's answer to AMD SEV-SNP and Intel TDX, both of which provide similar VM-level memory encryption for cloud workloads. For hyperscaler customers running on ARM-based instances (AWS Graviton, Azure Cobalt), CCA means confidential computing becomes available on ARM silicon for the first time, closing a critical enterprise security gap.

AMD Zen 4 EPYC: Genoa at 96 Cores with DDR5 and PCIe 5.0

 
In addition to announcing Milan-X processors at the virtual Accelerated Data Center Premiere event, AMD just provided some new public details concerning next-generation Zen 4 processors. The key takeaways from today's disclosures around the Zen 4 road-map include: EPYC "Genoa" processors will feature up to 96 high performance Zen 4 cores with DDR5 and PCIe 5.0 support. Zen 4 as expected uses the TSMC 5nm process. EPYC "Bergamo" is a high-core count compute engine designed for cloud-native workloads and other environments. Bergamo will feature up to 128 Zen 4 "C" cores. Bergamo will carry all of the same Genoa features like DDR5, PCIe 5.0, CXL 1.1, and more. Bergamo is socket-compatible with Genoa. The "Zen 4 C" is software-compatible with Zen 4 but with enhancements for cloud workloads and power efficiency enhancements. Look for more information on Zen 4 desktop and server platforms in 2022 and the expected launch later in the year. Bergamo isn't expected until H1'2023.

AMD's dual-socket strategy is smart: Genoa targets high-performance workloads with 96 full Zen 4 cores, while Bergamo's 128 density-optimized cores target cloud-native containerized workloads where per-core licensing costs (common with databases and enterprise software) make core count the primary optimization target. The Sun Microsystems cautionary tale applies here: technical superiority alone does not guarantee market dominance. AMD must convert its architectural lead into sustained enterprise procurement wins.

AMD Ryzen 7 5700G iGPU Outperforms Intel UHD 770 on Linux

 
Published yesterday was the Core i5 12600K / Core i9 12900K Linux review looking at the exciting performance uplift provided by Alder Lake. One of the areas only talked about briefly in yesterday's article were the UHD Graphics 770 found with these new desktop processors, due to time constraints with only having a few days so far for carrying out tests. Today the initial batch of UHD Graphics 770 / ADL-S GT1 Linux graphics/gaming benchmarks have wrapped up to show how the Intel graphics performance compares to prior generation Rocket Lake as well as AMD's Ryzen 7 5700G.

Intel's UHD Graphics 770 (ADL-S GT1) falling behind AMD's Ryzen 7 5700G Vega iGPU on Linux reflects both a driver maturity gap and architectural constraints. Intel's integrated graphics rely on a single execution unit design that prioritizes die area efficiency, while AMD's RDNA-derived iGPUs benefit from shared driver infrastructure with their discrete Radeon GPUs. For workstation users who skip discrete GPUs, this benchmark gap makes AMD the stronger choice for Linux desktops.

Intel oneAPI and OpenCL Compute Runtime Now Available on WSL2

 
Hardware-accelerated oneAPI Level Zero, OpenVINO, and OpenCL on Intel graphics hardware can now be enjoyed within the WSL2 environment when using the latest updates and drivers. Like with the rest of the WSL2 stack and capabilities from other GPU vendors, this is at a near-native level of performance. Notable with this effort is Microsoft getting Intel's open-source Compute-Runtime working atop Microsoft's open-source but not mainlined kernel driver. This is in reference to the DirectX "dxgkrnl" driver that had slim prospects of being mainlined when published last year in large part over lack of open-source clients. With this wired up Intel Compute-Runtime code atop, there is the possibility now Microsoft will try to get their DXGKRNL driver merged to mainline.

Intel's Compute-Runtime running atop Microsoft's DXGKRNL driver is a double-edged sword: it provides near-native GPU compute performance within WSL2, but it also creates a path for mainlining Microsoft's DirectX kernel driver into Linux. If DXGKRNL merges upstream, it would be the first Linux kernel driver whose primary purpose is interoperating with a proprietary Windows subsystem rather than driving hardware directly.

Intel Tiger Lake Benchmark: Ubuntu 21.04 Leads Windows 10 in 75% of Tests

 
With having hands on with a Dell XPS 13 9310 (Dell 0DXP1F) with the Core i7 1185G7 Tiger Lake processor (compared to prior Linux tests with the i7-1165G7), here is a fresh look at the performance of Microsoft Windows 10 Pro as shipped by Dell with all available stable updates versus a clean install of Ubuntu 21.04 Linux.

Linux leading Windows in 75% of CPU benchmarks on identical Tiger Lake hardware marks a significant shift. Five years ago, Windows consistently won general-purpose benchmarks due to better driver optimization and scheduler tuning. The reversal reflects both Linux kernel scheduler improvements (CFS bandwidth throttling, improved NUMA awareness) and Intel's increased investment in open-source Linux driver quality for their integrated graphics and power management subsystems.

Linux 5.14 Adds memfd_secret: Kernel-Isolated Memory for Processes

 
The "memfd_secret" system call is being added to the Linux 5.14 kernel to provide the ability to create memory areas that are visible only in the context of the owning process and these "secret" memory regions are not mapped by other processes or the kernel page tables. Using memfd_secret means the memory areas will only be mapped in the page table of the processes that have access to the owning file descriptor and is unmapped from the kernel direct map. Access to memfd_secret is disabled by default but requires using the secretmem_enable boot time option when booting the kernel to enable this secret memory functionality.

memfd_secret addresses a real attack vector: kernel memory read vulnerabilities (like those exposed by Spectre and Meltdown) can leak secrets from process memory mapped in kernel page tables. By unmapping secret regions from the kernel direct map entirely, memfd_secret makes these secrets invisible even to a compromised kernel. The disabled-by-default status and boot-time opt-in reflect the performance trade-off: removing pages from the direct map forces TLB flushes that can impact workloads with heavy memory pressure.