linux-kernel - Re: [PATCH] KVM: x86: Add host physical address width capability

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <jpgy4ip6v1y.fsf@linux.bootlegged.copy>
Date:	Thu, 09 Jul 2015 14:32:41 -0400
From:	Bandan Das <bsd@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Laszlo Ersek <lersek@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, qemu-devel@...gnu.org
Subject: Re: [PATCH] KVM: x86: Add host physical address width capability

Paolo Bonzini <pbonzini@...hat.com> writes:

> On 09/07/2015 08:43, Laszlo Ersek wrote:
>> On 07/09/15 08:09, Paolo Bonzini wrote:
>>>
>>>
>>> On 09/07/2015 00:36, Bandan Das wrote:
>>>> Let userspace inquire the maximum physical address width
>>>> of the host processors; this can be used to identify maximum
>>>> memory that can be assigned to the guest.
>>>>
>>>> Reported-by: Laszlo Ersek <lersek@...hat.com>
>>>> Signed-off-by: Bandan Das <bsd@...hat.com>
>>>> ---
>>>>  arch/x86/kvm/x86.c       | 3 +++
>>>>  include/uapi/linux/kvm.h | 1 +
>>>>  2 files changed, 4 insertions(+)
>>>>
>>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>>> index bbaf44e..97d6746 100644
>>>> --- a/arch/x86/kvm/x86.c
>>>> +++ b/arch/x86/kvm/x86.c
>>>> @@ -2683,6 +2683,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>  	case KVM_CAP_NR_MEMSLOTS:
>>>>  		r = KVM_USER_MEM_SLOTS;
>>>>  		break;
>>>> +	case KVM_CAP_PHY_ADDR_WIDTH:
>>>> +		r = boot_cpu_data.x86_phys_bits;
>>>> +		break;
>>>
>>> Userspace can just use CPUID, can't it?
>> 
>> I believe KVM's cooperation is necessary, for the following reason:
>> 
>> The truncation only occurs when the guest-phys <-> host-phys translation
>> is done in hardware, *and* the phys bits of the host processor are
>> insufficient to represent the highest guest-phys address that the guest
>> will ever face.
>> 
>> The first condition (of course) means that the truncation depends on EPT
>> being enabled. (I didn't test on AMD so I don't know if RVI has the same
>> issue.) If EPT is disabled, either because the host processor lacks it,
>> or because the respective kvm_intel module parameter is set so, then the
>> issue cannot be experienced.
>> 
>> Therefore I believe a KVM patch is necessary.
>> 
>> However, this specific patch doesn't seem sufficient; it should also
>> consider whether EPT is enabled. (And the ioctl should be perhaps
>> renamed to reflect that -- what QEMU needs to know is not the raw
>> physical address width of the host processor, but whether that width
>> will cause EPT to silently truncate high guest-phys addresses.)
>
> Right; if you want to consider whether EPT is enabled (which is the
> right thing to do, albeit it makes for a much bigger patch) a KVM patch
> is necessary.  In that case you also need to patch the API documentation.

Note that this patch really doesn't do anything except for printing a
message that something might potentially go wrong. Without EPT, you don't
hit the processor limitation with your setup, but the user should nevertheless
still be notified. In fact, I think shadow paging code should also emulate
this behavior if the gpa is out of range.

> Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/