On Fri, Feb 08, 2019 at 09:41:10AM -0800, Jim Mattson wrote:
> According to volume 3 of the APM, appendix E, CPUID
> Fn8000_001A_E[D,C,B]X are reserved. Since we have no way of knowing
> what these fields will be used for, they should not be whitelisted.
>
> Fixes: 24c82e576b78 ("KVM: Sanitize cpuid")
> Signed-off-by: Jim Mattson <jmattson@xxxxxxxxxx>
> Reviewed-by: Peter Shier <pshier@xxxxxxxxxx>
Reviewed-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
> ---
> arch/x86/kvm/cpuid.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index bbffa6c54697..183f40cd3362 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -696,6 +696,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
> entry->ecx = entry->edx = 0;
> break;
> case 0x8000001a:
> + entry->ebx = entry->ecx = entry->edx = 0;
Mostly of out of curiosity, but also a bit of devil's advocate, where
do we draw the line in terms of handling reserved fields/bits? For
example, Fn8000_001A_EAX bits 31:3 appear to be reserved, should we
clear them as well?
I get that we want to find a balance between having to update KVM every
time a new bit is defined and exposing unknown data to VMs, just seems
like we're making a somewhat arbitrary decision as to how much we're
willing to trust hardware vendors to not do weird/stupid things.
Switching gears, leaf 0x9 should also get this treatment.
> break;
> case 0x8000001d:
> break;
> --
> 2.20.1.791.gb4d0f1c61a-goog
>
