Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp6505096rwd; Mon, 5 Jun 2023 20:13:59 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6i3LXbmj6iyJVJqma2CxyNs5ykvgXlnUZ6waIk71de2XsfhgNeYp29+ZfKxtpzqTmfE+G5 X-Received: by 2002:a05:6e02:5c9:b0:33c:9631:3eaa with SMTP id l9-20020a056e0205c900b0033c96313eaamr1419695ils.2.1686021239127; Mon, 05 Jun 2023 20:13:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686021239; cv=none; d=google.com; s=arc-20160816; b=zwJsaWIPo0aeKW0N6Jh2/LQOdlTdSWBh3O+1lBuwFUCuprAnHkWsi4Pafny6/fSC8x y516/QKJYEl/uEQLBNw+1hjlSFA5TBWwG2GMZZI98eYbIoc9lP89YEHzPXJFa/ntYshT VZSXHL6524BUgzju4yWwenveZcu/mL+59wlo0jojuxpOvGfQDY442WKLyz8Blivqfaev 7W0d/6T0vprJgCT5s+gTxeuVmirDb+UrtQT0sFKBu6ELIWmS34wpvTDaLHJ0qX71i4/O 1fsA1tkMpDqfFs2HfiFTnrkym+CTdrMLosrCMoL8Z5WDt6DuoGMNxS9BuT8b+B/z2vkk 8Ciw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id :dkim-signature; bh=3xEEgBj9wPCJjZpnx8JQJbDcJlHFMc4XBdj3UTfBcuk=; b=LT3Yj7IW9u8kG7oxRZwjCxKObmNiWoQfp7ubV3ygL6JJ9qFOkUKy6HlM79bNjWG77q 1TuRLf8/QiFb7Lpk3AfVi31E6Q0wjbjvhT/S5yFgUCEgrUVhYlCrV/zTDidQ9ELKTzJB ojM//uM4Yd9N+8gFXl5ACive4WFcu5DBuG5iJKkVy3jGzcdFIjqOLbX/jBL8ZNDSiqIZ RnbuM+UQHH0L/rLLvIce+vw/LYIq3+zP4dmVMX3MfKNl92rA8d5KIpJCGW2eI6C1u+Lw X1VQkiGp99IAGmzxERnId+PSPGpWk3kMfCmmffixfyykiy1nuetX2KViliYikTHYKUlg iHXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=NjCLVRkz; 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=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m28-20020a637d5c000000b005406e76606csi6461636pgn.900.2023.06.05.20.13.22; Mon, 05 Jun 2023 20:13:58 -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=@intel.com header.s=Intel header.b=NjCLVRkz; 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=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234408AbjFFC5g (ORCPT + 99 others); Mon, 5 Jun 2023 22:57:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229660AbjFFC5e (ORCPT ); Mon, 5 Jun 2023 22:57:34 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 548ED187; Mon, 5 Jun 2023 19:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686020249; x=1717556249; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=F+vkV+jfb5o4EuHJj2V27tXZPhI2wJN8JMR+LPb/mNE=; b=NjCLVRkzAHHf7KH2MLO1pbkKAwsoTpkZG83+oGXI8lU3B6OptHTpjREd yAFOsyygdw0hD5fSqWYTTJgZKUwPh+Rf4wZ6El63PLuyayZc4SeyhS9nr R3nX7CJ+rilXzABCrNCYqeI3x9C0DLfgUjNB+b9LmKOEObbNq0nisKK8S ghEBo1pFt2UGyneLARPc79OrrSS9wJljcPwniBTtpgdoYMt4bH/Y17Kef RU4lQO9dSOdg1AbD6T9Zx0fO7CPVJptJ+faBTgzpIn12Xcl+rgkzXllTZ 0i5hSlVz6RuPEBcWirilDBUGUYr6HsS//UEZnlCNXfl9ohPEFBIQ0/uCi w==; X-IronPort-AV: E=McAfee;i="6600,9927,10732"; a="354042102" X-IronPort-AV: E=Sophos;i="6.00,219,1681196400"; d="scan'208";a="354042102" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jun 2023 19:57:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10732"; a="1039008219" X-IronPort-AV: E=Sophos;i="6.00,219,1681196400"; d="scan'208";a="1039008219" Received: from binbinwu-mobl.ccr.corp.intel.com (HELO [10.254.210.225]) ([10.254.210.225]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jun 2023 19:57:25 -0700 Message-ID: Date: Tue, 6 Jun 2023 10:57:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: [PATCH v1 3/6] KVM: VMX: Add new ops in kvm_x86_ops for LASS violation check To: Zeng Guang , Zhi Wang Cc: Paolo Bonzini , Sean Christopherson , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , H Peter Anvin , kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org References: <20230601142309.6307-1-guang.zeng@intel.com> <20230601142309.6307-4-guang.zeng@intel.com> <3b3d9106-9e4f-8a76-30ee-29540b06022a@linux.intel.com> <20230605205342.00000e41.zhi.wang.linux@gmail.com> From: Binbin Wu In-Reply-To: <20230605205342.00000e41.zhi.wang.linux@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 6/5/2023 8:53 PM, Zhi Wang wrote: > On Mon, 5 Jun 2023 11:31:48 +0800 > Binbin Wu wrote: > >> >> On 6/1/2023 10:23 PM, Zeng Guang wrote: >>> Intel introduces LASS (Linear Address Separation) feature providing >>                       ^ >>  missing "Space" here >>> an independent mechanism to achieve the mode-based protection. >>> >>> LASS partitions 64-bit linear address space into two halves, user-mode >>> address (LA[bit 63]=0) and supervisor-mode address (LA[bit 63]=1). It >>> stops any code execution or conditional data access[1] >>> 1. from user mode to supervisor-mode address space >>> 2. from supervisor mode to user-mode address space >>> and generates LASS violation fault accordingly. >>> >>> [1]A supervisor mode data access causes a LASS violation only if supervisor >>> mode access protection is enabled (CR4.SMAP = 1) and either RFLAGS.AC = 0 >>> or the access implicitly accesses a system data structure. >>> >>> Following are the rules of LASS violation check on the linear address(LA). >>> User access to supervisor-mode address space: >>> LA[bit 63] && (CPL == 3) >>> Supervisor access to user-mode address space: >>> Instruction fetch: !LA[bit 63] && (CPL < 3) >>> Data access: !LA[bit 63] && (CR4.SMAP==1) && ((RFLAGS.AC == 0 && >>> CPL < 3) || Implicit supervisor access) >>> >>> Add new ops in kvm_x86_ops to do LASS violation check. >>> >>> Signed-off-by: Zeng Guang >>> Tested-by: Xuelian Guo >>> --- >>> arch/x86/include/asm/kvm-x86-ops.h | 3 +- >>> arch/x86/include/asm/kvm_host.h | 2 ++ >>> arch/x86/kvm/kvm_emulate.h | 1 + >>> arch/x86/kvm/vmx/vmx.c | 47 ++++++++++++++++++++++++++++++ >>> arch/x86/kvm/vmx/vmx.h | 2 ++ >>> 5 files changed, 54 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-x86-ops.h >>> index 13bc212cd4bc..8980a3bfa687 100644 >>> --- a/arch/x86/include/asm/kvm-x86-ops.h >>> +++ b/arch/x86/include/asm/kvm-x86-ops.h >>> @@ -132,7 +132,8 @@ KVM_X86_OP_OPTIONAL(migrate_timers) >>> KVM_X86_OP(msr_filter_changed) >>> KVM_X86_OP(complete_emulated_msr) >>> KVM_X86_OP(vcpu_deliver_sipi_vector) >>> -KVM_X86_OP_OPTIONAL_RET0(vcpu_get_apicv_inhibit_reasons); >>> +KVM_X86_OP_OPTIONAL_RET0(vcpu_get_apicv_inhibit_reasons) >>> +KVM_X86_OP_OPTIONAL_RET0(check_lass) >>> >>> #undef KVM_X86_OP >>> #undef KVM_X86_OP_OPTIONAL >>> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h >>> index 92d8e65fe88c..98666d1e7727 100644 >>> --- a/arch/x86/include/asm/kvm_host.h >>> +++ b/arch/x86/include/asm/kvm_host.h >>> @@ -1731,6 +1731,8 @@ struct kvm_x86_ops { >>> * Returns vCPU specific APICv inhibit reasons >>> */ >>> unsigned long (*vcpu_get_apicv_inhibit_reasons)(struct kvm_vcpu *vcpu); >>> + >>> + bool (*check_lass)(struct kvm_vcpu *vcpu, u64 access, u64 la, u32 flags); >>> }; >>> >>> struct kvm_x86_nested_ops { >>> diff --git a/arch/x86/kvm/kvm_emulate.h b/arch/x86/kvm/kvm_emulate.h >>> index 5b9ec610b2cb..f1439ab7c14b 100644 >>> --- a/arch/x86/kvm/kvm_emulate.h >>> +++ b/arch/x86/kvm/kvm_emulate.h >>> @@ -91,6 +91,7 @@ struct x86_instruction_info { >>> /* x86-specific emulation flags */ >>> #define X86EMUL_F_FETCH BIT(0) >>> #define X86EMUL_F_WRITE BIT(1) >>> +#define X86EMUL_F_SKIPLASS BIT(2) >>> >>> struct x86_emulate_ops { >>> void (*vm_bugged)(struct x86_emulate_ctxt *ctxt); >>> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c >>> index a33205ded85c..876997e8448e 100644 >>> --- a/arch/x86/kvm/vmx/vmx.c >>> +++ b/arch/x86/kvm/vmx/vmx.c >>> @@ -8130,6 +8130,51 @@ static void vmx_vm_destroy(struct kvm *kvm) >>> free_pages((unsigned long)kvm_vmx->pid_table, vmx_get_pid_table_order(kvm)); >>> } >>> >>> +/* >>> + * Determine whether an access to the linear address causes a LASS violation. >>> + * LASS protection is only effective in long mode. As a prerequisite, caller >>> + * should make sure vCPU running in long mode and invoke this api to do LASS >>> + * violation check. >>> + */ >>> +bool vmx_check_lass(struct kvm_vcpu *vcpu, u64 access, u64 la, u32 flags) >>> +{ >>> + bool user_mode, user_as, rflags_ac; >>> + >>> + if (!!(flags & X86EMUL_F_SKIPLASS) || >>> + !kvm_is_cr4_bit_set(vcpu, X86_CR4_LASS)) >>> + return false; >>> + >>> + WARN_ON_ONCE(!is_long_mode(vcpu)); >> IMHO, it's better to skip the following checks and return false if it is >> out of long mode. >> > The check of long mode is in the caller implemented in in the next patch. :) > > + if (!is_long_mode(vcpu)) > + return false; I know the callers have checked the mode, however, IMHO, it's better as following: + if (!!(flags & X86EMUL_F_SKIPLASS) || + !kvm_is_cr4_bit_set(vcpu, X86_CR4_LASS) || WARN_ON_ONCE(!is_long_mode(vcpu))) + return false; >>> + >>> + user_as = !(la >> 63); >> It's better to describe how LASS treat linear address in compatibility >> mode in changelog or/and in comment, >> i.e. for a linear address with only 32 bits (or 16 bits), the processor >> treats bit 63 as if it were 0. >> >> >>> + >>> + /* >>> + * An access is a supervisor-mode access if CPL < 3 or if it implicitly >>> + * accesses a system data structure. For implicit accesses to system >>> + * data structure, the processor acts as if RFLAGS.AC is clear. >>> + */ >>> + if (access & PFERR_IMPLICIT_ACCESS) { >>> + user_mode = false; >>> + rflags_ac = false; >>> + } else { >>> + user_mode = vmx_get_cpl(vcpu) == 3; >>> + if (!user_mode) >>> + rflags_ac = !!(kvm_get_rflags(vcpu) & X86_EFLAGS_AC); >>> + } >>> + >>> + if (user_mode == user_as) >>> + return false; >>> + >>> + /* >>> + * Supervisor-mode _data_ accesses to user address space >>> + * cause LASS violations only if SMAP is enabled. >>> + */ >>> + if (!user_mode && !(access & PFERR_FETCH_MASK)) >>> + return kvm_is_cr4_bit_set(vcpu, X86_CR4_SMAP) && !rflags_ac; >>> + >>> + return true; >>> +} >>> + >>> static struct kvm_x86_ops vmx_x86_ops __initdata = { >>> .name = KBUILD_MODNAME, >>> >>> @@ -8269,6 +8314,8 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = { >>> .complete_emulated_msr = kvm_complete_insn_gp, >>> >>> .vcpu_deliver_sipi_vector = kvm_vcpu_deliver_sipi_vector, >>> + >>> + .check_lass = vmx_check_lass, >>> }; >>> >>> static unsigned int vmx_handle_intel_pt_intr(void) >>> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h >>> index 9e66531861cf..f2e775b9849b 100644 >>> --- a/arch/x86/kvm/vmx/vmx.h >>> +++ b/arch/x86/kvm/vmx/vmx.h >>> @@ -433,6 +433,8 @@ void vmx_enable_intercept_for_msr(struct kvm_vcpu *vcpu, u32 msr, int type); >>> u64 vmx_get_l2_tsc_offset(struct kvm_vcpu *vcpu); >>> u64 vmx_get_l2_tsc_multiplier(struct kvm_vcpu *vcpu); >>> >>> +bool vmx_check_lass(struct kvm_vcpu *vcpu, u64 access, u64 la, u32 flags); >>> + >>> static inline void vmx_set_intercept_for_msr(struct kvm_vcpu *vcpu, u32 msr, >>> int type, bool value) >>> {