Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Jacky Li <jackyli@google.com>
To: qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Zhao Liu" <zhao1.liu@intel.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Philippe Mathieu-Daudé" <philmd@mailo.com>,
	"Peter Xu" <peterx@redhat.com>,
	kvm@vger.kernel.org, "James Houghton" <jthoughton@google.com>,
	"Mingwei Zhang" <mizhang@google.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Brendan Jackman" <jackmanb@google.com>,
	"Reiji Watanabe" <reijiw@google.com>,
	"Jacky Li" <jackyli@google.com>
Subject: [RFC PATCH 0/6] Protect VMM from speculative attacks using x86 PKRU
Date: Tue, 18 Aug 2026 20:44:14 +0000	[thread overview]
Message-ID: <20260818-feature-pkey-dev-v1-0-8c0ef96a4da9@google.com> (raw)

Hi,

This RFC patch series introduces a hardware-assisted memory protection
mechanism in QEMU using x86 Protection Keys for Userspace (PKRU / MPK)
to complete the Address Space Isolation ecosystem by protecting the VMM
from guest-to-host speculative execution attacks.

In a guest-to-host speculative side-channel attack against QEMU, a
malicious guest mistrains the VMM branch predictor to execute a
speculative gadget in host mode. This gadget speculatively reads a
host secret and uses that secret as an index to touch guest RAMBlocks,
leaving an observable microarchitectural footprint in the CPU cache.
Existing mitigations like issuing IBPB on every VM-exit incur high
overhead, while guest_memfd cannot protect memory that must stay mapped.

To break this covert channel, we protect guest RAMBlocks using a
dedicated pkey (pkey_mprotect).

- During normal QEMU host userspace execution (I/O handling, timers,
  event loops), we lock this pkey by setting PKEY_DISABLE_ACCESS in
  the PKRU register via WRPKRU. Because CPU pipelines natively enforce
  PKRU restrictions during out-of-order execution, any speculative
  gadget in host mode attempting to touch guest RAMBlocks is blocked by
  the MMU at the hardware level, leaving zero footprint in the cache.

- Before entering KVM (KVM_RUN), we temporarily unlock the pkey, and
  immediately re-lock it upon returning to QEMU userspace.

- To gracefully handle legitimate host accesses to guest RAMBlocks
  when locked, a SEGV_PKUERR signal handler unlocks the pkey in the
  interrupted thread's xstate and issues an IBPB (PR_SPEC_INDIRECT_BRANCH)
  to prevent speculative leakage before resuming execution.

Comments and feedback on this approach are very welcome!

To: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Zhao Liu <zhao1.liu@intel.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@mailo.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: kvm@vger.kernel.org
Cc: James Houghton <jthoughton@google.com>
Cc: Mingwei Zhang <mizhang@google.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Brendan Jackman <jackmanb@google.com>
Cc: Reiji Watanabe <reijiw@google.com>
Cc: Jacky Li <jackyli@google.com>

Signed-off-by: Jacky Li <jackyli@google.com>
---
Jacky Li (6):
      [RFC PATCH 1/6] x86: Introduce basic PKRU hardware wrappers
      [RFC PATCH 2/6] kvm: Add guest memory Pkey initialization
      [RFC PATCH 3/6] physmem: Tag guest RAMBlocks with Protection Key
      [RFC PATCH 4/6] kvm: Lock guest RAMBlocks via PKRU during host userspace execution
      [RFC PATCH 5/6] x86: Add xstate parsing and PKRU offset detection
      [RFC PATCH 6/6] kvm: Implement SIGSEGV sentinel for Pkey recovery

 MAINTAINERS               |   1 +
 accel/kvm/kvm-all.c       |   7 +-
 include/exec/cpu-common.h |   4 +
 include/qemu/mmap-alloc.h |   5 +
 system/physmem.c          |  22 ++-
 system/vl.c               |   1 +
 util/meson.build          |   2 +-
 util/mmap-alloc.c         |   3 +-
 util/pkey.c               | 386 ++++++++++++++++++++++++++++++++++++++++++++++
 9 files changed, 424 insertions(+), 7 deletions(-)
---
base-commit: fa19879df1658f96ac07365fca8835b7decd6995
change-id: 20260729-feature-pkey-dev-c8a026db85b4

Best regards,
-- 
Jacky Li <jackyli@google.com>


             reply	other threads:[~2026-08-18 20:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18 20:44 Jacky Li [this message]
2026-08-18 20:44 ` [RFC PATCH 1/6] x86: Introduce basic PKRU hardware wrappers Jacky Li
2026-08-18 20:44 ` [RFC PATCH 2/6] kvm: Add guest memory Pkey initialization Jacky Li
2026-08-18 22:03   ` Dave Hansen
2026-08-18 20:44 ` [RFC PATCH 3/6] physmem: Tag guest RAMBlocks with Protection Key Jacky Li
2026-08-18 20:44 ` [RFC PATCH 4/6] kvm: Lock guest RAMBlocks via PKRU during host userspace execution Jacky Li
2026-08-18 20:44 ` [RFC PATCH 5/6] x86: Add xstate parsing and PKRU offset detection Jacky Li
2026-08-18 20:44 ` [RFC PATCH 6/6] kvm: Implement SIGSEGV sentinel for Pkey recovery Jacky Li
2026-08-18 21:55   ` Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260818-feature-pkey-dev-v1-0-8c0ef96a4da9@google.com \
    --to=jackyli@google.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jackmanb@google.com \
    --cc=jthoughton@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=mizhang@google.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@mailo.com \
    --cc=qemu-devel@nongnu.org \
    --cc=reijiw@google.com \
    --cc=richard.henderson@linaro.org \
    --cc=zhao1.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox