linux-kernel - Re: [PATCH v3] x86/speculation, KVM: only IBPB for switch_mm_always

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Ym1fGZIs6K7T6h3n@zn.tnic>
Date:   Sat, 30 Apr 2022 18:08:57 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Jon Kohler <jon@...anix.com>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Balbir Singh <sblbir@...zon.com>,
        Kim Phillips <kim.phillips@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v3] x86/speculation, KVM: only IBPB for
 switch_mm_always_ibpb on vCPU load

On Sat, Apr 30, 2022 at 02:50:35PM +0000, Jon Kohler wrote:
> This is 100% a fair ask, I appreciate the diligence, as we’ve all been there
> on the ‘other side’ of changes to complex areas and spend hours digging on
> git history, LKML threads, SDM/APM, and other sources trying to derive
> why the heck something is the way it is.

Yap, that's basically proving my point and why I want stuff to be
properly documented so that the question "why was it done this way" can
always be answered satisfactorily.

> AFAIK, the KVM IBPB is avoided when switching in between vCPUs
> belonging to the same vmcs/vmcb (i.e. the same guest), e.g. you could 
> have one VM highly oversubscribed to the host and you wouldn’t see
> either the KVM IBPB or the switch_mm IBPB. All good. 
> 
> Reference vmx_vcpu_load_vmcs() and svm_vcpu_load() and the 
> conditionals prior to the barrier.

So this is where something's still missing.

> However, the pain ramps up when you have a bunch of separate guests,
> especially with a small amount of vCPUs per guest, so the switching is more
> likely to be in between completely separate guests.

If the guests are completely separate, then it should fall into the
switch_mm() case.

Unless it has something to do with, as I looked at the SVM side of
things, the VMCBs:

	if (sd->current_vmcb != svm->vmcb) {

So it is not only different guests but also within the same guest and
when the VMCB of the vCPU is not the current one.

But then if VMCB of the vCPU is not the current, per-CPU VMCB, then that
CPU ran another guest so in order for that other guest to attack the
current guest, then its branch pred should be flushed.

But I'm likely missing a virt aspect here so I'd let Sean explain what
the rules are...

Thx.

-- 
Regards/Gruss,
    Boris.

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