Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 29 Apr 2022 22:59:11 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     Sean Christopherson <seanjc@google.com>
Cc:     Jon Kohler <jon@nutanix.com>, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Balbir Singh <sblbir@amazon.com>,
        Kim Phillips <kim.phillips@amd.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Kees Cook <keescook@chromium.org>,
        Waiman Long <longman@redhat.com>
Subject: Re: [PATCH v3] x86/speculation, KVM: only IBPB for
 switch_mm_always_ibpb on vCPU load
Message-ID: <YmxRnwSUBIkOIjLA@zn.tnic>
References: <20220422162103.32736-1-jon@nutanix.com>
 <YmwZYEGtJn3qs0j4@zn.tnic>
 <645E4ED5-F6EE-4F8F-A990-81F19ED82BFA@nutanix.com>
 <Ymw9UZDpXym2vXJs@zn.tnic>
 <YmxKqpWFvdUv+GwJ@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <YmxKqpWFvdUv+GwJ@google.com>
Precedence: bulk

On Fri, Apr 29, 2022 at 08:29:30PM +0000, Sean Christopherson wrote:
> That's why there's a bunch of hand-waving.

Well, I'm still not sure what this patch is trying to fix but both your
latest replies do sound clearer...

> Can you clarify what "this" is?  Does "this" mean "this patch", or does it mean

This patch.

> "this IBPB when switching vCPUs"?  Because if it means the latter, then I think
> you're in violent agreement; the IBPB when switching vCPUs is pointless and
> unnecessary.

Ok, let's concentrate on the bug first - whether a second IBPB - so to
speak - is needed. Doing some git archeology points to:

  15d45071523d ("KVM/x86: Add IBPB support")

which - and I'm surprised - goes to great lengths to explain what
those IBPB calls in KVM protect against. From that commit message, for
example:

"    * Mitigate attacks from guest/ring3->host/ring3.
      These would require a IBPB during context switch in host, or after
      VMEXIT."

so with my very limited virt understanding, when you vmexit, you don't
do switch_mm(), right?

If so, you need to do a barrier. Regardless of conditional IBPB or not
as you want to protect the host from a malicious guest.

In general, the whole mitigation strategies are enumerated in

Documentation/admin-guide/hw-vuln/spectre.rst

There's also a "3. VM mitigation" section.

And so on...

Bottomline is this: at the time, we went to great lengths to document
what the attacks are and how we are protecting against them.

So now, if you want to change all that, I'd like to see

- the attack scenario is this

- we don't think it is relevant because...

- therefore, we don't need to protect against it anymore

and all that should be properly documented.

Otherwise, there's no surviving this mess.

Thx!

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette