linux-kernel - RFC: The hypervisor's responsibility to stuff the RSB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Jul 2022 14:35:34 -0700
From:   Jim Mattson <jmattson@...gle.com>
To:     kvm list <kvm@...r.kernel.org>, Paolo Bonzini <pbonzini@...hat.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, Paul Turner <pjt@...gle.com>
Subject: RFC: The hypervisor's responsibility to stuff the RSB

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 “RSB stuffing” 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 “RSB stuffing” 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 that 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 Table 5) before returning from System Management Mode (SMM). Updated SMI handlers are provided via system BIOS updates.

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

Thoughts?