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;
MIME-Version: 1.0
References: <20220512184514.15742-1-jon@nutanix.com> <Yn1fjAqFoszWz500@google.com>
 <Yn1hdHgMVuni/GEx@google.com> <07BEC8B1-469C-4E36-AE92-90BFDF93B2C4@nutanix.com>
In-Reply-To: <07BEC8B1-469C-4E36-AE92-90BFDF93B2C4@nutanix.com>
From:   Jim Mattson <jmattson@google.com>
Date:   Thu, 12 May 2022 13:06:39 -0700
Message-ID: <CALMp9eQbP5DdX+SA0subeHmVxZgfQ7LEZ-Cxs3AFVHUpa6nhfg@mail.gmail.com>
Subject: Re: [PATCH v4] x86/speculation, KVM: remove IBPB on vCPU load
To:     Jon Kohler <jon@nutanix.com>
Cc:     Sean Christopherson <seanjc@google.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Joerg Roedel <joro@8bytes.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
        Kees Cook <keescook@chromium.org>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Kim Phillips <kim.phillips@amd.com>,
        Lukas Bulwahn <lukas.bulwahn@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ashok Raj <ashok.raj@intel.com>,
        KarimAllah Ahmed <karahmed@amazon.de>,
        David Woodhouse <dwmw@amazon.co.uk>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "kvm @ vger . kernel . org" <kvm@vger.kernel.org>,
        Waiman Long <longman@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, May 12, 2022 at 12:51 PM Jon Kohler <jon@nutanix.com> wrote:
>
>
>
> > On May 12, 2022, at 3:35 PM, Sean Christopherson <seanjc@google.com> wr=
ote:
> >
> > On Thu, May 12, 2022, Sean Christopherson wrote:
> >> On Thu, May 12, 2022, Jon Kohler wrote:
> >>> Remove IBPB that is done on KVM vCPU load, as the guest-to-guest
> >>> attack surface is already covered by switch_mm_irqs_off() ->
> >>> cond_mitigation().
> >>>
> >>> The original commit 15d45071523d ("KVM/x86: Add IBPB support") was si=
mply
> >>> wrong in its guest-to-guest design intention. There are three scenari=
os
> >>> at play here:
> >>
> >> Jim pointed offline that there's a case we didn't consider.  When swit=
ching between
> >> vCPUs in the same VM, an IBPB may be warranted as the tasks in the VM =
may be in
> >> different security domains.  E.g. the guest will not get a notificatio=
n that vCPU0 is
> >> being swapped out for vCPU1 on a single pCPU.
> >>
> >> So, sadly, after all that, I think the IBPB needs to stay.  But the do=
cumentation
> >> most definitely needs to be updated.
> >>
> >> A per-VM capability to skip the IBPB may be warranted, e.g. for contai=
ner-like
> >> use cases where a single VM is running a single workload.
> >
> > Ah, actually, the IBPB can be skipped if the vCPUs have different mm_st=
ructs,
> > because then the IBPB is fully redundant with respect to any IBPB perfo=
rmed by
> > switch_mm_irqs_off().  Hrm, though it might need a KVM or per-VM knob, =
e.g. just
> > because the VMM doesn't want IBPB doesn't mean the guest doesn't want I=
BPB.
> >
> > That would also sidestep the largely theoretical question of whether vC=
PUs from
> > different VMs but the same address space are in the same security domai=
n.  It doesn't
> > matter, because even if they are in the same domain, KVM still needs to=
 do IBPB.
>
> So should we go back to the earlier approach where we have it be only
> IBPB on always_ibpb? Or what?
>
> At minimum, we need to fix the unilateral-ness of all of this :) since we=
=E2=80=99re
> IBPB=E2=80=99ing even when the user did not explicitly tell us to.
>
> That said, since I just re-read the documentation today, it does specific=
ally
> suggest that if the guest wants to protect *itself* it should turn on IBP=
B or
> STIBP (or other mitigations galore), so I think we end up having to think
> about what our =E2=80=9Ccontract=E2=80=9D is with users who host their wo=
rkloads on
> KVM - are they expecting us to protect them in any/all cases?
>
> Said another way, the internal guest areas of concern aren=E2=80=99t some=
thing
> the kernel would always be able to A) identify far in advance and B)
> always solve on the users behalf. There is an argument to be made
> that the guest needs to deal with its own house, yea?

To the extent that the guest has control over its own house, yes.

Say the guest obviates the need for internal IBPB by statically
partitioning virtual cores into different security domains. If the
hypervisor breaks core isolation on the physical platform, it is
responsible for providing the necessary mitigations.