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