Re: [PATCH 00/03] Preventing zero GPU virtual address allocation

[Dave Gordon <david.s.gordon@intel.com>]

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@lists.freedesktop.org
> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx