Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp1169576ioo; Fri, 27 May 2022 03:07:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwHwhlid1iJrXc9P+o4kPig7G163pi+VIPojkosUMHWklzztI/cBcMV0SI/JC2H0iuJBATD X-Received: by 2002:a17:902:ca91:b0:163:91e5:d38 with SMTP id v17-20020a170902ca9100b0016391e50d38mr2919611pld.166.1653646066802; Fri, 27 May 2022 03:07:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653646066; cv=none; d=google.com; s=arc-20160816; b=KfaZNNRzrusX3KUSxV3DPZVAc1nPNJVTk6zgCrIej6pdY7OYfkzSNBveFOAjMME9Zi HJjhdftVZOeCRk3BACF105Zb9r7R7xVs/Ro6qwFulYeKF4hmYVSPYB9ZhR17qT4r2JX+ ukbKxB+pd9JSDGzJQAURKIDdWPA9oYK4xTjGo61hrmz+AzDsQwGiWye5o1Zp7twnwVu8 J8qRSLUtoyLKmW6ot9rsRg61lV8uKDeOmQrbbPUuJWDLPp2Wg5FH6D5LlkWVGR56aER8 P7bbgPbmyNT63sAOh6Y2l0YR5hZNB/kcxX/8bdkINpiZtKVJWA5FndeIDv32DZaTng45 KyvQ== 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=Ps3rawoSWC/it4y6dQ5wsGYhp9yrFt3MHXORhqDfylw=; b=hwMSaYZSz7upVkhown6JURzHDI9TMSZqY3nv9kvXqyUcTJpfDzJ40DujgRBG16fi0/ Jw82j1MrEOt8IQIouUGn6s1Uo7da2R2GwiDy+w7JoZBSqmq5RLJzeaYoz3FtSIf+Wvca 9x1HVHDDgNWrArRz/WZqEBXoFYBsxUjnpivGoB5SLlJADOvLtUE+ks0obSgf4rS0NhtR Kl1+rXyWbNwhhDYeKPlnNrWi/dZ0kf2TgFJB9ACBhIBeJVYqfx3gcq2qszLMCy5ns2kX yaeBy82g/ksSMyZBNP6Lu5B8xbfXa+CR4v+S1M68cZIefVvFjHmU6KHpqN6oEdIVxPSL mR6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=J4QwXySm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p12-20020a170902e74c00b00158f817a27bsi5582732plf.148.2022.05.27.03.07.32; Fri, 27 May 2022 03:07:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=J4QwXySm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346366AbiEZVfK (ORCPT + 99 others); Thu, 26 May 2022 17:35:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349159AbiEZVfI (ORCPT ); Thu, 26 May 2022 17:35:08 -0400 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D0838A075 for ; Thu, 26 May 2022 14:35:07 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id q18so2489966pln.12 for ; Thu, 26 May 2022 14:35:07 -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=Ps3rawoSWC/it4y6dQ5wsGYhp9yrFt3MHXORhqDfylw=; b=J4QwXySm0FJ4pZkEFIwaOJRNdMEWqjoPUfIdvss0oDROz3t6t+POWBXXPL5ILLnR2k OTsgFcHq5NDEljf0vTX6r5vVzxGsq4qlw+QBasZOptplqkHHeDNWkx6MXBMKpTez2w1X BfTqzrSz/nV7Utt+cXazsHix/D1/PHLrH071OQdpZ37WFjk+aycNDMUSpK9sArxKDfaE 3gD/0UpCt2TolugIInhXmSPfF740c2mRxTd/8v/kqBSq2ZSGs15fgfmcB9NHE3jDdG2X uVmDDYvgYz1khX0V4+Jr7RjUBP2BR5fZLvMSrVXiavnyZyZbvubg8yh00+YzHhC0dnVM /ebQ== 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=Ps3rawoSWC/it4y6dQ5wsGYhp9yrFt3MHXORhqDfylw=; b=HVN7MVppEXuqIdvyRsdTbJMrHEVK4quPBE74konRoUP62zi0UFcv3dDDfC8KFPJZMQ guPPgRywnfctFWNrT9Huj2g7DaTATZZZTSgqjQ+4i8i1a7szGIi6MMuzR6aVDrReYXG5 MU6NaZ8UelMg/PmMqlJX+VPex8GYMlKGY6aDTuEdgPA0wA00F1EFMGFl2VbqlyDiOUsE CTm00LuLOEM7QD2EbPPrT/9WIUucjWabuo6DmYKSma3y0g3xK1oscYhzxGwfUvWnThcP Y9oaFWR0/eLBFT8RaRYEwSJV5lMcr8hxp5SV3TDBv66xXgg7VSQ0qKRnNNQjZwGrCCgV UarA== X-Gm-Message-State: AOAM530+p20M+ENPYt7wT7mx488EDhmpjZPZc7+4urMW3Ew+Kc6EmpWD 16WOpeK7XG09tTyHgOum9hD+Eya7v+3VOw== X-Received: by 2002:a17:902:c94c:b0:162:2b70:110f with SMTP id i12-20020a170902c94c00b001622b70110fmr20126687pla.127.1653600906757; Thu, 26 May 2022 14:35:06 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id p4-20020a170902eac400b001635dc81415sm2025134pld.289.2022.05.26.14.35.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 May 2022 14:35:06 -0700 (PDT) Date: Thu, 26 May 2022 21:35:02 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chenyi Qiang , Lei Wang Subject: Re: [PATCH 1/2] KVM: VMX: Sanitize VM-Entry/VM-Exit control pairs at kvm_intel load time Message-ID: References: <20220525210447.2758436-1-seanjc@google.com> <20220525210447.2758436-2-seanjc@google.com> <8baca98e-63d6-f7dd-067b-05f8e0dc381f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8baca98e-63d6-f7dd-067b-05f8e0dc381f@redhat.com> X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham 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 Thu, May 26, 2022, Paolo Bonzini wrote: > On 5/25/22 23:04, Sean Christopherson wrote: > > +#define VMCS_ENTRY_EXIT_PAIR(name, entry_action, exit_action) \ > > + { VM_ENTRY_##entry_action##_##name, VM_EXIT_##exit_action##_##name } > > + > > static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf, > > struct vmx_capability *vmx_cap) > > { > > @@ -2473,6 +2476,24 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf, > > u64 _cpu_based_3rd_exec_control = 0; > > u32 _vmexit_control = 0; > > u32 _vmentry_control = 0; > > + int i; > > + > > + /* > > + * LOAD/SAVE_DEBUG_CONTROLS are absent because both are mandatory. > > + * SAVE_IA32_PAT and SAVE_IA32_EFER are absent because KVM always > > + * intercepts writes to PAT and EFER, i.e. never enables those controls. > > + */ > > + struct { > > + u32 entry_control; > > + u32 exit_control; > > + } vmcs_entry_exit_pairs[] = { > > + VMCS_ENTRY_EXIT_PAIR(IA32_PERF_GLOBAL_CTRL, LOAD, LOAD), > > + VMCS_ENTRY_EXIT_PAIR(IA32_PAT, LOAD, LOAD), > > + VMCS_ENTRY_EXIT_PAIR(IA32_EFER, LOAD, LOAD), > > + VMCS_ENTRY_EXIT_PAIR(BNDCFGS, LOAD, CLEAR), > > + VMCS_ENTRY_EXIT_PAIR(IA32_RTIT_CTL, LOAD, CLEAR), > > + VMCS_ENTRY_EXIT_PAIR(IA32_LBR_CTL, LOAD, CLEAR), > > No macros please, it's just as clear to expand them especially since the > #define is far from the struct definition. It's not for clarity, it's to prevent plopping an EXIT control into the ENTRY slot and vice versa. I have a hell of a time trying to visually differentiate those, and a buggy pair isn't guaranteed to be detected at runtime, e.g. if both are swapped, all bets are off, and if one is duplicated, odds the warn may or may not show up unless hardware actually supports at least one of the controls, if not both. With this, swapping LOAD and LOAD is obviously a nop, and swapping LOAD and CLEAR will generate a compiler error. FWIW, I did originally have the array declared as static __initdata immediately after the #define. I moved away from that because __initdata doesn't play nice with const, but then of course I forgot to add back the "const". /facepalm