Re: [PATCH v6 1/1] x86: kvm: svm: set up ERAPS support for guests

[Sean Christopherson <seanjc@google.com>]

n Thu, Nov 20, 2025, Sean Christopherson wrote:
> --
> From: Amit Shah <amit.shah@amd.com>
> Date: Fri, 7 Nov 2025 10:32:39 +0100
> Subject: [PATCH] KVM: SVM: Virtualize and advertise support for ERAPS
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> AMD CPUs with the Enhanced Return Address Predictor Security (ERAPS)
> feature (available on Zen5+) obviate the need for FILL_RETURN_BUFFER
> sequences right after VMEXITs.  ERAPS adds guest/host tags to entries in
> the RSB (a.k.a. RAP).  This helps with speculation protection across the
> VM boundary, and it also preserves host and guest entries in the RSB that
> can improve software performance (which would otherwise be flushed due to
> the FILL_RETURN_BUFFER sequences).
> 
> Importantly, ERAPS also improves cross-domain security by clearing the RAP
> in certain situations.  Specifically, the RAP is cleared in response to
> actions that are typically tied to software context switching between
> tasks.  Per the APM:
> 
>   The ERAPS feature eliminates the need to execute CALL instructions to
>   clear the return address predictor in most cases. On processors that
>   support ERAPS, return addresses from CALL instructions executed in host
>   mode are not used in guest mode, and vice versa. Additionally, the
>   return address predictor is cleared in all cases when the TLB is
>   implicitly invalidated and in the following cases:
> 
>   • MOV CR3 instruction
>   • INVPCID other than single address invalidation (operation type 0)
> 
> ERAPS also allows CPUs to extends the size of the RSB/RAP from the older
> standard (of 32 entries) to a new size, enumerated in CPUID leaf
> 0x80000021:EBX bits 23:16 (64 entries in Zen5 CPUs).
> 
> In hardware, ERAPS is always-on, when running in host context, the CPU
> uses the full RSB/RAP size without any software changes necessary.
> However, when running in guest context, the CPU utilizes the full size of
> the RSB/RAP if and only if the new ALLOW_LARGER_RAP flag is set in the
> VMCB; if the flag is not set, the CPU limits itself to the historical size
> of 32 entires.
> 
> Requiring software to opt-in for guest usage of RAPs larger than 32 entries
> allows hypervisors, i.e. KVM, to emulate the aforementioned conditions in
> which the RAP is cleared as well as the guest/host split.  E.g. if the CPU
> unconditionally used the full RAP for guests, failure to clear the RAP on
> transitions between L1 or L2, or on emulated guest TLB flushes, would
> expose the guest to RAP-based attacks as a guest without support for ERAPS
> wouldn't know that its FILL_RETURN_BUFFER sequence is insufficient.
> 
> Address the ~two broad categories of ERAPS emulation, and advertise
> ERAPS support to userspace, along with the RAP size enumerated in CPUID.
> 
> 1. Architectural RAP clearing: as above, CPUs with ERAPS clear RAP entries
>    on several conditions, including CR3 updates.  To handle scenarios
>    where a relevant operation is handled in common code (emulation of
>    INVPCID and to a lesser extent MOV CR3), piggyback VCPU_EXREG_CR3 and
>    create an alias, VCPU_EXREG_ERAPS.  SVM doesn't utilize CR3 dirty
>    tracking, and so for all intents and purposes VCPU_EXREG_CR3 is unused.
>    Aliasing VCPU_EXREG_ERAPS ensures that any flow that writes CR3 will
>    also clear the guest's RAP, and allows common x86 to mark ERAPS vCPUs
>    as needing a RAP clear without having to add a new request (or other
>    mechanism).
> 
> 2. Nested guests: the ERAPS feature adds host/guest tagging to entries
>    in the RSB, but does not distinguish between the guest ASIDs.  To
>    prevent the case of an L2 guest poisoning the RSB to attack the L1
>    guest, the CPU exposes a new VMCB bit (CLEAR_RAP).  The next
>    VMRUN with a VMCB that has this bit set causes the CPU to flush the
>    RSB before entering the guest context.  Set the bit in VMCB01 after a
>    nested #VMEXIT to ensure the next time the L1 guest runs, its RSB
>    contents aren't polluted by the L2's contents.  Similarly, before
>    entry into a nested guest, set the bit for VMCB02, so that the L1
>    guest's RSB contents are not leaked/used in the L2 context.
> 
> Enable ALLOW_LARGER_RAP (and emulate RAP clears) if and only if ERAPS is
> exposed to the guest.  Enabling ALLOW_LARGER_RAP unconditionally wouldn't
> cause any functional issues, but ignoring userspace's (and L1's) desires
> would put KVM into a grey area, which is especially undesirable due to the
> potential security implications.  E.g. if a use case wants to have L1 do
> manual RAP clearing even when ERAPS is present in hardware, enabling
> ALLOW_LARGER_RAP could result in L1 leaving stale entries in the RAP.
> 
> ERAPS is documented in AMD APM Vol 2 (Pub 24593), in revisions 3.43 and
> later.
> 
> Signed-off-by: Amit Shah <amit.shah@amd.com>
> Co-developed-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---

Applied to kvm-x86 svm.

[1/1] KVM: SVM: Virtualize and advertise support for ERAPS
      https://github.com/kvm-x86/linux/commit/db5e82496492

--
https://github.com/kvm-x86/linux/tree/next