Received: by 2002:ac2:464d:0:0:0:0:0 with SMTP id s13csp3286919lfo; Mon, 23 May 2022 00:45:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyswXxVm9DIR4vqsP9nLO9/J4+6U5VbM3qnvgsQcjDMRCtXmZ5LT1gK5GBGbbhVxPs3q6GD X-Received: by 2002:a17:90b:1d8a:b0:1e0:31a9:e62d with SMTP id pf10-20020a17090b1d8a00b001e031a9e62dmr8490080pjb.209.1653291909409; Mon, 23 May 2022 00:45:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653291909; cv=none; d=google.com; s=arc-20160816; b=LjG6p2FInKEipPqIW53ijV0oYrLXGai7Y/dE7LzW+/Q8Fvz53R47fcr9XHojtS6lGy ZWVFJWgo3sgpXscM2Lzi2gFfPSfLjyXuj/AU0/baEDl8y0kAUsIAs2kuW3Zru/G8d0pm 0aHdqwTiazJ16UBG7i8njeCoDmdgOe40vQYspJ8t2hIbqG9bs8SH5baH/+Xg6Ogud/Pv PTmk2IpR4m06ZcNfV4FgTBRANO0fHeSlDURdVUE6IEd2toQyVvPFrZdaYAEqmzvzXBms aPg/05PZJULs5irqVpLWs5x9tQ2nChwEwkA4lIsSmPpOWIrp+tVByMhrilk5pzqYnbnU LKDQ== 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=iTfEbxhEPE+I25BZ4CZtl8Ad8yWflp0UHaW5WO5m8b4=; b=PHQ7+UpcYr49Posu9dfw/F0X+1nTAlsPe5ym/3tDBpMMX0zs5t7eLQN/fyo5wl9OQV KlgfVeUqXl6qrT4oyQ3FSU+mivXxWH20ElW9VZj2NRfniiGL5ijOjTjREvWZzZDlTuXs ubt6PY0sKryd7DjgqTRXlikLYbSqLvVfr5CYqA+9W73AY8N5D/MzjsIf2APPV61uCvX8 YGVwpnCbfdYgwXhwT2iQHIwAu50sVYa+l2v3d0tWZtKW+9/VOxqhV8B9DV2FtN+R+d1B 592xUtabD7QT3kVmg3ErLCIyduE4rPUeV3DtiilhonREJBfzL8Pp9i5mKJjaPlpRzugT FPNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=H0xt++lZ; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id f11-20020a63de0b000000b003c1977e2008si9093371pgg.821.2022.05.23.00.45.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 00:45:09 -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=@google.com header.s=20210112 header.b=H0xt++lZ; 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=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 534811FE1C2; Sun, 22 May 2022 23:52:06 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353466AbiETUaf (ORCPT + 99 others); Fri, 20 May 2022 16:30:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235837AbiETUad (ORCPT ); Fri, 20 May 2022 16:30:33 -0400 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA69417B879 for ; Fri, 20 May 2022 13:30:32 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id d22so8246057plr.9 for ; Fri, 20 May 2022 13:30:32 -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=iTfEbxhEPE+I25BZ4CZtl8Ad8yWflp0UHaW5WO5m8b4=; b=H0xt++lZPCBFEgu1tOl35h8wuLpVcLdkrjqaUjvsezsw8IAIsh+NlwHQUtyoMvqBwt Qz/0gCIcR8haYgdvwk3UbFZ2j08fgJNNCcPdMQClFxCS9s7ILTqUOjphICYgN1cfERaM cT68xElFHVAPvvCYdtgOrYKHB+phRPNWU9k8RXO8AQKoLHUz87hT2lV3PzX41tUIzxuC Hn/Jp1Qplf6b+uVzXRqtQxKLYSQB2gy0F0mL7bIu+YVGX4s1onV2gVrm5JNSgfV+xtes fEQjNttnzEm/aQ6vK+Kw5rnbcdFIhP6D2yOPxO6Hv6iLKivCaE/o+Jzt+NobVFezSY3K RG4A== 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=iTfEbxhEPE+I25BZ4CZtl8Ad8yWflp0UHaW5WO5m8b4=; b=RALzXeYbniUqRnPgkXrAnBmlrgqpAAT5WmdLVPzaj9um2TPbh/4Gw1sxgzQNPjkMTE ssNiz4cpUTjNO3vAFJflQRJrWo7/zD11TJso67hqt6/1aqdAD4wSZaZO+F3tYkK5LKCS KB1Q1C58319kZ5mtSUeL1Eqyrk52qkVvc7Eq8mV63YiogqK0Hci1wZBh6ubrZU0D+G0b S5U4fKZVhZPC31wuyRBGvW7RbdtTZTNFgbKTPWnG/Lhy91npb4ZDYt6mh+/H4qN3r6p5 gDXti4fQO2QfV0k3gKbVcFpL9mGO1t2Qkb1wgn3+sZlDF4Hceh7NghhOhnwR2tjpKybK w+FQ== X-Gm-Message-State: AOAM53332SwJjw6y3NMFD13KLWQJIhjpRfORjQRMUcHBItEZ8GJRuaq9 +gHmkpu5zfDcnBdrKF4Q7iGtkw== X-Received: by 2002:a17:902:f08d:b0:161:d786:8694 with SMTP id p13-20020a170902f08d00b00161d7868694mr10797410pla.77.1653078632042; Fri, 20 May 2022 13:30:32 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id i198-20020a6287cf000000b005180c127200sm2301111pfe.24.2022.05.20.13.30.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 May 2022 13:30:31 -0700 (PDT) Date: Fri, 20 May 2022 20:30:28 +0000 From: Sean Christopherson To: Jon Kohler Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "x86@kernel.org" , "H. Peter Anvin" , Andrea Arcangeli , Josh Poimboeuf , Kees Cook , Waiman Long , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] KVM: VMX: do not disable interception for MSR_IA32_SPEC_CTRL on eIBRS Message-ID: References: <20220512174427.3608-1-jon@nutanix.com> <29CDF294-5394-47C7-8B50-5F1FC101891C@nutanix.com> <732266F9-9904-434A-857F-847203901A0C@nutanix.com> <13E3F717-2938-430F-BA8B-70DD87962344@nutanix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <13E3F717-2938-430F-BA8B-70DD87962344@nutanix.com> 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, May 20, 2022, Jon Kohler wrote: > > > > On May 20, 2022, at 4:06 PM, Sean Christopherson wrote: > > > > On Fri, May 20, 2022, Jon Kohler wrote: > >> > >>> On May 18, 2022, at 10:23 AM, Jon Kohler wrote: > >>> > >>>> On May 17, 2022, at 9:42 PM, Sean Christopherson wrote: > >>>>> + if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED) && data == BIT(0)) { > >>>> > >>>> Use SPEC_CTRL_IBRS instead of open coding "BIT(0)", then a chunk of the comment > >>>> goes away. > >>>> > >>>>> + vmx->spec_ctrl = data; > >>>>> + break; > >>>>> + } > >>>> > >>>> There's no need for a separate if statement. And the boot_cpu_has() check can > >>>> be dropped, kvm_spec_ctrl_test_value() has already verified the bit is writable > >>>> (unless you're worried about bit 0 being used for something else?) > >> > >> I was (and am) worried about misbehaving guests on pre-eIBRS systems spamming IBRS > >> MSR, which we wouldn’t be able to see today. Intel’s guidance for eIBRS has long been > >> set it once and be done with it, so any eIBRS aware guest should behave nicely with that. > >> That limits the blast radius a bit here. > > > > Then check the guest capabilities, not the host flag. > > > > if (data == SPEC_CTRL_IBRS && > > (vcpu->arch.arch_capabilities & ARCH_CAP_IBRS_ALL)) > > So I originally did that in my first internal patch; however, the code you wrote is > effectively the code I wrote, because cpu_set_bug_bits() already does that exact > same thing when it sets up X86_FEATURE_IBRS_ENHANCED. > > Is the boot cpu check more expensive than checking the vCPU perhaps? Otherwise, > checking X86_FEATURE_IBRS_ENHANCED seemed like it might be easier > understand for future onlookers, as thats what the rest of the kernel keys off of > when checking for eIBRS (e.g. in bugs.c etc). Cost is irrelevant, checking X86_FEATURE_IBRS_ENHANCED is simply wrong. Just because eIBRS is supported in the host doesn't mean it's advertised to the guest, e.g. an older VM could have been created without eIBRS and then migrated to a host that does support eIBRS. Now you have a guest that thinks it needs to constantly toggle IBRS (I assume that's the pre-eIBRS behavior), but by looking at the _host_ value KVM would assume it's a one-time write and not disable interception.