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: <09cb27f8-fa02-4b37-94de-1a4d86b9bdbd@redhat.com>
Date:   Mon, 18 May 2020 14:31:54 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Xiaoyao Li <xiaoyao.li@...el.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Cc:     jmattson@...gle.com,
        Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [PATCH] kvm: x86: Use KVM CPU capabilities to determine CR4
 reserved bits

On 18/05/20 06:52, Xiaoyao Li wrote:
> On 5/6/2020 5:44 PM, Paolo Bonzini wrote:
>> Using CPUID data can be useful for the processor compatibility
>> check, but that's it.  Using it to compute guest-reserved bits
>> can have both false positives (such as LA57 and UMIP which we
>> are already handling) and false negatives: 
> 
>> in particular, with
>> this patch we don't allow anymore a KVM guest to set CR4.PKE
>> when CR4.PKE is clear on the host.
> 
> A common question about whether a feature can be exposed to guest:
> 
> Given a feature, there is a CPUID bit to enumerate it, and a CR4 bit to
> turn it on/off. Whether the feature can be exposed to guest only depends
> on host CR4 setting? I.e., if CPUID bit is not cleared in cpu_data in
> host but host kernel doesn't set the corresponding CR4 bit to turn it
> on, we cannot expose the feature to guest. right?

It depends.  The most obvious case is that the host kernel doesn't use
CR4.PSE but we even use 4MB pages to emulate paging disabled mode when
the processor doesn't support unrestricted guests.

Basically, the question is whether we are able to save/restore any
processor state attached to the CR4 bit on vmexit/vmentry.  In this case
there is no PKRU field in the VMCS and the RDPKRU/WRPKRU instructions
require CR4.PKE=1; therefore, we cannot let the guest enable CR4.PKE
unless it's also enabled on the host.

Paolo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ