From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKp5D-0002iP-LG for qemu-devel@nongnu.org; Mon, 31 Oct 2011 06:27:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKp5C-0002R4-H7 for qemu-devel@nongnu.org; Mon, 31 Oct 2011 06:27:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKp5C-0002Qs-45 for qemu-devel@nongnu.org; Mon, 31 Oct 2011 06:27:10 -0400 Message-ID: <4EAE77F8.2050008@redhat.com> Date: Mon, 31 Oct 2011 12:27:04 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1319983368-21801-1-git-send-email-avi@redhat.com> <4EAD5B6B.204@codemonkey.ws> <4EAD5D07.6060004@redhat.com> <20111031003658.GC9698@truffala.fritz.box> In-Reply-To: <20111031003658.GC9698@truffala.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori , qemu-devel@nongnu.org, Blue Swirl On 10/31/2011 02:36 AM, David Gibson wrote: > > > > There is no direct use of signed arithmetic in the API (just in the > > implementation). Aliases can cause a region to move in either the > > positive or negative direction, and this requires either signed > > arithmetic or special casing the two directions. > > You keep saying we need signed arithmetic for this, but it's not > really true. *If* you see aliases as shifting the entire aliases > address space w.r.t., then just allowing a window to show through, you > get negative offsets, yes, but that's by no means the only way t think > about it. Obviously it's not the only way. We could insert checks for the direction, and for overflow/underflow. But I am looking for the most reliable way to prevent similar issues from popping up. There have been at least three bugs in this area. If we can use a heavy hammer here, it is worthwhile IMO. Sorry for being a little trollish, but I much prefer replacing function calls with infix operators, than getting a CVE for some overflow. > It's basically one spot - the alias handling in render_memory_region() > - that generates a negative start intermediate. I'm convinced it's > pretty straightforward to remove this - making a patch for it just > hasn't bubbled to the top of my priority queue, though. We keep adding, subtracting, and comparing stuff everywhere. I am fairly certain that you are right and there are no other trouble spot, but I am not absolutely sure, and I would like to be. > > Signed arithmetic is not the only motivation - overflow is another. > > Nothing prevents a user from placing a 64-bit 4k BAR at address > > ffff_ffff_ffff_f000; we could move to base/limit representation, but > > that will likely cause its own bugs. Finally, we should be able to > > represent both a 0-sized region and a 2^64 sized region. > > Note that an (inclusive) start/end representation also cannot > represent a 0 sized region. Right. In theory we shouldn't generate zero sized regions, but can we trust call device code not to do that? Also, start/end or off-by-one size are easy to get wrong since C programmers assume half-inclusive regions. -- error compiling committee.c: too many arguments to function