Intel KVM Virtualization Hit By Vulnerability Over Unfinished Code

[phoronix]

Phoronix: Intel KVM Virtualization Hit By Vulnerability Over Unfinished Code

At least not another hardware vulnerability, but CVE-2020-2732 appears to stem from unfinished code within the Intel VMX code for the Linux kernel's Kernel-based Virtual Machine (KVM) support...

http://www.phoronix.com/scan.php?pag...-CVE-2020-2732

[lectrode]

...this vulnerability stems form the fact this function...

[tildearrow]

...this vulnerability stems form the fact this function...

Come on...







Intel please stop...
By 2025 Intel will stop being Swiss cheese and instead be no cheese at all...!

[andrewjoy]

More than anything this shows the culture around security at Intel. And its not good.

[nanonyme]

Seems like a good example why you shouldn't go "ship it" with codebase that has stubbed out todo later code. The reality is no one will implement that unless there's a security incident or it becomes mandatory for some future feature.

[NotMine999]

Is Intel culture turning into "if it compiles, SHIP IT!" like other major software/OS development houses?

[nuetzel]

Is Intel culture turning into "if it compiles, SHIP IT!" like other major software/OS development houses?

...turning into...?

Isn't it called Wintel already?!

[zexelon]

I thought Torvalds checks every line of Linux code personally... clearly he is slipping

[theszym]

Well.... git has a history if you dont know....

# git blame v5.5 -L 7139,+21 -e -- arch/x86/kvm/vmx/vmx.c
Blaming lines: 0% (21/8023), done.
8a76d7f25f8f2 arch/x86/kvm/vmx.c (<joerg.roedel@amd.com> 2011-04-04 12:39:27 +0200 7139) static int vmx_check_intercept(struct kvm_vcpu *vcpu,
8a76d7f25f8f2 arch/x86/kvm/vmx.c (<joerg.roedel@amd.com> 2011-04-04 12:39:27 +0200 7140) struct x86_instruction_info *info,
8a76d7f25f8f2 arch/x86/kvm/vmx.c (<joerg.roedel@amd.com> 2011-04-04 12:39:27 +0200 7141) enum x86_intercept_stage stage)
8a76d7f25f8f2 arch/x86/kvm/vmx.c (<joerg.roedel@amd.com> 2011-04-04 12:39:27 +0200 7142) {
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7143) struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7144) struct x86_emulate_ctxt *ctxt = &vcpu->arch.emulate_ctxt;
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7145)
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7146) /*
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7147) * RDPID causes #UD if disabled through secondary execution controls.
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7148) * Because it is marked as EmulateOnUD, we need to intercept it here.
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7149) */
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7150) if (info->intercept == x86_intercept_rdtscp &&
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7151) !nested_cpu_has2(vmcs12, SECONDARY_EXEC_RDTSCP)) {
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7152) ctxt->exception.vector = UD_VECTOR;
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7153) ctxt->exception.error_code_valid = false;
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7154) return X86EMUL_PROPAGATE_FAULT;
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7155) }
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7156)
fb6d4d340e053 arch/x86/kvm/vmx.c (<pbonzini@redhat.com> 2016-07-12 11:04:26 +0200 7157) /* TODO: check more intercepts... */
8a76d7f25f8f2 arch/x86/kvm/vmx.c (<joerg.roedel@amd.com> 2011-04-04 12:39:27 +0200 7158) return X86EMUL_CONTINUE;
8a76d7f25f8f2 arch/x86/kvm/vmx.c (<joerg.roedel@amd.com> 2011-04-04 12:39:27 +0200 7159) }