On 03/21/2014 08:10 AM, Daniel Vetter wrote:
> On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark wrote:
Ie. an app that was using the gpu for something secure could
simply choose not to if the hw/driver could not guarantee that another
process using the gpu could not get access to the buf
On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark wrote:
>>> Ie. an app that was using the gpu for something secure could
>>> simply choose not to if the hw/driver could not guarantee that another
>>> process using the gpu could not get access to the buffers..
>>
>> IMO that should work fine, but we nee
On 03/20/2014 06:34 PM, Rob Clark wrote:
> On Thu, Mar 20, 2014 at 6:28 AM, Thomas Hellstrom
> wrote:
>> On 03/20/2014 10:43 AM, David Herrmann wrote:
>>> Hi
>>>
>>> On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
>>> wrote:
A user logs in to a system where DRI clients use render nodes.
On Thu, Mar 20, 2014 at 4:54 PM, Thomas Hellstrom
wrote:
> On 03/20/2014 06:34 PM, Rob Clark wrote:
>> On Thu, Mar 20, 2014 at 6:28 AM, Thomas Hellstrom
>> wrote:
>>> On 03/20/2014 10:43 AM, David Herrmann wrote:
Hi
On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
wrote:
On 03/20/2014 04:34 PM, Jerome Glisse wrote:
> On Thu, Mar 20, 2014 at 03:59:17PM +0100, Thomas Hellstrom wrote:
>> On 03/20/2014 03:36 PM, Jerome Glisse wrote:
>>> In any case this is not a render node issue and there is no reasons to force
>>> full VRAM eviction or anything like that.
>> This com
On 03/20/2014 03:36 PM, Jerome Glisse wrote:
>
> In any case this is not a render node issue and there is no reasons to force
> full VRAM eviction or anything like that.
This comment suggests you haven't read the discussion fully.
VRAM eviction was discussed in the context of legacy nodes.
This
On Thu, Mar 20, 2014 at 10:44 AM, Ilia Mirkin wrote:
> On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse 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
>>> > wrot
On Thu, Mar 20, 2014 at 6:28 AM, Thomas Hellstrom
wrote:
> On 03/20/2014 10:43 AM, David Herrmann wrote:
>> Hi
>>
>> On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
>> wrote:
>>> A user logs in to a system where DRI clients use render nodes. The
>>> system grants rw permission on the render n
On Thu, Mar 20, 2014 at 04:49:42PM +0100, Thomas Hellstrom wrote:
> On 03/20/2014 04:34 PM, Jerome Glisse wrote:
> > On Thu, Mar 20, 2014 at 03:59:17PM +0100, Thomas Hellstrom wrote:
> >> On 03/20/2014 03:36 PM, Jerome Glisse wrote:
> >>> In any case this is not a render node issue and there is no
On Thu, Mar 20, 2014 at 10:44:10AM -0400, Ilia Mirkin wrote:
> On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse 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
>
On Thu, Mar 20, 2014 at 03:59:17PM +0100, Thomas Hellstrom wrote:
> On 03/20/2014 03:36 PM, Jerome Glisse wrote:
> >
> > In any case this is not a render node issue and there is no reasons to force
> > full VRAM eviction or anything like that.
>
> This comment suggests you haven't read the discuss
On 03/20/2014 10:43 AM, David Herrmann wrote:
> Hi
>
> On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
> wrote:
>> A user logs in to a system where DRI clients use render nodes. The
>> system grants rw permission on the render nodes for the console user.
>> User starts editing a secret document
On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse 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
>> > wrote:
>> > Given that the legacy node is always around and _alw
Hi
On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
wrote:
> A user logs in to a system where DRI clients use render nodes. The
> system grants rw permission on the render nodes for the console user.
> User starts editing a secret document, starts some GPGPU structural FEM
> computations of th
On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote:
> On 03/20/2014 10:43 AM, David Herrmann wrote:
> > Hi
> >
> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
> > wrote:
> >> A user logs in to a system where DRI clients use render nodes. The
> >> system grants rw permission on
On 03/20/2014 10:05 AM, David Herrmann wrote:
> Hi Thomas
>
> On Thu, Mar 20, 2014 at 9:48 AM, Thomas Hellstrom
> wrote:
>> I'm merely trying to envision the situation where a distro wants to
>> create, for example an udev rule for the render nodes.
>>
>> How should the distro know that the imple
Hi Thomas
On Thu, Mar 20, 2014 at 9:48 AM, Thomas Hellstrom
wrote:
> I'm merely trying to envision the situation where a distro wants to
> create, for example an udev rule for the render nodes.
>
> How should the distro know that the implementation is not insecure?
>
> Historically drm has refus
On 03/20/2014 08:36 AM, David Herrmann wrote:
> Hi
>
> On Thu, Mar 20, 2014 at 7:43 AM, Thomas Hellstrom
> wrote:
>> On 03/17/2014 05:43 PM, David Herrmann wrote:
>>> We introduced render-nodes about 1/2 year ago and no problems showed up.
>>> Remove the drm_rnodes argument and enable them by def
Hi
On Thu, Mar 20, 2014 at 7:43 AM, Thomas Hellstrom
wrote:
> On 03/17/2014 05:43 PM, David Herrmann wrote:
>> We introduced render-nodes about 1/2 year ago and no problems showed up.
>> Remove the drm_rnodes argument and enable them by default now.
>
> So what about the malicious execbuf comman
Hi!
On 03/17/2014 05:43 PM, David Herrmann wrote:
> We introduced render-nodes about 1/2 year ago and no problems showed up.
> Remove the drm_rnodes argument and enable them by default now.
So what about the malicious execbuf command stream problem? Do we
require all drivers that enable
render-no
We introduced render-nodes about 1/2 year ago and no problems showed up.
Remove the drm_rnodes argument and enable them by default now.
Signed-off-by: David Herrmann
Acked-by: Daniel Vetter
---
v2:
- rebased on drm-next
drivers/gpu/drm/drm_stub.c | 7 +--
include/drm/drmP.h | 1 -
21 matches
Mail list logo
