Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp231719iob; Mon, 2 May 2022 17:58:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEnI8PNQ2M/3HoQdSga1phjk2N23cxpx4fyejth6ud2x4UmVZogdGo9gUI5Qt71F1UMFSu X-Received: by 2002:a17:90b:1c10:b0:1d2:a7c4:3cf with SMTP id oc16-20020a17090b1c1000b001d2a7c403cfmr2060298pjb.100.1651539513251; Mon, 02 May 2022 17:58:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651539513; cv=none; d=google.com; s=arc-20160816; b=c38tplieqEKQRTzvJvKatH7Qqph97q8MPf5yUDz8PAQscyoGdE9/QA8fpbB1vv+z8W xWeew7s9VaK1r1hycRzr8bF4qYZNzGCxraIVYMxA3hHNdjToRIbFg4G34GbsWaKhdbmh oPqqNry/xpXhAEU39SzdeL0W9K0q5TKsXvH4zKmvtiji0B3uGlGhH0Z/8NHT9rC0ZT5p lF4LNKvVGKQOg3/q9WQhUSLt0FqVBzMvtu//VGGiV9Hr8stNQL/0ptuB/CY6D/767eaR B+O6GaPI/ZVNNSRe3U4Mo++/PlqzT5NY7jhygkJdQDBXoc2GAFo6/4UujdJT26GZ1Ad3 ARYA== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ryz6qe26SSjFGkG1Tf8msJ+uFH2uRt70jwrl4EWJsSQ=; b=w9EOQ1vxekcQRzAa+R3j+92xfM9/1vqHISHjWXL8pyUWemQ52P9KLLvLixosmHmvv+ wqI7Pgl81Wx78gmXJ2v8sAGdz9qR//Gq9BTXnUQQVKgxJaJcWEeFILf0WAVHu8pWjecN sRih/Mz6GsMyREHI58x1/S2pwzZ1D+TsBQxydByRR7DhOs8vADG/GTt1+UWLTuctlDzC inCSF9m/p6UZ8HggpEwZ3ko5RWcGeFOyP7gZfX+6opoydBmjnTqnL45fIlnY/GWD57pR jAgbo4ncHFvmcQXWfsdt7HsNeb05yDkdQoIaIwYj0yg00bcYlbdFpQ9pp7yBOPekapyA XrUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="p6pYff/Q"; 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=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id nl1-20020a17090b384100b001d297b4e1afsi830460pjb.185.2022.05.02.17.58.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 17:58:33 -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=@alien8.de header.s=dkim header.b="p6pYff/Q"; 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=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 3708642A06; Mon, 2 May 2022 17:44:07 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379361AbiD2RCn (ORCPT + 99 others); Fri, 29 Apr 2022 13:02:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233453AbiD2RCk (ORCPT ); Fri, 29 Apr 2022 13:02:40 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BFA4AF1F8; Fri, 29 Apr 2022 09:59:21 -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 A0AEB1EC04AD; Fri, 29 Apr 2022 18:59:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1651251555; 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:in-reply-to:in-reply-to: references:references; bh=ryz6qe26SSjFGkG1Tf8msJ+uFH2uRt70jwrl4EWJsSQ=; b=p6pYff/QEvvu2vvG6CwN73BewKdNeL9a+iRQLsZjnLDrG9MSlayGHsCZdZn6tKts7qdW/U SzsAIeO77jM9tcI0SUyUL9g/q8CPwxRP1P3RbyiZM/uBphYykzRL20V471BXxBtEDE+wTR exBW9prOi1AaKwlkIf02zMp6q4T3660= Date: Fri, 29 Apr 2022 18:59:12 +0200 From: Borislav Petkov To: Jon Kohler Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Paolo Bonzini , Sean Christopherson , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220422162103.32736-1-jon@nutanix.com> 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 22, 2022 at 12:21:01PM -0400, Jon Kohler wrote: > Both switch_mm_always_ibpb and switch_mm_cond_ibpb are handled by > switch_mm() -> cond_mitigation(), which works well in cases where > switching vCPUs (i.e. switching tasks) also switches mm_struct; > however, this misses a paranoid case where user space may be running > multiple guests in a single process (i.e. single mm_struct). You lost me here. I admit I'm no virt guy so you'll have to explain in more detail what use case that is that you want to support. What guests share mm_struct? What is the paranoid aspect here? You want to protect a single guest from all the others sharing a mm_struct? > +/* > + * Issue IBPB when switching guest vCPUs IFF switch_mm_always_ibpb. > + * For the more common case of running VMs in their own dedicated process, > + * switching vCPUs that belong to different VMs, i.e. switching tasks, > + * will also switch mm_structs and thus do IPBP via cond_mitigation(); > + * however, in the always_ibpb case, take a paranoid approach and issue > + * IBPB on both switch_mm() and vCPU switch. > + */ > +static inline void x86_virt_guest_switch_ibpb(void) > +{ > + if (static_branch_unlikely(&switch_mm_always_ibpb)) > + indirect_branch_prediction_barrier(); If this switch is going to be conditional, then make it so: static void x86_do_cond_ibpb(void) { if (static_branch_likely(&switch_mm_cond_ibpb)) indirect_branch_prediction_barrier(); } and there's nothing "virt" about it - might as well call the function what it does. And I'd put that function in bugs.c... > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > index 6296e1ebed1d..6aafb0279cbc 100644 > --- a/arch/x86/kernel/cpu/bugs.c > +++ b/arch/x86/kernel/cpu/bugs.c > @@ -68,8 +68,12 @@ u64 __ro_after_init x86_amd_ls_cfg_ssbd_mask; > DEFINE_STATIC_KEY_FALSE(switch_to_cond_stibp); > /* Control conditional IBPB in switch_mm() */ > DEFINE_STATIC_KEY_FALSE(switch_mm_cond_ibpb); > -/* Control unconditional IBPB in switch_mm() */ > +/* Control unconditional IBPB in both switch_mm() and > + * x86_virt_guest_switch_ibpb(). > + * See notes on x86_virt_guest_switch_ibpb() for KVM use case details. > + */ > DEFINE_STATIC_KEY_FALSE(switch_mm_always_ibpb); > +EXPORT_SYMBOL_GPL(switch_mm_always_ibpb); ... so that I don't export that key to modules. I'd like to have the big picture clarified first, why we need this, etc. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette