linux-kernel - Re: [PATCH 2/3] Refactor hypercall infrastructure

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: <1188235750.6364.8.camel@squirrel>
Date:	Mon, 27 Aug 2007 12:29:10 -0500
From:	Anthony Liguori <aliguori@...ibm.com>
To:	Avi Kivity <avi@...ranet.com>
Cc:	kvm-devel@...ts.sourceforge.net, Ingo Molnar <mingo@...e.hu>,
	Dor Laor <dor.laor@...ranet.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] Refactor hypercall infrastructure


On Mon, 2007-08-27 at 19:06 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> >  void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> >  {
> >  	int i;
> > @@ -1632,6 +1575,12 @@ void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> >  	vcpu->regs[VCPU_REGS_RBX] = 0;
> >  	vcpu->regs[VCPU_REGS_RCX] = 0;
> >  	vcpu->regs[VCPU_REGS_RDX] = 0;
> > +
> > +	if ((function & 0xFFFF0000) == 0x40000000) {
> > +		emulate_paravirt_cpuid(vcpu, function);
> > +		goto out;
> > +	}
> > +
> >   
> 
> Hmm.  Suppose we expose kvm capabilities to host userspace instead, and 
> let the host userspace decide which features to expose to the guest via 
> the regular cpuid emulation?  That allows the qemu command line to 
> control the feature set.

That's a little awkward with something like NPT.  Some CPUID features
should be masked by the availability of NPT support in hardware and
whether kernelspace supports NPT.  To set these feature bits in
userspace, you would have to query kernelspace anyway.

It would be nice to be consistent with the other cpuid flags though.
There is somewhat of a similar issue with migration here.  If we have an
initial set of PV features and down the road, add more, it may be
desirable to enable those features depending on what your network looks
like.  Yeah, I think I agree that userspace is the right place to set
these bits.

> >  
> > +static int ud_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
> > +{
> > +	int er;
> > +	
> > +	er = emulate_instruction(&svm->vcpu, kvm_run, 0, 0);
> > +
> > +	/* we should only succeed here in the case of hypercalls which
> > +	   cannot generate an MMIO event.  MMIO means that the emulator
> > +	   is mistakenly allowing an instruction that should generate
> > +	   a UD fault so it's a bug. */
> > +	BUG_ON(er == EMULATE_DO_MMIO);
> >   
> 
> It's a guest-triggerable bug; one vcpu can be issuing ud2-in-a-loop 
> while the other replaces the instruction with something that does mmio.

Good catch!  I'll update.

> > +
> > +#define KVM_ENOSYS		ENOSYS
> >   
> 
> A real number (well, an integer, not a real) here please.  I know that 
> ENOSYS isn't going to change soon, but this file defines the kvm abi and 
> I'd like it to be as independent as possible.
> 
> Let's start it at 1000 so that spurious "return 1"s or "return -1"s 
> don't get translated into valid error numbers.

Okay.

> I really like the simplification to the guest/host interface that this 
> patch brings.

Thanks.

Regards,

Anthony Liguori

-
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/