Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp6428386rwr; Mon, 24 Apr 2023 20:41:05 -0700 (PDT) X-Google-Smtp-Source: AKy350YPh5H5TTySF9D0Ox1Il+zRyL/hzjAjFlTzzSoTmsBTVYP+tDZw/Isbym+4zHLGaNXnhNIm X-Received: by 2002:a17:90a:71c4:b0:24b:2e6a:24f8 with SMTP id m4-20020a17090a71c400b0024b2e6a24f8mr15617223pjs.41.1682394065475; Mon, 24 Apr 2023 20:41:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682394065; cv=none; d=google.com; s=arc-20160816; b=ubBYdfA2VQDtcrO9effFrAsOa1CRRpyIS3rJ+mxt+rXdjCohmXqZ2qOPuz9Lkgu52h YImJKALUA/8LAfFEt4hEmeQM2wbyPpQiTSc453iqln29gPs7xelLSqKHtIBJ//vGo4pI C+Krz695Mwtvn9MAuvDVJSsTuc1j29f30WiEyARq2pn8QmgVDo2itHPVrvnStyRHdS72 uvYqQzIUSKoYDdF7Yu3oimCKKJqTmJ643U7+qalRfEU0fse47RG7MTE8qQpW+jllmy/J yOgHBZLPL8Otj06Vf5EW1qmdyp5dIGR+edSupLJj9QUPTMFfuOPiiUjSvCglBQKt9Niv 5Y4w== 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=Swk47UC2hhbw8oDvNWe5Kt4H8EbcTyzrB9jbq4kUVxg=; b=rusktZYJK50wFyPpRU8Tky47FfOmc6cbypg2UT1G+O06uIucVpe8b2Blnu2/J0U+iU x3uSKVWX2AbeOse8PP9bqM59HNNYfZWOmCvOIpYQ+XYHS4MTNRTB9io3sGFYKPCsYQuG 7izucoLm9bkFcxvpH4PIBl1ijDvrMo6fC6ZHe8u5X2m2UjYKioMxBYWaDfvxoziBr9Sj fukvzQELXPN4r2ytQE9nZ0oUoa97XYsA3Pwt5nRt1TpWqid5DJyJuiIjvNwy6v/v6fKZ l1ThfXPWilmTwYDJKU3Lj1oUlXLu5+FboY09KEUKDr5J4bFe+PdTS4xlU5iPJyz/DmkH Tjfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="STY44/0t"; 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 q6-20020a17090aa00600b00246f8b06125si15022233pjp.108.2023.04.24.20.40.51; Mon, 24 Apr 2023 20:41:05 -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="STY44/0t"; 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 S233265AbjDYD1V (ORCPT + 99 others); Mon, 24 Apr 2023 23:27:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233263AbjDYD1B (ORCPT ); Mon, 24 Apr 2023 23:27:01 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52D22AF17; Mon, 24 Apr 2023 20:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1682393211; x=1713929211; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=MykIHyOnFBYvjtTNVdllwAiFmLXXR+pbIjotFGUpHJg=; b=STY44/0tER/dmOvP3H/XaGjIEqGGIAmHIYlaFxDRGnzZBdZZnykEJ9ju YD0d9nFVITvjPxoXw5QnlRFnPEO4su409Tyomq2gRuiMxkgN78odi/C0Q CeRpkNeGFHWH2Pvjup8jHYYdxx62EW6imOCvnNR6yzFzlNVQqUK8+++FW Z5V3l1CyOZ9x6N20RrxZdmCb2V+JhUroBxiUw1x5m303l9eUE5S5SheyT DKz/2UKeWKvIx7txPbF1WIweFwNG7sJtYgOfZnaVpBzxTnnmkF5fkRT+K MkLfko4X5vvWCROwQzGEvS8dM9DpoAD57FtJviBx4vWjZl4BmvFaxQ3ey A==; X-IronPort-AV: E=McAfee;i="6600,9927,10690"; a="346656800" X-IronPort-AV: E=Sophos;i="5.99,224,1677571200"; d="scan'208";a="346656800" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Apr 2023 20:26:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10690"; a="837253766" X-IronPort-AV: E=Sophos;i="5.99,224,1677571200"; d="scan'208";a="837253766" Received: from zengguan-mobl1.ccr.corp.intel.com (HELO [10.238.0.183]) ([10.238.0.183]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Apr 2023 20:26:47 -0700 Message-ID: <040a4d50-d25b-c6b9-960a-a85dda30b857@intel.com> Date: Tue, 25 Apr 2023 11:26:34 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH 2/6] KVM: VMX: Add new ops in kvm_x86_ops for LASS violation check Content-Language: en-US To: Binbin Wu , Paolo Bonzini , "Christopherson,, Sean" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , H Peter Anvin , "kvm@vger.kernel.org" Cc: "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Gao, Chao" References: <20230420133724.11398-1-guang.zeng@intel.com> <20230420133724.11398-3-guang.zeng@intel.com> <735e3259-26d4-33f1-0e59-8171d1e832e9@linux.intel.com> From: Zeng Guang In-Reply-To: <735e3259-26d4-33f1-0e59-8171d1e832e9@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 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 4/24/2023 3:43 PM, Binbin Wu wrote: > > On 4/20/2023 9:37 PM, Zeng Guang wrote: >> Intel introduce LASS (Linear Address Separation) feature providing > /s/introduce/introduces OK. > >> 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 data access >> 1. from user mode to supervisor-mode address space >> 2. from supervisor mode to user-mode address space >> and generates LASS violation fault accordingly. > IMO, the description of the point 2 may be misleading that LASS stops > any data access from supervisor mode to user mode address space, > although the description following adds the conditions. May change to " It stops any code execution or conditional data access". The condition is illustrated in next paragraph. > >> 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 rule of LASS violation check on the linear address(LA). > /s/rule/rules OK. >> 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 >> --- >> arch/x86/include/asm/kvm-x86-ops.h | 1 + >> arch/x86/include/asm/kvm_host.h | 5 +++ >> arch/x86/kvm/vmx/vmx.c | 55 ++++++++++++++++++++++++++++++ >> arch/x86/kvm/vmx/vmx.h | 2 ++ >> 4 files changed, 63 insertions(+) >> >> diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-x86-ops.h >> index abccd51dcfca..f76c07f2674b 100644 >> --- a/arch/x86/include/asm/kvm-x86-ops.h >> +++ b/arch/x86/include/asm/kvm-x86-ops.h >> @@ -131,6 +131,7 @@ 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(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 8ff89a52ef66..31fb8699a1ff 100644 >> --- a/arch/x86/include/asm/kvm_host.h >> +++ b/arch/x86/include/asm/kvm_host.h >> @@ -69,6 +69,9 @@ >> #define KVM_X86_NOTIFY_VMEXIT_VALID_BITS (KVM_X86_NOTIFY_VMEXIT_ENABLED | \ >> KVM_X86_NOTIFY_VMEXIT_USER) >> >> +/* x86-specific emulation flags */ >> +#define KVM_X86_EMULFLAG_SKIP_LASS _BITULL(1) > Do you use the flag outside of emulator? > For LAM patch, it's planned to move the flags inside emulator. IMO, the detailed flag is implementation specific. Is it necessary to bind with emulator though it's only used inside emulator ? >> + >> /* x86-specific vcpu->requests bit members */ >> #define KVM_REQ_MIGRATE_TIMER KVM_ARCH_REQ(0) >> #define KVM_REQ_REPORT_TPR_ACCESS KVM_ARCH_REQ(1) >> @@ -1706,6 +1709,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, u64 flags); > The flags may be dropped if the caller knows to skip it or not. Probably I don't get you right. Do you mean it need define another function without flags ? >> }; >> >> struct kvm_x86_nested_ops { >> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c >> index c923d7599d71..581327ede66a 100644 >> --- a/arch/x86/kvm/vmx/vmx.c >> +++ b/arch/x86/kvm/vmx/vmx.c >> @@ -8070,6 +8070,59 @@ 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 VM > Should be vCPU? Similar meaning, I think. :) >> 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, u64 flags) >> +{ >> + bool user_mode, user_as, rflags_ac; >> + >> + if (!!(flags & KVM_X86_EMULFLAG_SKIP_LASS) || >> + !kvm_is_cr4_bit_set(vcpu, X86_CR4_LASS)) >> + return false; >> + >> + WARN_ON_ONCE(!is_long_mode(vcpu)); >> + >> + user_as = !(la >> 63); >> + >> + /* >> + * 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) { >> + /* >> + * 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; >> + } else { >> + return true; >> + } >> + } >> + >> + return false; >> +} >> + >> +static bool vmx_check_lass(struct kvm_vcpu *vcpu, u64 access, u64 la, u64 flags) >> +{ >> + return is_long_mode(vcpu) && __vmx_check_lass(vcpu, access, la, flags); >> +} >> + >> static struct kvm_x86_ops vmx_x86_ops __initdata = { >> .name = "kvm_intel", >> >> @@ -8207,6 +8260,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 a3da84f4ea45..6569385a5978 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, u64 flags); >> + >> static inline void vmx_set_intercept_for_msr(struct kvm_vcpu *vcpu, u32 msr, >> int type, bool value) >> {