linux-kernel - Re: [RFC PATCH 10/18] KVM: VMX: Extend EPT Violation protection bits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8B9EBE3E-0EA0-4EAA-A0B6-731F08A172DE@nutanix.com>
Date: Tue, 23 Dec 2025 04:15:43 +0000
From: Jon Kohler <jon@...anix.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "tglx@...utronix.de"
	<tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de"
	<bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 10/18] KVM: VMX: Extend EPT Violation protection bits



> On May 12, 2025, at 2:37 PM, Sean Christopherson <seanjc@...gle.com> wrote:
> 
> On Thu, Mar 13, 2025, Jon Kohler wrote:
>> Define macros for READ, WRITE, EXEC protection bits, to be used by
>> MBEC-enabled systems.
>> 
>> No functional change intended.
>> 
>> Signed-off-by: Jon Kohler <jon@...anix.com>
>> 
>> ---
>> arch/x86/include/asm/vmx.h | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>> 
>> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
>> index d7ab0ad63be6..ffc90d672b5d 100644
>> --- a/arch/x86/include/asm/vmx.h
>> +++ b/arch/x86/include/asm/vmx.h
>> @@ -593,8 +593,17 @@ enum vm_entry_failure_code {
>> #define EPT_VIOLATION_GVA_IS_VALID BIT(7)
>> #define EPT_VIOLATION_GVA_TRANSLATED BIT(8)
>> 
>> +#define EPT_VIOLATION_READ_TO_PROT(__epte) (((__epte) & VMX_EPT_READABLE_MASK) << 3)
>> +#define EPT_VIOLATION_WRITE_TO_PROT(__epte) (((__epte) & VMX_EPT_WRITABLE_MASK) << 3)
>> +#define EPT_VIOLATION_EXEC_TO_PROT(__epte) (((__epte) & VMX_EPT_EXECUTABLE_MASK) << 3)
>> #define EPT_VIOLATION_RWX_TO_PROT(__epte) (((__epte) & VMX_EPT_RWX_MASK) << 3)
>> 
>> +static_assert(EPT_VIOLATION_READ_TO_PROT(VMX_EPT_READABLE_MASK) ==
>> +      (EPT_VIOLATION_PROT_READ));
>> +static_assert(EPT_VIOLATION_WRITE_TO_PROT(VMX_EPT_WRITABLE_MASK) ==
>> +      (EPT_VIOLATION_PROT_WRITE));
>> +static_assert(EPT_VIOLATION_EXEC_TO_PROT(VMX_EPT_EXECUTABLE_MASK) ==
>> +      (EPT_VIOLATION_PROT_EXEC));
> 
> Again, as a general rule, introduce macros and helpers functions when they are
> first used, not as tiny prep patches.  There are exceptions to that rule, e.g. to
> avoid cyclical dependencies or to isolate arch/vendor changes, but know of those
> exceptions apply in this series.
> 
> Patches like this are effectively impossible to review from a design/intent
> perspective, because without peeking at the usage that comes along later, there's
> no way to determine whether or not it makes sense to add these macros.
> 
> And looking ahead, I don't see any reason to slice n' dice the RWX=>prot macro.
> 
> TL;DR: drop this patch.

Sold! Dropped this one and cleaned it all up for v1