From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 799A8C433F5 for ; Thu, 12 May 2022 19:35:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354762AbiELTfX (ORCPT ); Thu, 12 May 2022 15:35:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239853AbiELTfW (ORCPT ); Thu, 12 May 2022 15:35:22 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA6D82469EA for ; Thu, 12 May 2022 12:35:21 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id n10so6108834pjh.5 for ; Thu, 12 May 2022 12:35:21 -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:in-reply-to; bh=kfZN6PXN3cDIj6QUSkzpmoXvq4z3A1Hj8dUVdgbk/LI=; b=TDmXlRACyP52L1jGPGFOWL4byOhwal0rhKM+xO441dFXS3IuZdPlDV85V5K1j0yrPA odDZ67qDA2O6O3JFbd+WH0LQpcmMhogaJYT+wq/7HszRntXNVPXDeSk1gG08QzZRQRIW CHlDNPl4fMOaoqiWI8Phe4dM/4zcQY5u3Nc6eAWh3jfJg4zIRCPnUCYXUMs3QEhDX84q gu+blpAY5EDrIJRk0oKEA6r2HJYVePEmNySaN4Th6TkiPfm4w+kWRDX7DllWMSaIN2l8 6kGOMXnjEhn5ERdzY4qMgzI+UhM3IbSbengxwejfbRcVwb/k2PpeHOn5zgF1HWH89dza nEwg== 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:in-reply-to; bh=kfZN6PXN3cDIj6QUSkzpmoXvq4z3A1Hj8dUVdgbk/LI=; b=dBDE8uaH/IrFewnK3wclfrB0ZMdGQXM7ZHl2dTiPOjxzih89LhftXKKcfjhFlrjPMh y7+tetgOES2qt1jVGcgyDM/YUjwlu7/PpAyaE/oNG2446zqAeUzmhIX6Itz/E6qR574l 3YaHIioonCMQENbHWnmYrR3PBhWnauEC168vJqkuLI15AXkWoNLyvFnC/JECO3fkQpdN INb5S8XGHvnOR5GfDp9+45OStSJ0FSbqySezoB4hkL3TrMmhPWlBP0XMKiZo9cDsTza9 WcA1cMluYBILtLl/vuxiKnzdYCH1HO2VeVfXItQU+qkp7/J6GGNzzGUMWi+MT5mmgiRH EDNw== X-Gm-Message-State: AOAM531TCluacAdybfiMx7OWj2CqqY91raUlTUe3GNDPqAm6evisU0qX D+7NI/38+/LkG9OYunoAL4MbBw== X-Google-Smtp-Source: ABdhPJy3B0WgQXyYcsYlyM8zhsfQkOrQ9Ynae+lWMuPFoAySH0P8tBiO77yZ9vYieIinOyRTKKEsyA== X-Received: by 2002:a17:903:22cb:b0:15e:d715:1bd8 with SMTP id y11-20020a17090322cb00b0015ed7151bd8mr1319276plg.159.1652384121012; Thu, 12 May 2022 12:35:21 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id p187-20020a62d0c4000000b0050dc7628135sm226616pfg.15.2022.05.12.12.35.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 May 2022 12:35:20 -0700 (PDT) Date: Thu, 12 May 2022 19:35:16 +0000 From: Sean Christopherson To: Jon Kohler Cc: Jonathan Corbet , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "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, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Waiman Long Subject: Re: [PATCH v4] x86/speculation, KVM: remove IBPB on vCPU load Message-ID: References: <20220512184514.15742-1-jon@nutanix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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 simply > > wrong in its guest-to-guest design intention. There are three scenarios > > at play here: > > Jim pointed offline that there's a case we didn't consider. When switching 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 notification 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 documentation > most definitely needs to be updated. > > A per-VM capability to skip the IBPB may be warranted, e.g. for container-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_structs, because then the IBPB is fully redundant with respect to any IBPB performed 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 IBPB. That would also sidestep the largely theoretical question of whether vCPUs from different VMs but the same address space are in the same security domain. It doesn't matter, because even if they are in the same domain, KVM still needs to do IBPB.