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]
Date:	Tue, 5 May 2015 20:48:14 +0200
From:	Radim Krčmář <rkrcmar@...hat.com>
To:	Bandan Das <bsd@...hat.com>
Cc:	Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, guangrong.xiao@...ux.intel.com,
	Yang Zhang <yang.z.zhang@...el.com>, wanpeng.li@...ux.intel.com
Subject: Re: [PATCH 08/13] KVM: x86: stubs for SMM support

2015-05-05 14:38-0400, Bandan Das:
> Radim Krčmář <rkrcmar@...hat.com> writes:
> ...
> >> +		break;
> >
> > (I'm not sure if this is supported if IA32_VMX_BASIC[49] = 0.
> >  34.15.6.4 Saving Guest State
> >    The SMM-transfer monitor (STM) can also discover the current value of
> >    the SMBASE register by using the RDMSR
> >
> >  but it's not possible to get into STM without having a support for it
> >  noted in IA32_VMX_BASIC[49] and more magic we also don't emulate to
> >  actually enable it.)
> 
> Where does it mention IA32_VMX_BASIC[49] ? I only see "IA32_VMX_MISC[15] should be 1"
> in 34.15.6.4. Anyway, I think we should do what the spec says..

The relevant part is "SMM-transfer monitor (STM) can" -- you can't be
STM without IA32_VMX_MISC[15] and a bunch of other stuff.

Testing on real hardware would be the best way to tell ...
(Till we know, I'm okay with anything.)

> >> @@ -7208,6 +7240,8 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu)
> >>  	vcpu->arch.regs_avail = ~0;
> >>  	vcpu->arch.regs_dirty = ~0;
> >>  
> >> +	vcpu->arch.smbase = 0x30000;
> >
> > It's not reset on INIT, only on RESET.  (34.11 SMBASE RELOCATION)
> I remember mentioning it elsewhere - IMO kvm_vcpu_reset() and kvm_vcpu_init()
> should really be two different interfaces. I don't mean code duplication - one
> can just call the other but different names will be of some help when it comes
> to the million places where the spec mentions INIT and RESET have different
> behavior.

Agreed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ