From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 378E725F790 for ; Thu, 27 Feb 2025 19:34:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740684864; cv=none; b=e0DWVsHNff/rYZL6VpdQsORKYeTj8VWYDRBFVVIa3Uyz+hdyQel1BJT3NgX6X/tkTcw7Wp53knxFBHIWjqKvpDWQWcP1widQMFh0hnObYKMGkD8HExYH4S0GdGMjI9asYEdeLJpDKpqkwdlt/pTl2///39GkxRZeiotmJqVg7SE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740684864; c=relaxed/simple; bh=iqMFOWoLHPzEE2F7btnovEmgqjRXPhaMKoi0v82VKo8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=D5ZVshhfnb17DOQ99HQsYCE43L4KqV1QTc3d+eIz90HKK8mxsh0U8AV8c3RAVQhRI/vXBAIlhqHgBcwLAKLQLSKn7JWObN8yA5nT50tyOBVJoLVn9IobvD6pWt2oTDnaysqLBt0Jos8YX0D9aoycK87eBTWzlGTrVeYwxAbAErs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=3yEKuo4f; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="3yEKuo4f" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fc0bc05c00so4176268a91.2 for ; Thu, 27 Feb 2025 11:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740684862; x=1741289662; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=a17KzYivCQNainroozlTYNEBao153DxG5A3TbD1B1BQ=; b=3yEKuo4f/teswu2As+3lw0lv5gQhsJJufpp9x9e7MvRtpLNrOtlBkIvUrkNXTgdvZ2 xeNLH5hOCtY3wbvJr+LzCSCttMV2qRR7sHAC92Ks3Hmc3YOf23fS2nllS3gqwvLpTf/i 3A5+0FZsvxoOZE9eTC4iRXLHx3kZsaSUTDKRg15xa8PP5g/JB3tCFb9EWn6uxI5O530K o7xZkCYweNtvEnZJbR1eccJ3w9ARwHUBtPf+hHcbDSJcmVEeIjyMiK7h1BnuaO9zN8wi Xoxqah/370wMTEzVEumLM8XsjFFIT1tKbEEPf505/unuwD7QYQAaBqyzGTaulBPDtSTw AlDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740684862; x=1741289662; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=a17KzYivCQNainroozlTYNEBao153DxG5A3TbD1B1BQ=; b=p5urkR1wZWY23ZlAxKYnh5dbr3V8Hod90S1+oXbdbs/qV/nJUHeko1MhsOpj2rnf+u 38ystJKd/YbcnFF4cnpoaExQP4W4p4/XYtwNmwHrCcpCNcn9QATbPGitQiTk10zJ0Itt JwOmz6JDdJxYyHOzX8nATZULJVTpRfIt2ijS1uV2HNxTcEcsUDcOX8hdRFdIARDRcKXZ SPDPuDDAzMmL4d668zcV359eQBYy8C/jxcE272nD5MXjbzKeQMKSwT3ieBBT/oeJK/Rv DTMX53aOLBXDp7kHuwXCjS1Yp27Oxar7tFqOhqAGLqsROeWmR8LhWNbKPB4NtyYlvND7 RNPQ== X-Forwarded-Encrypted: i=1; AJvYcCXdg34sJOexvohaFKXIVTdwSa56Kdj5CpHHQQD3yx6mzb+TLPh1r+jcZAZvgZKONzlzma8n/JA6tHPYaRE=@vger.kernel.org X-Gm-Message-State: AOJu0YwdNlq739Tw3t0BlFk03LH3Ax6cuN3/oQBoTxLHtp3h9bxlrQI9 YEABN+At5nSq8HYJpwYCV11rD6KPBJ4OTX8mVn7RT8G7YQawqcSND9ltRnQOL0dGxBH8w+sWnHr bug== X-Google-Smtp-Source: AGHT+IF+7pMShNlkxX9Q3ftILKLxc4OcR65JsoK+DbBdUkSfdPP3enQqEnHoYWbV/VbGsPrN73yEXxb17ZE= X-Received: from pjboi16.prod.google.com ([2002:a17:90b:3a10:b0:2fc:1eb0:5743]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4a89:b0:2ee:8ea0:6b9c with SMTP id 98e67ed59e1d1-2febab570b1mr1014148a91.12.1740684862557; Thu, 27 Feb 2025 11:34:22 -0800 (PST) Date: Thu, 27 Feb 2025 19:34:21 +0000 In-Reply-To: <88E181D6-323E-4352-8E4C-7B7191707611@nutanix.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227000705.3199706-1-seanjc@google.com> <20250227000705.3199706-3-seanjc@google.com> <73f00589-7d6d-489a-ae40-fefdf674ea42@suse.com> <88E181D6-323E-4352-8E4C-7B7191707611@nutanix.com> Message-ID: Subject: Re: [PATCH v2 2/2] KVM: nVMX: Decouple EPT RWX bits from EPT Violation protection bits From: Sean Christopherson To: Jon Kohler Cc: Nikolay Borisov , Paolo Bonzini , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 27, 2025, Jon Kohler wrote: > > On Feb 27, 2025, at 1:52=E2=80=AFAM, Nikolay Borisov wrote: > >=20 > > !-------------------------------------------------------------------| > > CAUTION: External Email Noted. :-D > > |-------------------------------------------------------------------! > >=20 > > On 27.02.25 =D0=B3. 2:07 =D1=87., Sean Christopherson wrote: > >> Define independent macros for the RWX protection bits that are enumera= ted > >> via EXIT_QUALIFICATION for EPT Violations, and tie them to the RWX bit= s in > >> EPT entries via compile-time asserts. Piggybacking the EPTE defines w= orks > >> for now, but it creates holes in the EPT_VIOLATION_xxx macros and will > >> cause headaches if/when KVM emulates Mode-Based Execution (MBEC), or a= ny > >> other features that introduces additional protection information. > >> Opportunistically rename EPT_VIOLATION_RWX_MASK to EPT_VIOLATION_PROT_= MASK > >> so that it doesn't become stale if/when MBEC support is added. > >> No functional change intended. > >> Cc: Jon Kohler > >> Cc: Nikolay Borisov > >> Signed-off-by: Sean Christopherson > >=20 > > Reviewed-by: Nikolay Borisov >=20 > LGTM, but any chance we could hold this until I get the MBEC RFC out?=20 No? It's definitely landing before the MBEC support, and IOM it works quit= e nicely with the MBEC support (my diff at the bottom). I don't see any reason to d= elay or change this cleanup. > My apologies on the delay, I caught a terrible chest cold after we met ab= out > it, followed by a secondary case of strep! Ow. Don't rush on behalf of upstream, KVM has lived without MBEC for a lon= g time, it's not going anywhere.o --- arch/x86/include/asm/vmx.h | 4 +++- arch/x86/kvm/mmu/paging_tmpl.h | 9 +++++++-- arch/x86/kvm/vmx/vmx.c | 7 +++++++ 3 files changed, 17 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h index d7ab0ad63be6..61e31e915e46 100644 --- a/arch/x86/include/asm/vmx.h +++ b/arch/x86/include/asm/vmx.h @@ -587,9 +587,11 @@ enum vm_entry_failure_code { #define EPT_VIOLATION_PROT_READ BIT(3) #define EPT_VIOLATION_PROT_WRITE BIT(4) #define EPT_VIOLATION_PROT_EXEC BIT(5) +#define EPT_VIOLATION_PROT_USER_EXEC BIT(6) #define EPT_VIOLATION_PROT_MASK (EPT_VIOLATION_PROT_READ | \ EPT_VIOLATION_PROT_WRITE | \ - EPT_VIOLATION_PROT_EXEC) + EPT_VIOLATION_PROT_EXEC | \ + EPT_VIOLATION_PROT_USER_EXEC) #define EPT_VIOLATION_GVA_IS_VALID BIT(7) #define EPT_VIOLATION_GVA_TRANSLATED BIT(8) =20 diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.= h index 68e323568e95..ede8207bf4d7 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -181,8 +181,9 @@ static inline unsigned FNAME(gpte_access)(u64 gpte) unsigned access; #if PTTYPE =3D=3D PTTYPE_EPT access =3D ((gpte & VMX_EPT_WRITABLE_MASK) ? ACC_WRITE_MASK : 0) | - ((gpte & VMX_EPT_EXECUTABLE_MASK) ? ACC_EXEC_MASK : 0) | - ((gpte & VMX_EPT_READABLE_MASK) ? ACC_USER_MASK : 0); + ((gpte & VMX_EPT_EXECUTABLE_MASK) ? ACC_EXEC_MASK : 0) | + ((gpte & VMX_EPT_USER_EXECUTABLE_MASK) ? ACC_USER_EXEC_MASK : 0) | + ((gpte & VMX_EPT_READABLE_MASK) ? ACC_USER_MASK : 0); #else BUILD_BUG_ON(ACC_EXEC_MASK !=3D PT_PRESENT_MASK); BUILD_BUG_ON(ACC_EXEC_MASK !=3D 1); @@ -511,6 +512,10 @@ static int FNAME(walk_addr_generic)(struct guest_walke= r *walker, * ACC_*_MASK flags! */ walker->fault.exit_qualification |=3D EPT_VIOLATION_RWX_TO_PROT(pte_acce= ss); + /* This is also wrong.*/ + if (vcpu->arch.pt_guest_exec_control && + (pte_access & VMX_EPT_USER_EXECUTABLE_MASK)) + walker->fault.exit_qualification |=3D EPT_VIOLATION_PROT_USER_EXEC; } #endif walker->fault.address =3D addr; diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 0db64f4adf2a..4684647ef063 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -5806,6 +5806,13 @@ static int handle_ept_violation(struct kvm_vcpu *vcp= u) =20 exit_qualification =3D vmx_get_exit_qual(vcpu); =20 + /* + * The USER_EXEC flag is undefined if MBEC is disabled. + * Note, this is wrong, MBEC should be a property of the MMU. + */ + if (!vcpu->arch.pt_guest_exec_control) + exit_qualification &=3D ~EPT_VIOLATION_PROT_USER_EXEC; + /* * EPT violation happened while executing iret from NMI, * "blocked by NMI" bit has to be set before next VM entry. base-commit: 67983df09fc3f96d0d6107fe1a99d29460bab481 --=20