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
ntel-gfx
> > Subject: Re: [Intel-gfx] [PATCH 00/03] Preventing zero GPU virtual address
> > allocation
> >
> > On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> > > On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > > > On W
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 thr
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Daniel Vetter
> Sent: Thursday, May 21, 2015 12:01 AM
> To: Chris Wilson; intel-gfx
> Subject: Re: [Intel-gfx] [PATCH 00/03] Preventing zero GPU virtual address
> a
On Thu, May 21, 2015 at 12:38:45PM +0300, David Weinehall wrote:
> On Thu, May 21, 2015 at 09:43:00AM +0100, Chris Wilson wrote:
> > On Thu, May 21, 2015 at 11:08:42AM +0300, David Weinehall wrote:
> [snip]
> > > Not exactly sure what you suggest here?
> >
> > That you have an unmitigated security
On Thu, May 21, 2015 at 11:44:11AM +0200, Daniel Vetter wrote:
> On Thu, May 21, 2015 at 09:43:00AM +0100, Chris Wilson wrote:
> > On Thu, May 21, 2015 at 11:08:42AM +0300, David Weinehall wrote:
> > > On Wed, May 20, 2015 at 05:10:58PM +0100, Chris Wilson wrote:
> > > > On Wed, May 20, 2015 at 06:
On Thu, May 21, 2015 at 09:43:00AM +0100, Chris Wilson wrote:
> On Thu, May 21, 2015 at 11:08:42AM +0300, David Weinehall wrote:
> > On Wed, May 20, 2015 at 05:10:58PM +0100, Chris Wilson wrote:
> > > On Wed, May 20, 2015 at 06:00:43PM +0200, Daniel Vetter wrote:
> > > > On Wed, May 20, 2015 at 03:
On Thu, May 21, 2015 at 09:43:00AM +0100, Chris Wilson wrote:
> On Thu, May 21, 2015 at 11:08:42AM +0300, David Weinehall wrote:
[snip]
> > Not exactly sure what you suggest here?
>
> That you have an unmitigated security hole in your design.
No, I meant what you suggest as a remedy.
Kind regar
On Thu, May 21, 2015 at 11:08:42AM +0300, David Weinehall wrote:
> On Wed, May 20, 2015 at 05:10:58PM +0100, Chris Wilson wrote:
> > On Wed, May 20, 2015 at 06:00:43PM +0200, Daniel Vetter wrote:
> > > On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> > > > On Wed, May 20, 2015 at 03:
On Wed, May 20, 2015 at 05:10:58PM +0100, Chris Wilson wrote:
> On Wed, May 20, 2015 at 06:00:43PM +0200, Daniel Vetter wrote:
> > On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> > > On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > > > On Wed, May 20, 2015 at 04:54:
On Wed, May 20, 2015 at 06:00:43PM +0200, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> > On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > > On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > > > This patch series (one patc
On Wed, May 20, 2015 at 06:00:43PM +0200, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> > On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > > On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > > > This patch series (one patc
On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > > This patch series (one patch each for libdrm, the kernel, and beignet)
> > > aims to provide a mea
On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > This patch series (one patch each for libdrm, the kernel, and beignet)
> > aims to provide a means to add a context-specific means to prevent
> > a mapping to GPU vir
On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> This patch series (one patch each for libdrm, the kernel, and beignet)
> aims to provide a means to add a context-specific means to prevent
> a mapping to GPU virtual address zero. This is needed at least by
> Beignet (possibly in
This patch series (one patch each for libdrm, the kernel, and beignet)
aims to provide a means to add a context-specific means to prevent
a mapping to GPU virtual address zero. This is needed at least by
Beignet (possibly in other use-cases too, though I don't know of any
other) to allow use of ad
16 matches
Mail list logo
