From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 7/24] Understanding guest pointers to vmcs12 structures
Date: Mon, 02 Aug 2010 16:38:11 +0300
Message-ID: <4C56CA43.1000206@redhat.com>
References: <1276431753-nyh@il.ibm.com> <201006131226.o5DCQ95O012945@rice.haifa.ibm.com> <4C15ECD1.1070108@redhat.com> <20100802122550.GA3779@fermat.math.technion.ac.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org
To: "Nadav Har'El" <nyh@math.technion.ac.il>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:63724 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752873Ab0HBNiS (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 2 Aug 2010 09:38:18 -0400
In-Reply-To: <20100802122550.GA3779@fermat.math.technion.ac.il>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

  On 08/02/2010 03:25 PM, Nadav Har'El wrote:
>
>
>>> +	/* offfset = Base + [Index * Scale] + Displacement */
>>> +	addr = vmx_get_segment_base(vcpu, seg_reg);
>>> +	if (base_is_valid)
>>> +		addr += kvm_register_read(vcpu, base_reg);
>>> +	if (index_is_valid)
>>> +		addr += kvm_register_read(vcpu, index_reg)<<scaling;
>>> +	addr += exit_qualification; /* holds the displacement */
>>>
>> Do we need a segment limit and access rights check?
> You are absolutely right. The instructions we're emulating (VMREAD, VMWRITE,
> VMPTRLD, etc.) should throw a #GP in a bunch of segmentation errors, including
> segment limit, execute-only segments, non-canonical 64-bit addresses, and a
> bunch of other unlikely error cases.
>
> To achieve 100% accurate emulation in the error path, it will require quite
> a bit new code (here, and in many other places throughout the nested VMX code)
> that isn't necessary for running a correctly-written guest hypervisor (such
> as KVM or VMware). At worst, not accurately emulating the error path correctly
> might allow a broken L1 to do bad things to itself, but it doesn't allow it
> to do anything bad to L0 or other L1's.
>
> Would you accept that I'll add a TODO in the code here (and in similar cases)
> and leave perfecting the error path to a later path?

Given that the x86 emulator doesn't get this right, yes.  But please do 
document all the points where this is wrong.  Silent failure is the 
worst kind of failure, at least we'll know where to look.

-- 
error compiling committee.c: too many arguments to function