mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Liran Alon <liran.alon@oracle.com>
Cc: jmattson@google.com, dwmw@amazon.co.uk, bp@alien8.de,
	thomas.lendacky@amd.com, aliguori@amazon.com,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU
Date: Tue, 9 Jan 2018 12:41:09 +0100	[thread overview]
Message-ID: <713b5681-a6eb-7a7b-620f-282bd67eb745@redhat.com> (raw)
In-Reply-To: <30cf953d-3132-4dbb-97ba-4b49aa949580@default>

On 09/01/2018 12:31, Liran Alon wrote:
>> On current generation processors, as I understand it, IBRS simply 
>> disables the indirect branch predictor when set to 1.  Therefore,
>> as
> This is not how I understood what IBRS does.
> 
> Intel (not sure about AMD) states that if IBRS is set, indirect
> branches will now allow their predicted target address to be
> controlled by code that executed in a less privileged prediction-mode
> before the IBRS was last written with a value of 1. (Intel also
> states that thus an indirect branch may be affected by code in a less
> privileged prediction-mode that executed AFTER IBRS mode was last
> written with a value of 1).

Difficult to say that, because AMD microcode for IBRS does not exist.
Is it even documented whether VMX/SVM non-root mode is a different
physical prediction mode.

Generally I agree you'd go by what the spec say, but we don't really
have a final spec from the vendors.  The microarchitectural level
matters much more than the spec in this case, I'm opinion: what current
microcode patches do, and how future processors plan to close the leak
once and for all.

The above ("IBRS simply disables the indirect branch predictor") was my
take-away message from private discussion with Intel.  My guess is that
the vendors are just handwaving a spec that doesn't match what they have
implemented, because honestly a microcode update is unlikely to do much
more than an old-fashioned chicken bit.  Maybe on Skylake it does
though, since the performance characteristics of IBRS are so different
from previous processors.  Let's ask Arjan who might have more
information about it, and hope he actually can disclose it...

Paolo

> Therefore, L2 could also inject BTB/BHB entries that will be used by
> L1: Consider the case that L2 injects values into BTB/BHB and then
> issues a hypercall which will cause #VMExit which will be forwarded
> to L1. Because L2 & L1 runs in the same prediction-mode (both Ring0
> SVM guest-mode) from physical CPU perspective, Ring0 L1 code could be
> using BTB/BHB entries injected by Ring0 L2. (The fact that L0 have
> set IBRS to 1 when exiting from L2 to L0 doesn't prevent those
> entries from being used by L1 after L0 enters L1).
> 
> This is different than what happens in non-nested case as L0 & L1
> runs in different physical prediction-modes and therefore setting
> IBRS=1 on every #VMExit should suffice.
> 
> Therefore, I don't understand how L1 setting IBRS to 1 will help him
> in this case. Maybe this mechanism works differently on AMD?
> 
>> Future processors might have a mode that says "just set IBRS=1 and
>> I'll DTRT".  If that's done by indexing the BTB using the full virtual
>> address, the CPL _and_ the ASID/PCID/VPID, then IBPB is not needed
>> here because the L2 VM uses a different ASID.  If that's done by only
>> augmenting the BTB index with the CPL, we'd need an IBPB.  But in
>> this new world we've been thrown into, that would be a processor bug...

  reply	other threads:[~2018-01-09 11:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 11:31 Liran Alon
2018-01-09 11:41 ` Paolo Bonzini [this message]
2018-01-09 14:30   ` Arjan van de Ven
  -- strict thread matches above, loose matches on Subject: below --
2018-01-09 16:01 Liran Alon
2018-01-09 15:33 Liran Alon
2018-01-09 15:56 ` Arjan van de Ven
2018-01-09 15:00 Liran Alon
2018-01-09 15:19 ` Arjan van de Ven
2018-01-09 16:17   ` Paolo Bonzini
2018-01-09 16:23     ` Arjan van de Ven
2018-01-09 16:49       ` Paolo Bonzini
2018-01-09 20:39         ` Konrad Rzeszutek Wilk
2018-01-09 20:47           ` Konrad Rzeszutek Wilk
2018-01-09 20:57             ` Jim Mattson
2018-01-09 21:11               ` Konrad Rzeszutek Wilk
2018-01-09 21:19                 ` Jim Mattson
2018-01-09 21:42               ` Paolo Bonzini
2018-01-09 21:59                 ` Jim Mattson
2018-01-09 21:56           ` Paolo Bonzini
2018-01-08 18:08 [PATCH 0/7] KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") mitigations to guest Paolo Bonzini
2018-01-08 18:08 ` [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU Paolo Bonzini
2018-01-08 20:00   ` Liran Alon
2018-01-09 11:07     ` 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=713b5681-a6eb-7a7b-620f-282bd67eb745@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=thomas.lendacky@amd.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

all inboxes | Powered by JetHome®