mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Liran Alon <liran.alon@oracle.com>,
	jmattson@google.com, x86@kernel.org, dwmw@amazon.co.uk,
	bp@alien8.de, aliguori@amazon.com, thomas.lendacky@amd.com,
	rkrcmar@redhat.com, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: [PATCH 3/8] kvm: vmx: pass MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD down to the guest
Date: Wed, 10 Jan 2018 14:20:13 +0100	[thread overview]
Message-ID: <c31716da-a3d1-35e9-7671-8b8b80a5879e@redhat.com> (raw)
In-Reply-To: <EBDECE05-48A1-4906-AC0D-8D5928A799F2@gmail.com>

On 10/01/2018 06:03, Nadav Amit wrote:
>>
>> Of course the code will become something like
>>
>> 	if (using_ibrs || vmx->spec_ctrl != 0)
>> 		wrmsrl(MSR_IA32_SPEC_CTRL, host_ibrs);
>>
>> optimizing the case where the host is using retpolines.
> Excuse my ignorance: Can you point me to the specifications that mention “we
> should set IBRS bit even if it was already set on every #VMExit” ?

All I have is some PowerPoint slides from Intel. :(  They say:

---
A near indirect jump/call/return may be affected by code in a less
privileged prediction mode that executed AFTER IBRS mode was last
written with a value of 1. There is no need to clear IBRS before writing
it with a value of 1. Unconditionally writing it with a value of 1 after
the prediction mode change is sufficient.

VMX non-root is considered a less privileged prediction mode than VM
root.  CPL 3 is considered a less privileged prediction mode than CPL0,
1, 2.

Some processors may enhance IBRS such that it isolates prediction modes
effectively and at higher performance if left set instead of being set
when enter OS and VMM and cleared when entering applications.  [This is]
enumerated by IA32_ARCH_CAPABILITIES[1].
---

(Yes, it literally says VM root, not VMX root).

But I think this is an awful specification.  For two reasons:

* a simple specification that does "IBRS=1 blocks indirect branch
prediction altogether" would actually satisfy the specification just as
well, and it would be nice to know if that's what the processor actually
does.

* the future case with enhanced IBRS still requires the expensive IBPB
when switching between applications or between guests, where the
PCID/VPID (and PCID/VPID invalidation) could be used to remove that need.

Paolo

  reply	other threads:[~2018-01-10 13:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 16:48 Liran Alon
2018-01-09 16:57 ` Paolo Bonzini
2018-01-10  5:03   ` Nadav Amit
2018-01-10 13:20     ` Paolo Bonzini [this message]
2018-01-10 14:06       ` Arjan van de Ven
2018-01-10 14:28         ` Paolo Bonzini
2018-01-10 15:41           ` Konrad Rzeszutek Wilk
2018-01-10 15:45             ` Paolo Bonzini
2018-01-10 15:48             ` Woodhouse, David
2018-01-10 15:56               ` Paolo Bonzini
2018-01-10 16:05                 ` David Woodhouse
2018-01-12 23:17     ` Jim Mattson
2018-01-12 23:19       ` Nadav Amit
  -- strict thread matches above, loose matches on Subject: below --
2018-01-10 16:51 Liran Alon
2018-01-10 17:07 ` David Woodhouse
2018-01-10 16:19 Liran Alon
2018-01-10 16:27 ` Paolo Bonzini
2018-01-10 17:14   ` Jim Mattson
2018-01-10 17:16     ` Paolo Bonzini
2018-01-10 17:23       ` Nadav Amit
2018-01-10 17:32         ` Jim Mattson
2018-01-10 16:47 ` David Woodhouse
2018-01-10  0:33 Liran Alon
2018-01-09 16:06 Liran Alon
2018-01-09 12:03 [PATCH v2 0/8] KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") mitigations to guest Paolo Bonzini
2018-01-09 12:03 ` [PATCH 3/8] kvm: vmx: pass MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD down to the guest Paolo Bonzini
2018-01-13 10:16   ` Longpeng (Mike)
2018-01-15  9:23     ` Paolo Bonzini
2018-01-15  9:34       ` Thomas Gleixner

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=c31716da-a3d1-35e9-7671-8b8b80a5879e@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aliguori@amazon.com \
    --cc=arjan@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dwmw@amazon.co.uk \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liran.alon@oracle.com \
    --cc=nadav.amit@gmail.com \
    --cc=rkrcmar@redhat.com \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /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

all inboxes | Powered by JetHome®