> > I'm working on changing DRM such that the master node does not need to > run as root and instead can be a normal user. Because of this I can't > leave AddMap the way it is. The security hole is that a normal user > could allocate multi/large shared areas, consume all of kernel VM > space and crash the kernel. > > Second choice would be to make a new map type, DRM_VSHM. The specific > driver would initmap the needed space at load time. The code > implementing it would be identical to DRM_SHM, you just need another > map type defined so that you can tell them apart. This scheme does not > require anyone to be root and does not have a kernel DOS hole.
At the moment I'm having similiar issues with Radeon XvMC it initially will require root as I'm not sure how to submit the command streams outside of indirect buffers which are a root only thing... I'd also like to have a separate sarea for storing this stuff, I don't care for V4L, XvMC is what is supported out there now and NVIDIA provide it and don't provide v4l... also there is no need for this to be in-kernel, its only a DMA stream and a sync point... I think we should have a root master process to be honest, it can run from init and also have it do any mode setting type business... it can operate like the DDXes do today, except it won't do any mode settting or anything until prompted by the user app... I just feel in-kernel is going to become bloated with what is the DDX _dri.x file now ... just because MS put lots of things in kernel doesn't mean we have to... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
