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 for Android: free password hash cracker in your pocket

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

Message-ID: <559FD30C.4000209@redhat.com>
Date:	Fri, 10 Jul 2015 16:13:32 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Laszlo Ersek <lersek@...hat.com>, Bandan Das <bsd@...hat.com>
Cc:	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	qemu-devel@...gnu.org
Subject: Re: [PATCH] KVM: x86: Add host physical address width capability



On 09/07/2015 20:57, Laszlo Ersek wrote:
>> Without EPT, you don't
>> hit the processor limitation with your setup, but the user should nevertheless
>> still be notified.
> 
> I disagree.

FWIW, I also disagree (and it looks like Bandan disagrees with himself
now :)).

>> In fact, I think shadow paging code should also emulate
>> this behavior if the gpa is out of range.
> 
> I disagree.

Same here.

> There is no "out of range" gpa. QEMU allocates enough memory, and it
> should be completely transparent to the guest. The fact that it silently
> breaks with nested paging if the host processor doesn't have enough
> address bits is a bug (maybe a hardware bug, maybe a KVM bug; I'm not
> sure, but I suspect it's a hardware bug).

It's a hardware bug, possibly due to some limitations in the physical
addresses that the TLB can store?  I guess KVM could detect the
situation and fall back to sloooow shadow paging.

> ... In any case, please understand that I'm not campaigning for this
> warning :) IIRC the warning was your (very welcome!) idea after I
> reported the problem; I'm just trying to ensure that the warning match
> the exact issue I encountered.

Yup.  I think the right thing to do would be to hide memory above the
limit.  A kernel patch to query the limit is definitely necessary, but
it needs to return e.g. 48 for shadow paging (otherwise you could just
use CPUID).  I'm not sure if the rest is possible with just QEMU, or it
requires help from the firmware.  Probably yes.

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/