Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API

[Avi Kivity]

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