linux-kernel - RE: [PATCH 9/9] KVM: x86: Disable intercept for Intel processor trace MSRs

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] [day] [month] [year] [list]

Date:   Wed, 18 Oct 2017 07:15:00 +0000
From:   "Kang, Luwei" <luwei.kang@...el.com>
To:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC:     "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "rkrcmar@...hat.com" <rkrcmar@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Chao Peng <chao.p.peng@...ux.intel.com>
Subject: RE: [PATCH 9/9] KVM: x86: Disable intercept for Intel processor
 trace MSRs

> On October 16, 2017 8:14:11 AM EDT, Luwei Kang <luwei.kang@...el.com> wrote:
> >From: Chao Peng <chao.p.peng@...ux.intel.com>
> >
> >Trap for Intel processor trace is none sense. Pass through to guest
> >directly.
> 
> 
> And none of those MSRs can be subverted by the guest? That is none of these should be filtered / audited first?
> 
   Currently, I think it is no necessary. For example, host context(MSRs) would be saved and guest context would be restored before VM-entry in host-guest mode. And IA32_RTIT_CTL will be written with the value of the associated Guest State field of the VMCS on VM entry. I am not very clear what your point. Could you make a specific scenes?

Thanks,
Luwei Kang

> 
> >
> >Signed-off-by: Chao Peng <chao.p.peng@...ux.intel.com>
> >Signed-off-by: Luwei Kang <luwei.kang@...el.com>
> >---
> > arch/x86/kvm/vmx.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> >diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
> >3c9ce3e..58606ce 100644
> >--- a/arch/x86/kvm/vmx.c
> >+++ b/arch/x86/kvm/vmx.c
> >@@ -7076,6 +7076,20 @@ static __init int hardware_setup(void)
> > 	if (pt_mode == PT_MODE_GUEST)
> > 		pt_register_virt_ops(&pt_virt_ops);
> >
> >+	if (pt_mode == PT_MODE_GUEST || pt_mode == PT_MODE_HOST_GUEST) {
> >+		u32 i, eax, ebx, ecx, edx;
> >+
> >+		cpuid_count(0x14, 1, &eax, &ebx, &ecx, &edx);
> >+		vmx_disable_intercept_for_msr(MSR_IA32_RTIT_CTL, false);
> >+		vmx_disable_intercept_for_msr(MSR_IA32_RTIT_STATUS, false);
> >+		vmx_disable_intercept_for_msr(MSR_IA32_RTIT_OUTPUT_BASE, false);
> >+		vmx_disable_intercept_for_msr(MSR_IA32_RTIT_OUTPUT_MASK, false);
> >+		vmx_disable_intercept_for_msr(MSR_IA32_RTIT_CR3_MATCH, false);
> >+		for (i = 0; i < (eax & 0x7); i++)
> >+			vmx_disable_intercept_for_msr(MSR_IA32_RTIT_ADDR0_A + i,
> >+									false);
> >+	}
> >+
> > 	return alloc_kvm_area();
> >
> > out:
> 
> 
> Thanks!