Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
From:   Jim Mattson <jmattson@google.com>
Date:   Fri, 22 Jul 2022 14:35:34 -0700
Message-ID: <CALMp9eT4-hVw9Gwp00K59JstS52vidSRcV0WW5qEhJvaY6aR5g@mail.gmail.com>
Subject: RFC: The hypervisor's responsibility to stuff the RSB
To:     kvm list <kvm@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>
Cc:     LKML <linux-kernel@vger.kernel.org>, Paul Turner <pjt@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Now that Retbleed has drawn everyone's attention back to Skylake's
RSBA behavior, I've been hearing murmurings about the hypervisor's
responsibility to stuff the RSB on VM-entry when running on RSBA
parts.

Referring back to Intel's paper, "Retpoline: A Branch Target Injection
Mitigation," it does say:

> There are also a number of events that happen asynchronously from normal =
program execution that can result in an empty RSB. Software may use =E2=80=
=9CRSB stuffing=E2=80=9D sequences whenever these asynchronous events occur=
:
>
> 1. Interrupts/NMIs/traps/aborts/exceptions which increase call depth.
> 2. System Management Interrupts (SMI) (see BIOS/Firmware Interactions).
> 3. Host VMEXIT/VMRESUME/VMENTER.
> 4. Microcode update load (WRMSR 0x79) on another logical processor of the=
 same core.
>
> Software may avoid RSB underflow by inserting an =E2=80=9CRSB stuffing=E2=
=80=9D sequence following all of the above conditions.

KVM *does* stuff the RSB on VM-exit, to protect the host kernel.
However, it fails to stuff the RSB on VM-entry. Stuffing the RSB on
VM-entry is necessary to protect the guest if KVM has made any unsafe
changes to the RSB, such as reducing its depth. Though Intel doesn't
spell it out, the responsibility of the hypervisor on VM-entry is much
the same as the responsibility of the SMI handler on RSM.

For reference, here's the "BIOS/Firmware Interactions" section of the
aforementioned paper, referenced above:

> System Management Interrupt (SMI) handlers can leave the RSB in a state t=
hat OS code does not expect. In order to avoid RSB underflow on return from=
 SMI, an SMI handler may implement RSB stuffing (for parts identified in Ta=
ble 5) before returning from System Management Mode (SMM). Updated SMI hand=
lers are provided via system BIOS updates.

I don't really want to do this, but I don't want to be negligent, either.

Thoughts?