Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp185239iob; Mon, 2 May 2022 16:34:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3jgIHLDpaZ7VSaZA0BeOPqknBMOgikoce49/iKQVK8Cl08cYgXCnVALHIoDKV+x03OyXJ X-Received: by 2002:a17:902:e012:b0:15d:53:61ff with SMTP id o18-20020a170902e01200b0015d005361ffmr13955803plo.73.1651534494529; Mon, 02 May 2022 16:34:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651534494; cv=none; d=google.com; s=arc-20160816; b=QPDr8GgZIYkTlFcVF5/5qaGhYoDH9aMRh3tXguIqfuKAv+RCqr+mvth00Q1/6WLoCZ 9JcuflrrX5K5q552xJ4XuOtZNSWpK+FYjInrUZEeUxaDf4Jx58/6hLWlVPpx4xrOp6yN psYuwLX1z1RCpyNvByYCYywChFRaqOUWoQfGnX57tpZnGFO5hozzMnTOYbpkGl3rWaFm KZZfdoKaYcTbcMMA90AP0l90dWLaT+HAEtPqJFU2l+Q7eIikej9BM3auBaPwQJbPAxw7 5tKvUSjzI07mGWYhgUTWJhSovCNcmO/nfHaQDCPkM4PyxmxpSdCuXeXKLJPM/1qVqhZz XGSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=WbX1fT1P8676LYFVWwwEMd2ZHtmSK7UfBZ60pY9/zR8=; b=jjqw02Nptb15lcnpzoYbJdL+yUEws4M0b3qiLhdXMPFTj/0oYxdNLUiiW3ZwH11ZRP IoqtRhs3ueI7Vaz0Zzv0M9SUN7V6JwcHMJpD9giW82/3lvHu+PyWDQeOUYj9oBIERNBs CNYMi2yTgK4j8luxNghFXlQscBxumZY8WkAhhTglLT29kjnMyNXxQKH0ezT8sNYPr6ao M1UN2BCcfzLHVid8Q6UShQSRYCQKVsZNI3r1cAcSJHIxs9NBQ7lZ7s2UpykTAWvmGZ7r Hz/VZ229LqhPAW8XYqfwrE2RVqM86ds7zGjK+gWqS9SIkgMaZPFySMtXuL0HoCF80Xqx xhGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=GlmreAAA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id j9-20020a170903024900b00156fceb78f1si16665873plh.318.2022.05.02.16.34.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 16:34:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=GlmreAAA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4A4F912AB9; Mon, 2 May 2022 16:34:47 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377597AbiD2UdE (ORCPT + 99 others); Fri, 29 Apr 2022 16:33:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1380840AbiD2Uc4 (ORCPT ); Fri, 29 Apr 2022 16:32:56 -0400 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 512E5D76C8 for ; Fri, 29 Apr 2022 13:29:35 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id b12so8098874plg.4 for ; Fri, 29 Apr 2022 13:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=WbX1fT1P8676LYFVWwwEMd2ZHtmSK7UfBZ60pY9/zR8=; b=GlmreAAAsU5cuVMz+TYYpnjCf8pfVWI9KZiaEKN7VrQ8rb9z9E8423HiuTnF/cMtpv 9hLaFaS+ZRjx9e/r8AW9M8iRNETHD3+mwfBGc4fgKhDtdAUuMdT9FetdA7Sx9LYMmzJ5 zrCy+KxtXIE4eaf48AJKDkjaRhI0ySANhDl6yfagfYCybcL1WDrdGLYIsDXf0LaNHvF6 m3UppbmTSVQSOSB+MhGCQtTdGA0uzbdNwXVtUfvgIX3rakktgqFOPH3rE415JsvwMDAc H+ZsFr5fEWHXEZ69hNXKsiCItPf+IcHdHyAYFH8hZCG4V31nT/oE+kbiYcBRstU0XO9a 6rRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=WbX1fT1P8676LYFVWwwEMd2ZHtmSK7UfBZ60pY9/zR8=; b=OyB5nTLmgsgclBw040vh1cNs7P/n3qsEPGwCNv5/UPZxaBd+Otv6RSLSjL9OeHSk/e Yv6AEw40ZT0Gz8yZPcNVCG/qGFkWp8T+QlsxNfr/8HNU/4aN5orYavb70/NGr77AArpN BBzNMYLi0QnoQQmlPnCYFs/SiWllZZ7I/JKEeBFdrI7DbQieFefV0IW4Q9BI345BEgdj VmGjX31XfEheVmL1V1XpAQd7fPUnxTTiU1rYR+vwzkBQFFK8mQoh0ysmjuOR7tj6Untt iLETSmKY/URT6GU9Ju/PWmdBgPXg+KAczvgfSknG7wh90pW7xukM9XTWkd5ZnU/Md0jU PZ7A== X-Gm-Message-State: AOAM5328d2Cv3AOO86hjk+oMmmTkQ+aEWbyd/N9gJ3zfxM1RdKpJ8ebr qiakRnM4rffbUDaMZtI4Irre/g== X-Received: by 2002:a17:902:b208:b0:14f:14e8:1e49 with SMTP id t8-20020a170902b20800b0014f14e81e49mr824906plr.35.1651264174676; Fri, 29 Apr 2022 13:29:34 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id h10-20020a170902f70a00b0015e8d4eb287sm16870plo.209.2022.04.29.13.29.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Apr 2022 13:29:34 -0700 (PDT) Date: Fri, 29 Apr 2022 20:29:30 +0000 From: Sean Christopherson To: Borislav Petkov Cc: Jon Kohler , Thomas Gleixner , Ingo Molnar , Dave Hansen , "x86@kernel.org" , "H. Peter Anvin" , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Josh Poimboeuf , Peter Zijlstra , Balbir Singh , Kim Phillips , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , Andrea Arcangeli , Kees Cook , Waiman Long Subject: Re: [PATCH v3] x86/speculation, KVM: only IBPB for switch_mm_always_ibpb on vCPU load Message-ID: References: <20220422162103.32736-1-jon@nutanix.com> <645E4ED5-F6EE-4F8F-A990-81F19ED82BFA@nutanix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no 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 Fri, Apr 29, 2022, Borislav Petkov wrote: > On Fri, Apr 29, 2022 at 05:31:16PM +0000, Jon Kohler wrote: > > Selftests IIUC, but there may be other VMMs that do funny stuff. Said > > another way, I don’t think we actively restrict user space from doing > > this as far as I know. > > "selftests", "there may be"?! > > This doesn't sound like a real-life use case to me and we don't do > changes just because. Sorry. > > > The paranoid aspect here is KVM is issuing an *additional* IBPB on > > top of what already happens in switch_mm(). > > Yeah, I know how that works. > > > IMHO KVM side IBPB for most use cases isn’t really necessarily but > > the general concept is that you want to protect vCPU from guest A > > from guest B, so you issue a prediction barrier on vCPU switch. > > > > *however* that protection already happens in switch_mm(), because > > guest A and B are likely to use different mm_struct, so the only point > > of having this support in KVM seems to be to “kill it with fire” for > > paranoid users who might be doing some tomfoolery that would > > somehow bypass switch_mm() protection (such as somehow > > sharing a struct). > > Yeah, no, this all sounds like something highly hypothetical or there's > a use case of which you don't want to talk about publicly. What Jon is trying to do is eliminate IBPB that already exists in KVM. The catch is that, in theory, someone not-Jon could be running multiple VMs in a single address space, e.g. VM-based containers. So if we simply delete the IBPB, then we could theoretically and silently break a user. That's why there's a bunch of hand-waving. > Either way, from what I'm reading I'm not in the least convinced that > this is needed. Can you clarify what "this" is? Does "this" mean "this patch", or does it mean "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.