linux-kernel - [PATCH 0/5] nSVM: L1 -> L2 event injection fixes and a self-test

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]

Message-Id: <cover.1646944472.git.maciej.szmigiero@oracle.com>
Date:   Thu, 10 Mar 2022 22:38:36 +0100
From:   "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Brijesh Singh <brijesh.singh@....com>,
        Jon Grimm <Jon.Grimm@....com>,
        David Kaplan <David.Kaplan@....com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Liam Merwick <liam.merwick@...cle.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH 0/5] nSVM: L1 -> L2 event injection fixes and a self-test

From: "Maciej S. Szmigiero" <maciej.szmigiero@...cle.com>

There are some issues with respect to nSVM L1 -> L2 event injection.

First, the next_rip field of a VMCB is *not* an output-only field for a VMRUN.
This field value (instead of the saved guest RIP) in used by the CPU for
the return address pushed on stack when injecting a software interrupt or
INT3 or INTO exception (this was confirmed by AMD).

On a VMRUN that does event injection it has similar function as VMX's
VM_ENTRY_INSTRUCTION_LEN field, although, in contrast to VMX, it holds an
absolute RIP value, not a relative increment.

However, KVM seems to treat this field as a unidirectional hint from the CPU
to the hypervisor - there seems to be no specific effort to maintain this
field consistency for such VMRUN.

This is mostly visible with running a nested guest, with L1 trying to inject
an event into its L2.
In this case, we need to make sure the next_rip field gets synced from
vmcb12 to vmcb02.

Another issue is that pending L1 -> L2 events are forgotten if there is an
intervening L0 VMEXIT during their delivery.
We need to make sure they are remembered (including their desired next_rip
field value) until they are either re-injected into L2 successfully or
returned back to L1 in the EXITINTINFO field upon a nested VMEXIT.

A new KVM self-test that checks for the nSVM issues described above is
included in this patch series.

These issues are SVM-specific - all the use cases described above already
work correctly with VMX.

This patch set was tested with both Linux and Windows nested guests.

  KVM: nSVM: Sync next_rip field from vmcb12 to vmcb02
  KVM: SVM: Downgrade BUG_ON() to WARN_ON() in svm_inject_irq()
  KVM: nSVM: Don't forget about L1-injected events
  KVM: nSVM: Restore next_rip when doing L1 -> L2 event re-injection
  KVM: selftests: nSVM: Add svm_nested_soft_inject_test

 arch/x86/kvm/svm/nested.c                     |  69 +++++++-
 arch/x86/kvm/svm/svm.c                        |  60 ++++++-
 arch/x86/kvm/svm/svm.h                        |  48 ++++++
 tools/testing/selftests/kvm/.gitignore        |   1 +
 tools/testing/selftests/kvm/Makefile          |   1 +
 .../selftests/kvm/include/x86_64/svm_util.h   |   2 +
 .../kvm/x86_64/svm_nested_soft_inject_test.c  | 147 ++++++++++++++++++
 7 files changed, 324 insertions(+), 4 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/x86_64/svm_nested_soft_inject_test.c