VMScape: Cracking VM-Host Isolation in the Speculative Execution Age & How Linux Patches Respond

4 days 9 hours ago
by George Whittaker Introduction

In the world of modern CPUs, speculative execution, where a processor guesses ahead on branches and executes instructions before the actual code path is confirmed, has long been recognized as a performance booster. However, it has also given rise to a class of vulnerabilities collectively known as “Spectre” attacks, where microarchitectural side states (such as the branch target buffer, caches, or predictor state) are mis-exploited to leak sensitive data.

Now, a new attack variant, dubbed VMScape, exposes a previously under-appreciated weakness: the isolation between a guest virtual machine and its host (or hypervisor) in the branch predictor domain. In simpler terms: a malicious VM can influence the CPU’s branch predictor in such a way that when control returns to the host, secrets in the host or hypervisor can be exposed. This has major implications for cloud security, virtualization environments, and kernel/hypervisor protections.

In this article we’ll walk through how VMScape works, the CPUs and environments it affects, how the Linux kernel and hypervisors are mitigating it, and what users, cloud operators and admins should know (and do).

What VMScape Is & Why It Matters The Basics of Speculative Side-Channels

Speculative execution vulnerabilities like Spectre exploit the gap between architectural state (what the software sees as completed instructions) and microarchitectural state (what the CPU has done internally, such as cache loads, branch predictor updates, etc). Even when speculative paths are rolled back architecturally, side-effects in the microarchitecture can remain and be probed by attackers.

One of the original variants, Spectre-BTI (Branch Target Injection, also called Spectre v2) leveraged the Branch Target Buffer (BTB) / predictor to redirect speculative execution along attacker-controlled paths. Over time, hardware and software mitigations (IBRS, eIBRS, IBPB, STIBP) have been introduced. But VMScape shows that when virtualization enters the picture, the isolation assumptions break down.

VMScape: Guest to Host via Branch Predictor

VMScape (tracked as CVE‑2025‑40300) is described by researchers from ETH Zürich as “the first Spectre-based end-to-end exploit in which a malicious guest VM can leak arbitrary sensitive information from the host domain/hypervisor, without requiring host code modifications and in default configuration.”

Here are the key elements making VMScape significant:

  • The attack is cross-virtualization: a guest VM influences the host’s branch predictor state (not just within the guest).

Go to Full Article
George Whittaker

Banking on Collaboration: The 2025 State of Open Source in Financial Services

5 days 6 hours ago

This week in New York City at the Open Source in Finance Forum we marked an exciting milestone. This is the fifth consecutive year that Linux Foundation Research and FINOS have collaborated on the State of Open Source in Financial Services Report, and the insights from this year's study are not only impactful for the financial services sector at large, they extend far beyond it. 

Hilary Carter

Disaggregated Routing with SONiC and VPP: Architecture and Integration – Part One

5 days 11 hours ago

The networking industry is undergoing a fundamental architectural transformation, driven by the relentless demands of cloud-scale data centers and the rise of software-defined infrastructure. At the heart of this evolution is the principle of disaggregation: the systematic unbundling of components that were once tightly integrated within proprietary, monolithic systems.  This movement began with the separation […]

The post Disaggregated Routing with SONiC and VPP: Architecture and Integration – Part One appeared first on Linux.com.

Linux.com Editorial Staff

[Testing Update] 2025-10-21 - Mesa, Firefox-Beta, Rebuilds

6 days 8 hours ago

Hello community, here we have another set of package updates. Welcome to our new development cycle of Manjaro 25.1.0, code-named ‘Anh-Linh’. It is not sure yet if we will focus on Plasma 6.4 series or adopt 6.5 series early on. For sure we will introduce GNOME 49 and maybe Cosmic 1.0 (Beta).

Current Promotions Recent News Valkey to replace Redis in the [extra] Repository (click for more details) Previous News Finding information easier about Manjaro (click for more details) Notable Package Updates Additional Info Python 3.13 info (click for more details) Info about AUR packages (click for more details)

Get our latest daily developer images now from Github: Plasma, GNOME, XFCE. You can get the latest stable releases of Manjaro from CDN77.

Our current supported kernels
  • linux54 5.4.300
  • linux510 5.10.245
  • linux515 5.15.195
  • linux61 6.1.157
  • linux66 6.6.113
  • linux612 6.12.54
  • linux616 6.16.12 [EOL]
  • linux617 6.17.4
  • linux618 6.18.0-rc2
  • linux61-rt 6.1.156_rt56
  • linux66-rt 6.6.112_rt63
  • linux612-rt 6.12.49_rt13
  • linux616-rt 6.16.0_rt3
  • linux617-rt 6.17.1_rt5

Package Changes (10/21/25 18:30 CEST)

  • testing core x86_64: 1 new and 1 removed package(s)
  • testing extra x86_64: 426 new and 429 removed package(s)
  • testing multilib x86_64: 20 new and 20 removed package(s)

A list of all changes can be found here.

Click to view the poll.

Check if your mirror has already synced:

15 posts - 8 participants

Read full topic

philm

Self-Tuning Linux Kernels: How LLM-Driven Agents Are Reinventing Scheduler Policies

6 days 9 hours ago
by George Whittaker Introduction

Modern computing systems rely heavily on operating-system schedulers to allocate CPU time fairly and efficiently. Yet many of these schedulers operate blindly with respect to the meaning of workloads: they cannot distinguish, for example, whether a task is latency-sensitive or batch-oriented. This mismatch, between application semantics and scheduler heuristics, is often referred to as the semantic gap.

A recent research framework called SchedCP aims to close that gap. By using autonomous LLM‐based agents, the system analyzes workload characteristics, selects or synthesizes custom scheduling policies, and safely deploys them into the kernel, without human intervention. This represents a meaningful step toward self-optimizing, application-aware kernels.

In this article we will explore what SchedCP is, how it works under the hood, the evidence of its effectiveness, real-world implications, and what caveats remain.

Why the Problem Matters

At the heart of the issue is that general-purpose schedulers (for example the Linux kernel’s default policy) assume broad fairness, rather than tailoring scheduling to what your application cares about. For instance:

  • A video-streaming service may care most about minimal tail latency.

  • A CI/CD build system may care most about throughput and job completion time.

  • A cloud analytics job may prefer maximum utilisation of cores with less concern for interactive responsiveness.

Traditional schedulers treat all tasks mostly the same, tuning knobs generically. As a result, systems often sacrifice optimisation opportunities. Some prior efforts have used reinforcement-learning techniques to tune scheduler parameters, but these approaches have limitations: slow convergence, limited generalisation, and weak reasoning about why a workload behaves as it does.

SchedCP starts from the observation that large language models can reason semantically about workloads (expressed in plain language or structured summaries), propose new scheduling strategies, and generate code via eBPF that is loaded into the kernel via the sched_ext interface. Thus, a custom scheduler (or modified policy) can be developed specifically for a given workload scenario, and in a self-service, automated way.

Architecture & Key Components

SchedCP comprises two primary subsystems: a control-plane framework and an agent loop that interacts with it. The framework decouples “what to optimise” (reasoning) from “how to act” (execution) in order to preserve kernel stability while enabling powerful optimisations.

Here are the major components:

Go to Full Article
George Whittaker

[Testing Update] 2025-10-20 - Kernels, Systemd, GNOME, Certbot, Deepin, Firefox

1 week ago

Hello community, here we have another set of package updates. Welcome to our new development cycle of Manjaro 25.1.0, code-named ‘Anh-Linh’. It is not sure yet if we will focus on Plasma 6.4 series or adopt 6.5 series early on. For sure we will introduce GNOME 49 and maybe Cosmic 1.0 (Beta).

Current Promotions Recent News Valkey to replace Redis in the [extra] Repository (click for more details) Previous News Finding information easier about Manjaro (click for more details) Notable Package Updates
  • Some Kernels got updated
    • Kernel 6.16 series was marked EOL
    • Kernel linux615-rt was removed
    • Kernel linux617-rt got added
  • Systemd 257.10
  • More GNOME 49.1 packages
  • Certbot 5.1.0
  • More Deepin updates
  • Firefox 144.0 and 145.0b3
  • Thunderbird 144.0.1
  • Gstreamer 1.26.7
  • OpenSearch 3.3.0
  • Qemu 10.1.1
  • Haskell and Python updates
Additional Info Python 3.13 info (click for more details) Info about AUR packages (click for more details)

Get our latest daily developer images now from Github: Plasma, GNOME, XFCE. You can get the latest stable releases of Manjaro from CDN77.

Our current supported kernels
  • linux54 5.4.300
  • linux510 5.10.245
  • linux515 5.15.195
  • linux61 6.1.157
  • linux66 6.6.113
  • linux612 6.12.54
  • linux616 6.16.12 [EOL]
  • linux617 6.17.4
  • linux618 6.18.0-rc2
  • linux61-rt 6.1.156_rt56
  • linux66-rt 6.6.112_rt63
  • linux612-rt 6.12.49_rt13
  • linux616-rt 6.16.0_rt3
  • linux617-rt 6.17.1_rt5

Package Changes (10/20/25 15:35 CEST)

  • testing core x86_64: 30 new and 31 removed package(s)
  • testing extra x86_64: 1211 new and 1360 removed package(s)
  • testing multilib x86_64: 12 new and 12 removed package(s)

A list of all changes can be found here.

Click to view the poll.

Check if your mirror has already synced:

6 posts - 6 participants

Read full topic

philm