Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp302117rwd; Tue, 6 Jun 2023 23:32:59 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4t/ei9nUKpPq9/TILo4SGErOT6LEOP6H8uEd04DQXa8fCrhSdJEu0TM2A46IzJH9rsaYVL X-Received: by 2002:a17:902:db01:b0:1ac:750e:33d5 with SMTP id m1-20020a170902db0100b001ac750e33d5mr4940469plx.15.1686119579194; Tue, 06 Jun 2023 23:32:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686119579; cv=none; d=google.com; s=arc-20160816; b=CsLksN7GmYVI6+mAvpxYHpsh75h0jJ266kD615xZ2iQmZQsaVEnjCGEpCn0rxxn3mb Kzkm1ZY3YoX/2Dpnw/oS2bK0Ic4mUZycuKt+fEITp3W+ahE6C5hIvKnKXBKrIJgYWD4r bukiHvihbPEqqp/DOsfxtCH/rubpw6HxS9f8x/hKzATrs/kYvUBddMhNRs8VxY+LRmS8 ZohUMG+u9Vtnhq89wIlzuISI5AWiIYpkV5ORU0fHA5EfePw9zOVonG/NYczohicPcfJw GkKxe5gOGPCKCh0V6zPQpbGuuDE0S9YpZuNYGTRPo9s7LJFbRJsrNRJanoZ0XFSO/aal 433g== 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:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=F1bMSRX+oumqiu/J/Hob5CpMlvwXbXmZ2JheN4N3GSo=; b=wl7jIgim3t+GN+IAQJDa86I05+t1h3dZ7k0RPYd0USUya7QiEajTc6YTD1h2RAg/9T 8QRTWzzcncKm8biZs4CpawGh/R9vLNiEtVTVvsKRfM/es/EwL7SC5yLAndje3Lg/9CXA sa24wxH6iVbXxlEG6P7t/nEsaeaEDQMJYxi+HLk6aP53RMVDuvPr+Wxc4Tc9wTknuh8H iATsb0ngfDEQXosHvf7xyHCl+RYoPRP5t9fcwG0ZLlgiSt9AiRqXBXHEAxSZtGUHOvNa c0fe6xCTAKrmcTjGjD/TWNHVN+Xz5WFeJfhQENucPIV4f86/YRv9yHMfuCX/dEzaFEox 8qVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JC1PJLYG; 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 bd5-20020a170902830500b001a1d78af685si8126127plb.466.2023.06.06.23.32.44; Tue, 06 Jun 2023 23:32:59 -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=JC1PJLYG; 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 S235163AbjFGG32 (ORCPT + 99 others); Wed, 7 Jun 2023 02:29:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234210AbjFGG3V (ORCPT ); Wed, 7 Jun 2023 02:29:21 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D58F1FCA; Tue, 6 Jun 2023 23:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686119347; x=1717655347; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=8s4/A/li4xc6E8e+qolexVNkC6cEYlX78umXHVQ4tug=; b=JC1PJLYG/JeamTxlDwYJsF6yjTHNgsxLtgdMPE6vGZPdRAYZg3ZkrJaJ h30W3cscfwvYfiW71aYbW7ePx935oIG56Znuiyi0IJt5A9nHZGP4eLQA0 ykLWcOwixqJFJFdOjx/DQBFJyqXRDewWdF+O145f4dCEYq3VyfObhaXhi dTjBjoCpknxJCsY4wYCdl78UQGFkzEy6ADk+NV/Zq53HaldH7Z4FBSWjg oQB9vJLvJzF8S6ymbuHfttXeoBy0fS7rGAV8NdY0WBeFiggxNpudcw7oq dnupToA1dUGAe69Bs0em3jRdCmgEkLfFwWBQ5estgntFWhl0ZnljXOfsZ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10733"; a="354392635" X-IronPort-AV: E=Sophos;i="6.00,223,1681196400"; d="scan'208";a="354392635" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jun 2023 23:29:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10733"; a="799175329" X-IronPort-AV: E=Sophos;i="6.00,223,1681196400"; d="scan'208";a="799175329" Received: from zengguan-mobl1.ccr.corp.intel.com (HELO [10.238.0.196]) ([10.238.0.196]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jun 2023 23:29:04 -0700 Message-ID: Date: Wed, 7 Jun 2023 14:28:54 +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 Content-Language: en-US To: Binbin Wu Cc: Paolo Bonzini , "Christopherson,, Sean" , 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> From: Zeng Guang In-Reply-To: <3b3d9106-9e4f-8a76-30ee-29540b06022a@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 11:31 AM, Binbin Wu wrote: > > On 6/1/2023 10:23 PM, Zeng Guang wrote: >> Intel introduces LASS (Linear Address Separation) feature providing >                       ^ >  missing "Space" here Thanks. >> 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. In some cases , cpu mode check already exists before invoking LASS violation detect, e.g. vmx instruction emulation. So it's designed to make vmx_check_lass() focusing on LASS violation alone, and leave it to caller taking care of cpu mode in advance. The purpose is to avoid duplicating cpu mode check though the impact seems not significant. :) >> + >> + 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. > OK, will add comments on specific treatment in compatibility mode. >> + >> + /* >> + * 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) >> {