From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sasha Levin <sasha.levin@oracle.com>
Subject: Re: sanitizing kvmtool
Date: Sun, 25 Oct 2015 15:06:44 -0400
Message-ID: <562D2844.1090106@oracle.com>
References: <CACT4Y+ZX71GiGzDrk4hSYVrWdoZ1eoPBdUYR_z4jY-mgOCZCuA@mail.gmail.com>
 <5622583D.2060006@oracle.com>
 <CACT4Y+YyoukPjTqb+1RD2HKm2auO0CbHTT7Ov7FQm43MWtmLYw@mail.gmail.com>
 <5624FBF4.20201@oracle.com>
 <CACT4Y+ZwLTrUBEC6-EmEnvdtKZcYsdhwEjq-yLztqiZo-ejOAg@mail.gmail.com>
 <5624FFC7.2010301@oracle.com>
 <CACT4Y+b_mF+CcY3VAPPH6w+YEkd3UaKXfjK6b5CHYgDy2TGnCg@mail.gmail.com>
 <5625075F.4010508@oracle.com>
 <CACT4Y+Yr7+EqM2L_8AALYnuhsBvwr_r6BdTXL_PStK+V-Ve7CQ@mail.gmail.com>
 <5627C659.6030000@oracle.com> <562CF2FE.3070308@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: Sasha Levin <levinsasha928@gmail.com>,
	Pekka Enberg <penberg@kernel.org>,
	Asias He <asias.hejun@gmail.com>, penberg@cs.helsinki.fi,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Will Deacon <will.deacon@arm.com>, andre.przywara@arm.com,
	matt@ozlabs.org, laijs@cn.fujitsu.com,
	Michael Ellerman <michael@ellerman.id.au>,
	Prasad Joshi <prasadjoshi124@gmail.com>, marc.zyngier@arm.com,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	mingo@elte.hu, gorcunov@openvz.org,
	andreas.herrmann@caviumnetworks.com, kvm@vger.kernel.org,
	Kostya Serebryany <kcc@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Alexey Samsonov <samsonov@google.com>,
	Alexander Potapenko <glider@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Dmitry Vyukov <dvyukov@google.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from userp1040.oracle.com ([156.151.31.81]:40156 "EHLO
	userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751698AbbJYTNz (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 25 Oct 2015 15:13:55 -0400
In-Reply-To: <562CF2FE.3070308@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 10/25/2015 11:19 AM, Paolo Bonzini wrote:
> 
> 
> On 21/10/2015 19:07, Sasha Levin wrote:
>> On 10/19/2015 11:15 AM, Dmitry Vyukov wrote:
>>> But still: if result of a racy read is passed to guest, that can leak
>>> arbitrary host data into guest.
>>
>> I see what you're saying.
> 
> I don't... how can it leak arbitrary host data?  The memcpy cannot write
> out of bounds.

The issue I had in mind (simplified) is:

vcpu1				vcpu2
----------------------------------------
guest writes idx
check if idx is valid
				guest writes new idx
access (guest mem + idx)


So I'm not sure if cover both the locking, and potential compiler tricks
sufficiently enough to prevent that scenario.


Thanks,
Sasha