linux-kernel - Re: [PATCH] KVM: x86: restrict maximal physical address

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: <1cca4e4d-97f8-91b9-4e71-66f4a3c3cfb2@redhat.com>
Date:   Fri, 25 Nov 2016 17:43:10 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Radim Krčmář <rkrcmar@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH] KVM: x86: restrict maximal physical address

>> This check is correct.
>>
>> However, I wonder if there is any way for user space to query this property?
>
> Do you mean boot_cpu_data.x86_phys_bits?
> Userspace can execute CPUID instruction and read the value; QEMU does.

Thanks, good to know. I remember that on s390x we explicitly decided to 
query the maximum address from KVM (KVM_S390_VM_MEM_LIMIT_SIZE) for two 
reasons. One of them was "just because our CPU supports it doesn't mean 
KVM supports it". Just like with all CPU features.

However, this applies only for configuring hardware virtualization. The 
value that is exposed to the guest comes from the cpu model (with s390x 
cpu model support). So it will also not change during migration.

But if this will never be relevant for x86 (KVM will always support host 
x86_phys_bits), fine.

>
>> On s390x, there is a kvm capability to export this information to user
>> space. So QEMU can fail (e.g. migration) with a nice error message about
>> missing hardware support.
>>
>> (most probably we still want to block this case, as migration will seem to
>> work but than simply fail due to missing hardware support I guess). Maybe
>> there is also already a nice check in QEMU that I am not yet aware of :)
>
> This patch is bad.  It would break QEMU on all old machines, because
> QEMU sets 40 by default.

Not sure if rounding that value down (so it is at least consistent in 
KVM) makes sense (and documenting this behavior "may be rounded down"). 
And then implementing appropriate checks in QEMU (if not already present).

>
> Heh, QEMU doesn't check at all -- it even allows migration with
> "host-phys-bits" feature and will happily change phys-bits when
> migrating to another machine.
>

Either migrate that value (hmmm... ) or glue it to a command line 
parameter, so it won't change while migrating. E.g.

- cpu models (if this value was always the same for a CPU generation - 
no expert on x86 cpu models).
- "-cpu maxmem..." - could be a fit when thinking about "maximum VM size 
== max phys bits for our guest". But depends how this value is actually 
interpreted by guests.

-- 

David