On 27/05/15 10:17, David Weinehall wrote: > On Thu, May 21, 2015 at 10:50:37AM +0100, Chris Wilson wrote: >> It also have just as much risk as reporting EBUSY due to the CL client >> trying to use a pinned buffer. >> >> However, it is a security hole because the same process can arrange to >> have whatever buffer it likes at 0 then access it through the CL kernel. > > I don't really understand what you're getting at here. While it's true > that userland can have whatever buffer it likes at 0, there's nothing in > the current code that prevents this in the first place, so I cannot see > how this could be a regression. This feature isn't intended as a > security measure; its sole purpose is to help implementations that > assume 0 = failure to avoid weird bugs. > > Regards: David > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx FWIW, GuC submission will require any object that has to be accessed by the GuC itself to be mapped at an address that is *not* in the lowest portion of the address range [0..GUC_WOPCM_SIZE_VALUE), currently 512K. This mostly applies to GuC-specific objects such as the GuC client and log objects, but also to 'intel_context' objects, as the GuC needs to read and/or update certain parts of the saved context. The GuC doesn't access batchbuffer objects, or any user-defined data buffers that they operate on. .Dave. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
