On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse <j.glisse at gmail.com> wrote: > On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote: >> On 03/20/2014 10:43 AM, David Herrmann wrote: >> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom >> > <thellstrom at vmware.com> wrote: >> > Given that the legacy node is always around and _always_ has these >> > races, why should we prevent render-nodes from appearing just because >> > the _driver_ is racy? I mean, there is no gain in that.. if it opens a >> > new race, as you assumed, then yes, we should avoid it. But at least >> > for all drivers supporting render-nodes so far, they either are >> > entirely safe or the just described races exist on both nodes. >> >> My suggestion is actually not to prevent render nodes from appearing, >> but rather that we should restrict them to drivers with command stream >> verification and / or per process virtual memory, and I also think we >> should plug the above races on legacy nodes. That way legacy nodes would >> use the old "master owns it all" model, while render nodes could allow >> multiple users at the same time. > > FYI both radeon and nouveau (last time i check) can not be abuse to access > random VRAM or buffer bind by another process (except if the buffer is share > of course).
I'm not aware of any restrictions in nouveau that would prevent you from accessing any vram... there are a number of copy engines accessible that would allow you to copy one region to another, and I'm not aware of code to validate pushbuf contents (it would have to parse the pushbuf and know which methods store source/destination addresses). You could probably get creative and use that to overwrite the MMU tables, to then gain the ability to read/write any part of system memory... but perhaps the engines won't allow you to do that, not sure. (Or perhaps the PDE isn't mapped into VRAM. Again, not sure.) -ilia
