On 6/21/05, Thomas Hellström <[EMAIL PROTECTED]> wrote: > > On 6/21/05, Thomas Hellström <[EMAIL PROTECTED]> wrote: > >> While this will probably work today it will leave little room for future > >> applications of DRI. > > > > Can XvMC needs be handled via the V4L interface? I would expect an > > some point relevant V4L drivers will also get integrated into the > > DRM/fbdev composite driver. > > > > I haven't actually looked into the V4L interface, but in VIA's own > solution they end up with a proprietary decoder interface that uses their > V4L kernel driver and needs to be run as root. Imagine a vulnerable media > player that accesses remote URLs and needs to be run as root.
There are other V4L drivers that don't need to run as root. I would suspect that VIA didn't implement something correctly and triggered the need to be root. > i810 XvMC (from which the unichrome driver initially was derived) is also > using drm, but I think nobody is really using it. > > > Is 8K of memory not enough for VIA? Or is the problem that there are > > three structures being placed in sarea: DRM, via DRM, via XvMC. With > > three structures you can't tell the offset to load the third one at. > > Could the three structures problem be fixed by just combining the > > structure defs for via DRM and via XvMC? > > It is sufficient today. My point is that we'll be restricting the > generality of drm. > > After som continous development of OpenGL and XvMC the private part of the > sarea would look like > > ------------- > OpenGL stuff > ------------- > XvMC stuff > ------------- > XvmC lock array > ------------- > More OpenGL stuff > ------------- > Continuation of XvMC lock array > _____________ > > Even More OpenGL stuff > ______________ > > and therefore IMHO the cleanest solution is to have an XvMC private sarea > of it's own, and I'd like to be able to reserve shared memory pages for > authenticated clients only, and I believe the DRM is the right place for > this. 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. My first choice would be to push these locks into the driver's V4L interface. 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. However, the V4L interface is directly manipulable by the user - it does not have a driver library driving it. I don't see how you are going to be able to build V4L if the locks are managed through DRM. -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- 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_idt77&alloc_id492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
