Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp790477img; Thu, 28 Feb 2019 07:56:35 -0800 (PST) X-Google-Smtp-Source: AHgI3Ib6OD7BeeucaCNTLylOYwZprA+LYAJxupcxZfNDa0WOE+y7BAKv8UYOt7GIsl8TKYQJ8Uwv X-Received: by 2002:a63:5813:: with SMTP id m19mr9140633pgb.294.1551369395635; Thu, 28 Feb 2019 07:56:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551369395; cv=none; d=google.com; s=arc-20160816; b=BfYYjIB8BsaSVa43psitUWdzzz6/Q+fbCqtXGVL/OEuulcvT8Lxk8L/b3xOIIIsoIe MAOuPUd2n3no2t1JlFw6/Invt78TlKly2Tn7o9rjxSN+ZmA/gXUllOCCOgl3kYnFNxcS GTCAmni4yXJ5W3ZiDe0n7AveMWAGwqjhOSPzNP6QbjZdCaOXnCGtdmZX3zE/DMTJvWFa ZWdUmBYnnOHjloNdmO7dBuk2fy0+u1IN4Y+poblF5ukyrgCTGKNI915R9jBliRcDgvxY YYoVxGl0/CA+vn8SmAHbccl/NBGScm92AI7n6tjeilOMN5X/xycKHOckgo0hbmhiZnzC 0iJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=55OoEe+NLAw2XQtwbIDq4CgncZz/MoKaD4AooZvOUyc=; b=vwsQDXqk94QSxI3XtliXKZxYDyM3NR7NNw/UK9dxRN/G09p5eWVawesojM1G+xFOjW pG4iKG1BLC3HuPlbTN3m2eT7otv/ye9sjQ7mBydtE+JDt3L3Yu+kzSy0PfoA7c3dVMgV CL2IzSHUSxOOmZDnxSpw+vyZ7PfOjk6ptdzmzmofkBJ7gvDhs/zeEa+1MZf13WHwQibV 9xlChKzfOS833l4dx+u+MUWzbz+1KXcERhu3/mh4ivYuwBWDTS/wuY4IPjlymDE57fnR h8mA6HVS6CdqmxzC3rxeNihGvPPF5k9OmPPBz9ns3GF9leNH5Zn5J9J4oSpG4bbsBUwt XPEg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z192si17501645pgd.500.2019.02.28.07.56.16; Thu, 28 Feb 2019 07:56:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387447AbfB1Pxs (ORCPT + 99 others); Thu, 28 Feb 2019 10:53:48 -0500 Received: from mga07.intel.com ([134.134.136.100]:52021 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730843AbfB1Pxr (ORCPT ); Thu, 28 Feb 2019 10:53:47 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 07:53:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,423,1544515200"; d="scan'208";a="137026203" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.181]) by FMSMGA003.fm.intel.com with ESMTP; 28 Feb 2019 07:53:45 -0800 Date: Thu, 28 Feb 2019 07:53:45 -0800 From: Sean Christopherson To: Jim Mattson Cc: Yang Weijiang , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , LKML , kvm list , "Michael S. Tsirkin" , yu-cheng.yu@intel.com, Zhang Yi Z Subject: Re: [PATCH v3 1/8] KVM:VMX: Define CET VMCS fields and bits Message-ID: <20190228155345.GC6166@linux.intel.com> References: <20190225132716.6982-1-weijiang.yang@intel.com> <20190225132716.6982-2-weijiang.yang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 26, 2019 at 11:31:11AM -0800, Jim Mattson wrote: > On Mon, Feb 25, 2019 at 10:32 PM Yang Weijiang wrote: > > > > CET - Control-flow Enforcement Technology, it's used to > > protect against return/jump oriented programming (ROP) > > attacks. It provides the following capabilities to defend > > against ROP/JOP style control-flow subversion attacks: > > - Shadow Stack (SHSTK): > > A second stack for the program that is > > used exclusively for control transfer > > operations. > > - Indirect Branch Tracking (IBT): > > Free branch protection to defend against > > Jump/Call Oriented Programming. > > > > On processors that support CET, VMX saves/restores > > the states of IA32_S_CET, SSP and IA32_INTR_SSP_TABL_ADDR MSR > > to the VMCS area for Guest/Host unconditionally. > > > > If VM_EXIT_LOAD_HOST_CET_STATE = 1, the host CET MSRs are > > restored from VMCS host-state area at VM exit as follows: > > > > - HOST_IA32_S_CET: Host supervisor mode IA32_S_CET MSR is loaded > > from this field. > > > > - HOST_SSP : Host SSP is loaded from this field. > > > > - HOST_INTR_SSP_TABL_ADDR : Host IA32_INTR_SSP_TABL_ADDR > > MSR is loaded from this field. > > > > If VM_ENTRY_LOAD_GUEST_CET_STATE = 1, the guest CET MSRs are loaded > > from VMCS guest-state area at VM entry as follows: > > > > - GUEST_IA32_S_CET : Guest supervisor mode IA32_S_CET MSR is loaded > > from this field. > > > > - GUEST_SSP : Guest SSP is loaded from this field. > > > > - GUEST_INTR_SSP_TABL_ADDR : Guest IA32_INTR_SSP_TABL_ADDR > > MSR is loaded from this field. > > > > Additionally, to context switch guest and host CET states, the VMM > > uses xsaves/xrstors instructions to save/restore the guest CET states > > at VM exit/entry. The CET xsave area is within thread_struct.fpu area. > > If OS execution flow changes during task switch/interrupt/exception etc., > > the OS also relies on xsaves/xrstors to switch CET states accordingly. > > > > Signed-off-by: Zhang Yi Z > > Signed-off-by: Yang Weijiang > > --- > > arch/x86/include/asm/vmx.h | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h > > index ade0f153947d..395c1f7e5938 100644 > > --- a/arch/x86/include/asm/vmx.h > > +++ b/arch/x86/include/asm/vmx.h > > @@ -98,6 +98,7 @@ > > #define VM_EXIT_LOAD_IA32_EFER 0x00200000 > > #define VM_EXIT_SAVE_VMX_PREEMPTION_TIMER 0x00400000 > > #define VM_EXIT_CLEAR_BNDCFGS 0x00800000 > > +#define VM_EXIT_LOAD_HOST_CET_STATE 0x10000000 > > > > #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff > > > > @@ -109,6 +110,7 @@ > > #define VM_ENTRY_LOAD_IA32_PAT 0x00004000 > > #define VM_ENTRY_LOAD_IA32_EFER 0x00008000 > > #define VM_ENTRY_LOAD_BNDCFGS 0x00010000 > > +#define VM_ENTRY_LOAD_GUEST_CET_STATE 0x00100000 > > > > #define VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR 0x000011ff > > > > @@ -325,6 +327,9 @@ enum vmcs_field { > > GUEST_PENDING_DBG_EXCEPTIONS = 0x00006822, > > GUEST_SYSENTER_ESP = 0x00006824, > > GUEST_SYSENTER_EIP = 0x00006826, > > + GUEST_IA32_S_CET = 0x00006828, > > + GUEST_SSP = 0x0000682a, > > + GUEST_INTR_SSP_TABL_ADDR = 0x0000682c, > > Nit: TABL is an unusual abbreviation. Perhaps TBL here and below? I don't see any reason to abbreviate TABLE, we don't need the two characters for anything. > And why did you drop the 'IA32' here, but not in GUEST_IA32_S_CET above? > (It is true that there seems to be no rhyme or reason to the mnemonics > chosen here. For example, EFER keeps its IA32, but SYSENTER_EIP > doesn't. Sigh.) My vote is to always drop IA32, IMO it's redundant.