linux-kernel - Re: [PATCH 1/3] kvm: wire up KVM_CAP_VM_GPA

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: <8106d06c-4359-47ef-b363-a6302e1271a4@intel.com>
Date: Tue, 5 Mar 2024 10:59:23 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Sean Christopherson <seanjc@...gle.com>, Gerd Hoffmann <kraxel@...hat.com>
Cc: kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
 "H. Peter Anvin" <hpa@...or.com>,
 "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] kvm: wire up KVM_CAP_VM_GPA_BITS for x86

On 3/4/2024 11:15 PM, Sean Christopherson wrote:
> On Fri, Mar 01, 2024, Gerd Hoffmann wrote:
>> Add new guest_phys_bits field to kvm_caps, return the value to
>> userspace when asked for KVM_CAP_VM_GPA_BITS capability.
>>
>> Initialize guest_phys_bits with boot_cpu_data.x86_phys_bits.
>> Vendor modules (i.e. vmx and svm) can adjust this field in case
>> additional restrictions apply, for example in case EPT has no
>> support for 5-level paging.
>>
>> Signed-off-by: Gerd Hoffmann <kraxel@...hat.com>
>> ---
>>   arch/x86/kvm/x86.h | 2 ++
>>   arch/x86/kvm/x86.c | 5 +++++
>>   2 files changed, 7 insertions(+)
>>
>> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
>> index 2f7e19166658..e03aec3527f8 100644
>> --- a/arch/x86/kvm/x86.h
>> +++ b/arch/x86/kvm/x86.h
>> @@ -24,6 +24,8 @@ struct kvm_caps {
>>   	bool has_bus_lock_exit;
>>   	/* notify VM exit supported? */
>>   	bool has_notify_vmexit;
>> +	/* usable guest phys bits */
>> +	u32  guest_phys_bits;
>>   
>>   	u64 supported_mce_cap;
>>   	u64 supported_xcr0;
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 48a61d283406..e270b9b708d1 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -4784,6 +4784,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>   		if (kvm_is_vm_type_supported(KVM_X86_SW_PROTECTED_VM))
>>   			r |= BIT(KVM_X86_SW_PROTECTED_VM);
>>   		break;
>> +	case KVM_CAP_VM_GPA_BITS:
>> +		r = kvm_caps.guest_phys_bits;
> 
> This is not a fast path, just compute the effective guest.MAXPHYADDR on the fly
> using tdp_root_level and max_tdp_level.  But as pointed out and discussed in the
> previous thread, adverising a guest.MAXPHYADDR that is smaller than host.MAXPHYADDR
> simply doesn't work[*].
> 
> I thought the plan was to add a way for KVM to advertise the maximum *addressable*
> GPA, and figure out a way to communicate that to the guest, e.g. so that firmware
> doesn't try to use legal GPAs that the host cannot address.

 From one off-list email thread, Paolo was proposing to change the 
definition of CPUID.0x80000008:EAX[23:16] to "Maximum usable physical 
address size in bits", in detail:

  Maximum usable physical address size in bits. Physical addresses
  above this size should not be used, but will not produce a "reserved"
  page fault. When this field is zero, all bits up to PhysAddrSize are
  usable. This field is expected to be nonzero only on guests where
  the hypervisor is using nesting paging.

As I understand it, it turns bit [23:16] of EAX of CPUID 0x80000008 into 
a PV field, that is set by VMM(e.g., KVM/QEMU) and consumed by guest.

So KVM can advertise maximum addressable/usable physical address bits in 
CPUID.0x80000008:EAX[23:16] via GET_SUPPORTED_CPUID.

> Paolo, any update on this?
> 
> [*] https://lore.kernel.org/all/CALMp9eTutnTxCjQjs-nxP=XC345vTmJJODr+PcSOeaQpBW0Skw@mail.gmail.com
>