Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp225993iob; Mon, 2 May 2022 17:47:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw10//XhrCgAjInIuJ7qsH6WIyBwE23IO/ZXgbhskmeKP1tcGWQWkASWJRtxeVmxk9TnSfL X-Received: by 2002:a17:902:b694:b0:153:1d9a:11a5 with SMTP id c20-20020a170902b69400b001531d9a11a5mr13966695pls.151.1651538855617; Mon, 02 May 2022 17:47:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651538855; cv=none; d=google.com; s=arc-20160816; b=v+70WTOYSMyNkjJo6KxGkwsXwvORbv9pAryQUdbZWyb5vtvj0CgzTnAaYZQsgCDhqX hue22kAIK9P+mPq03X5jmPepBYpY0yYgTRNpV2dhs43lvedqw9KyZbCYZYhU7rBI29DU ciam1U+12ISPYagNO+/bFdVicFKou/W1vt7uadjVQr2gwCuZzenKpONWM5ypt/yqt1GG FqK0YhlmCBAmsjqulVBtMrXhEIDegdhy9SJJ5f2jMLArab0w/km12Z7mpjVa7d2My+YK 4NlYb5GPYWH8K78m3Jni+Y7J2cYnFxx+7LurUUaFooKi8wmj8AKzqpW0hM2MyoUOtfb/ XAXw== 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=I4U8glVnuq6Udv8BBw4C461Q7LSCRVtHUAvx084Xn4E=; b=JzadkfLaNOA4Cja7oKKWEMWh+bzMlK0LPjp6YcY3xnEazb8wGevOoJchtrRKWtfg4a amVLXktA0aSHKFlmv7Du+UYQhXAiypDatcxLMjuXsbqlC20MOLtQ+A7Z5CPZWck6yIU4 nkxEcCvpfos8aQhRELNUUfq7CJ0t8NGU2XmfrnfWjeBSmqCxzodWbjR/n/FnNioCmWAJ Pajag+533vO3qnbsqbghukLPWgOAw6gmzDd9g2AtCPSOjSf2mTuATeoqYzKSiL7bgeDN XSPdy3zWRTvp79wwbNohkdFvXHDEHR3t3PJFYldzJl+LRde38TEIgo01AppNgbhEec3S mnlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="N/Gn0YPj"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id j12-20020a17090a7e8c00b001d2d69d3f46si592548pjl.151.2022.05.02.17.47.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 17:47:35 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="N/Gn0YPj"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0D6734C784; Mon, 2 May 2022 17:36:19 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357512AbiD2WZu (ORCPT + 99 others); Fri, 29 Apr 2022 18:25:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239749AbiD2WZr (ORCPT ); Fri, 29 Apr 2022 18:25:47 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8B8BDC9B9; Fri, 29 Apr 2022 15:22:28 -0700 (PDT) Received: from zn.tnic (p5de8eeb4.dip0.t-ipconnect.de [93.232.238.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id DE3C11EC050F; Sat, 30 Apr 2022 00:22:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1651270943; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I4U8glVnuq6Udv8BBw4C461Q7LSCRVtHUAvx084Xn4E=; b=N/Gn0YPjt0yops3V1ZK6EXBLZDGlHVVpH3hnjqubvDWNhrdln4Y6d6fhyXPtbCVCilEp4g REKBUYhDYMOOfNf5ltdfSAHSmAwLyNbG/i9JyqOqELTJpn4zt0vnrHrI43AhD3ixHqxLm8 X7pDC+UiwUvzwgm3Ri+Pd8twL2I9Ij4= Date: Sat, 30 Apr 2022 00:22:20 +0200 From: Borislav Petkov To: Sean Christopherson 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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE 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 at 09:59:52PM +0000, Sean Christopherson wrote: > Correct, but KVM also doesn't do IBPB on VM-Exit (or VM-Entry), Why doesn't it do that? Not needed? > nor does KVM do IBPB before exiting to userspace. Same question. > The IBPB we want to whack is issued only when KVM is switching vCPUs. Then please document it properly as I've already requested. > Except that _none_ of that documentation explains why the hell KVM > does IBPB when switching betwen vCPUs. Probably because the folks involved in those patches weren't the hell mainly virt people. Although I see a bunch of virt people on CC on that patch. > : But stepping back, why does KVM do its own IBPB in the first place?  The goal is > : to prevent one vCPU from attacking the next vCPU run on the same pCPU.  But unless > : userspace is running multiple VMs in the same process/mm_struct, switching vCPUs, > : i.e. switching tasks, will also switch mm_structs and thus do IPBP via cond_mitigation. > : > : If userspace runs multiple VMs in the same process, This keeps popping up. Who does that? Can I get a real-life example to such VM-based containers or what the hell that is, pls? > enables cond_ipbp, _and_ sets > : TIF_SPEC_IB, then it's being stupid and isn't getting full protection in any case, > : e.g. if userspace is handling an exit-to-userspace condition for two vCPUs from > : different VMs, then the kernel could switch between those two vCPUs' tasks without > : bouncing through KVM and thus without doing KVM's IBPB. > : > : I can kinda see doing this for always_ibpb, e.g. if userspace is unaware of spectre > : and is naively running multiple VMs in the same process. So this needs a clearer definition: what protection are we even talking about when the address spaces of processes are shared? My naïve thinking would be: none. They're sharing address space - branch pred. poisoning between the two is the least of their worries. So to cut to the chase: it sounds to me like you don't want to do IBPB at all on vCPU switch. And the process switch case is taken care of by switch_mm(). -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette