kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Singh, Brijesh" <brijesh.singh@amd.com>,
	Liran Alon <liran.alon@oracle.com>,
	"rkrcmar@redhat.com" <rkrcmar@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v2] KVM: SVM: Fix detection of AMD Errata 1096
Date: Thu, 18 Jul 2019 12:49:40 +0200	[thread overview]
Message-ID: <d0445fde-afe1-f3fe-6c26-3d8eef8dc4d8@redhat.com> (raw)
In-Reply-To: <462d7b68-94c9-2e9b-23f8-bc2567fa62af@amd.com>

Brijesh,

just one thing I'd like to double check: does the erratum really depend 
on guest CR4.SMAP, or rather on host CR4.SMAP?  (Of course the SMEP 
check instead needs to use guest CR4.SMEP).

And here is a commit message with style fixes:

---
When CPU raise #NPF on guest data access and guest CR4.SMAP=1, it is
possible that CPU microcode implementing DecodeAssist will fail
to read bytes of instruction which caused #NPF. This is AMD errata
1096 and it happens because CPU microcode reading instruction bytes
incorrectly attempts to read code as implicit supervisor-mode data
accesses (that is, just like it would read e.g. a TSS), which are
susceptible to SMAP faults. The microcode reads CS:RIP and if it is
a user-mode address according to the page tables, the processor
gives up and returns no instruction bytes.  In this case,
GuestIntrBytes field of the VMCB on a VMEXIT will incorrectly
return 0 instead of the correct guest instruction bytes.

Current KVM code attemps to detect and workaround this errata, but it
has multiple issues:

1) It mistakenly checks if guest CR4.SMAP=0 instead of guest CR4.SMAP=1,
which is required for encountering a SMAP fault.

2) It assumes SMAP faults can only occur when vCPU CPL==3.
However, in case vCPU CR4.SMEP=0, the guest can execute an instruction
which reside in a user-accessible page with CPL<3 priviledge. If this
instruction raise a #NPF on it's data access, then CPU DecodeAssist
microcode will still encounter a SMAP violation.  Even though no sane
OS will do so (as it's an obvious priviledge escalation vulnerability),
we still need to handle this semanticly correct in KVM side.

Note that (2) *is* a useful optimization, because CR4.SMAP=1 is an easy
triggerable condition and guests usually enable SMAP together with SMEP,
If the vCPU has CR4.SMEP=1, the errata could indeed be encountered only
at guest CPL3; otherwise, the CPU would raise a SMEP fault to guest
instead of #NPF.  We keep this condition to avoid false positives in
the detection of the errata.

In addition, to avoid future confusion and improve code readbility,
include details of the errata in code and not just in commit message.
---

Paolo

  reply	other threads:[~2019-07-18 10:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-16 23:56 [PATCH v2] KVM: SVM: Fix detection of AMD Errata 1096 Liran Alon
2019-07-17 20:44 ` Singh, Brijesh
2019-07-18 10:49   ` Paolo Bonzini [this message]
2019-07-18 15:25     ` Singh, Brijesh
2019-07-18 10:50 ` Paolo Bonzini

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=d0445fde-afe1-f3fe-6c26-3d8eef8dc4d8@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=brijesh.singh@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=liran.alon@oracle.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@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;
as well as URLs for NNTP newsgroup(s).