Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp127145iob; Thu, 12 May 2022 20:36:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8QK5tQMkQ9lOtCoCnph1Ka8t5nthZ8D77zImCL66UXA3uBCy+PYSDBuUrXT4bPIeJzioz X-Received: by 2002:a17:902:da91:b0:15e:d22f:cfd7 with SMTP id j17-20020a170902da9100b0015ed22fcfd7mr2980155plx.85.1652412990532; Thu, 12 May 2022 20:36:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652412990; cv=none; d=google.com; s=arc-20160816; b=h9r/IoSCrFBrYB/YSOCsdsZhN3+4Lcl+b3BODG7S1nI7TPre2SC2yKHH9scbYstvua 3FihF6QppFIeSbGo+JSFPqRgWMLyLCicxQqh67mHZcTCL9AFVlsupk3kI7YSPLD+RPP9 u1UxHSXduZsea64K6hHogozgpezVGKjTNNZlg0JLa6D+qzgtHGmXHZOMps0dvhK1H6Yc TttnBcOBCEC+Z543ylyqcmOSz+PYNRICzIjdQaDX0rQOSZXbr46f2YhY+bDeoBvVqyQB V1ggoGh5FThngI5fmt1Iqo7H+/C7VnkTIeF6fHchvEw3Hy9YLm2uD5NIvYmzHxWiKjfr KqnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=297SZhnbfakt9y0BHFgnqzkCZLJUke1XogmQGvDK8R4=; b=dEYpV9JVJzrncE+Z3Qp3Y8BFe3igbmNrdjNwjNaK0eqD2rfVY/5HcZVrhAJkRhkI9y 3qJkBeE1eW7tWGZCKgiIA4iC9KFuydutzHMkx1AJ3zUED/HIQzcc7vYC4ZlhkbCuBiv6 Xyn+yruBkx50Y/xDN7BP9SKV1q/GUD3r4mcawXzAE4l1jkPjmS0OBUInhZXc+US8r/J7 oF8i6R9i/XC1kcq5zCZZqeYl2+pfI5VG9scbU9RcVYTIcltHy3UTNl41Q/QN1+U55szb o0ylEI2CLK9AnMYT9Vmv3QGOg/VIb+azSs1Lm0KFs7xRRe2kcHehBw2axEPjgasuHCa3 uR9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=m9HMjtn3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d7-20020a170902654700b0015d06426f70si1619878pln.249.2022.05.12.20.36.18; Thu, 12 May 2022 20:36:30 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=m9HMjtn3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376678AbiEMDHG (ORCPT + 99 others); Thu, 12 May 2022 23:07:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356735AbiEMDHD (ORCPT ); Thu, 12 May 2022 23:07:03 -0400 Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E9FE45AC7 for ; Thu, 12 May 2022 20:07:02 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id p12-20020a9d4e0c000000b00606b40860a3so4086878otf.11 for ; Thu, 12 May 2022 20:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=297SZhnbfakt9y0BHFgnqzkCZLJUke1XogmQGvDK8R4=; b=m9HMjtn3t15regA8x1GltDY08DyPBuI2H0RawHwVfEekwc56tea1CeNnXrDCzfMSsr T6LDfkOGVAxHlFZ5blEteba7l8cHTjFwQsUqaL6bexFl3C14r2qGMsjZsHwnYnSgSU/l YMC1c6z2iZHeQDptFxo+AJbSFYLWexKpQLb0QbGWGws60uTswZkLayRv4fx9VDHM4LoT jpWYlcF+Lkq6g3rCH49AYvRHONXLVW/9OnDDxHw0N461nY+PU4Bdzg+F+HJEETHXBI+V jpXhR7PTGYzYIxiM6kBPMM2W64m5Uh6TgfeVIPR8WRv0Rsk9kpCzIIgej+KltjAUZptZ N/kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=297SZhnbfakt9y0BHFgnqzkCZLJUke1XogmQGvDK8R4=; b=Xs9ZL/pcaPMkf12pVFkIgmGVB5CyW6Y6v/aI4jlqscsPTedPq4BOeO0xVFkYyiDyIe P91YvaQkVFDnNkYOTyHAoObA/+WwM9m6Aex2pU4WrCRpnyh1Kv3LRH6r4bD/lWqHxP3A wOx9DF+F0IziWSyxTVCCRlgv+04Vvb+jExbkyDx4TcPrnkTprLOKE0VESd26jRGq4NQf EixLMnzwTzRLeVouzSP8C/ROlNZia39GxF2XjTvKAnw8hfreOczuAYet5Zele/nXOlEL jR3DblgQO7Y33Qvp6LC/Ejg/uVgGhgN9TkCQg9gCqozzlTk8ZSC+FmXMLU6j4f2QGJi8 BKTg== X-Gm-Message-State: AOAM533hSKFw9oXBTqhBvISRy7PILL2aZ5tY9x3ChCt1CV6V8EWTjqpV lExiaLA3NTQoih96ECTTWth34EYx1y92m1KXlNKbCQ== X-Received: by 2002:a05:6830:280e:b0:606:ae45:6110 with SMTP id w14-20020a056830280e00b00606ae456110mr1143445otu.14.1652411221187; Thu, 12 May 2022 20:07:01 -0700 (PDT) MIME-Version: 1.0 References: <20220512184514.15742-1-jon@nutanix.com> <07BEC8B1-469C-4E36-AE92-90BFDF93B2C4@nutanix.com> In-Reply-To: From: Jim Mattson Date: Thu, 12 May 2022 20:06:49 -0700 Message-ID: Subject: Re: [PATCH v4] x86/speculation, KVM: remove IBPB on vCPU load To: Jon Kohler Cc: Sean Christopherson , Jonathan Corbet , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , "H. Peter Anvin" , Kees Cook , Andrea Arcangeli , Josh Poimboeuf , Kim Phillips , Lukas Bulwahn , Peter Zijlstra , Ashok Raj , KarimAllah Ahmed , David Woodhouse , "linux-doc@vger.kernel.org" , LKML , "kvm @ vger . kernel . org" , Waiman Long Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 12, 2022 at 5:50 PM Jon Kohler wrote: > You mentioned if someone was concerned about performance, are you > saying they also critically care about performance, such that they are > willing to *not* use IBPB at all, and instead just use taskset and hope > nothing ever gets scheduled on there, and then hope that the hypervisor > does the job for them? I am saying that IBPB is not the only viable mitigation for cross-process indirect branch steering. Proper scheduling can also solve the problem, without the overhead of IBPB. Say that you have two security domains: trusted and untrusted. If you have a two-socket system, and you always run trusted workloads on socket#0 and untrusted workloads on socket#1, IBPB is completely superfluous. However, if the hypervisor chooses to schedule a vCPU thread from virtual socket#0 after a vCPU thread from virtual socket#1 on the same logical processor, then it *must* execute an IBPB between those two vCPU threads. Otherwise, it has introduced a non-architectural vulnerability that the guest can't possibly be aware of. If you can't trust your OS to schedule tasks where you tell it to schedule them, can you really trust it to provide you with any kind of inter-process security? > Would this be the expectation of just KVM? Or all hypervisors on the > market? Any hypervisor that doesn't do this is broken, but that won't keep it off the market. :-)