On 13.03.2010 03:20, Corbin Simpson wrote: > On Fri, Mar 12, 2010 at 5:20 PM, Jose Fonseca <jfons...@vmware.com> > wrote: >> Because if you have a huge vertex buffer and you only draw few >> indices you may choose to upload to VRAM only the vertices actually >> referred. Applications do this. And for certain hardware uploads >> are very slow, so it is an worthwhile optimization. > > Sure, not saying that it's not. > >> Efficiency is just or more important goal than principles like >> "state tracker should sanitize". There is hardware that can handle >> buffers with out of bounds indices without crashing. The APIs we >> expose also make the same promise. In such situation the >> shortcomings on one hardware should not be taxed to all. > > Oh, it's not a hardware limitation. If the vert and elt indices > aren't clamped, then an attacker could theoretically retrieve bits of > VRAM/GTT he shouldn't be allowed to peek at. In order to prevent > this, the radeon kernel module requires that I set those clamps, and > that they be within the bounds of the various buffers being used for > rendering. I wouldn't call it a shortcoming so much as a security > consideration. > > I've pushed a revert of the original patch, and an r300g patch that, > while not perfect, covers the common case that Wine hits.
I think I don't really understand that (and the fix you did for r300g). Why can't you simply clamp the maxIndex to the minimum of the submitted maxIndex and the vertex buffer max index? Now you have this: maxIndex = MIN3(maxIndex, r300->vertex_buffer_max_index, count - minIndex); This is then used to set the hardware max index clamp. However, for example count could be 3, min index 0, but the actual vertices fetched 0, 15, 30 - as long as the vertex buffers are large enough this is perfectly legal, but as far as I can tell your patch would force the hardware to just fetch the 0th vertex (3 times). Count really tells you nothing at all about the index range (would also be legal to have huge count but very small valid index range if you fetch same vertices repeatedly). Roland ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
