Michel Dänzer wrote:
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote:
Alan Cox wrote:
The log design presents numerous opportunities for rogue processes to do
bad things. At some level, that's inherent in the nature of direct
rendering. If you don't trust the processes, don't enable direct rendering.
Thats a very poor answer to the problem. DRI needs to be moving towards
being more secure, and building in assumptions of insecurity just makes
it worse when better cards are used.
Security is more than just the memory manager. To enforce video memory
protection, we'd have to audit the code and add memory protection to
existing drm modules. That is quite a lot of work, and requires
extensive knowledge of each card. So I don't think it's worth the
trouble with current cards.
I still think 'we may not succeed 100%, at least in the short term' is a
bad excuse for not trying, but that seems to be mostly me.
Its critical that the kernel knows what memory on the video space is
being used for command queue and protects it. From the description of
the SiS turboqueue I suspect you may be able to root a sis video box
that way but without full docs I can't tell.
Protecting a statically assigned command queue is one thing (something
similar to what's currently done on radeon would be sufficient),
protecting dynamically allocated video memory is another.
If the DRM operated on memory objects instead of with offsets directly,
it should be trivial: It only has to check that the caller has
permission to access the memory objects involved.
Other stuff like textures is merely annoyance value. Knowing who owned a
block for cleanup matters and the DRI lock/mem handling on some chips
already handles it. Its also cheap because you only have to track some
kind of texture handles not pages for cleanup.
Actually, the long term idea is to have both dri and ddx allocate from
the same memory pool. So we can't rely on texture handles for that.
May I ask why we can't, assuming this is done via EXA callbacks into the
DDX driver that use the shared memory manager?
When thinking about the memory manager, there's far more uses for
graphics memory than just textures:
The framebuffer (including color, Z, stencil, etc)
Pbuffers
Renderbuffer/Framebuffer objects
Pixel/Vertex buffer objects
Texture images
OpenGL miscellaneous (e.g. vertex/fragment programs)
X server miscellaneous (pixmap cache, etc)
So, just constructing a memory manager around texture handles seems
short-sighted.
Furthermore, different memory objects may have different
requirements/properties:
1. The location of the object in memory (perhaps the framebuffer has
to be at the start of memory).
2. Particular byte/word alignments
3. Can we use VRAM and/or AGP memory for the object?
4. Can the object can be lost asynchronously (Pbuffers)?
... plus others I'm surely forgetting or not aware of.
Bearing in mind that I'm probably among the least knowledgeable of the
Linux kernel among those here, here are my thoughts on the subject.
1. I'd like an allocator that can be used outside/independent of the
Xserver. Specifically, an allocator that EGL and EGL drivers can use.
2. There needs to be a way to share memory blocks between processes.
3. Blocks should get automatically freed when the process that creates
them terminates (unless they're shared w/ another process, perhaps).
4. Blocks should probably be named by an opaque handle. That might
help to support some kind of simple security model plus allow memory
blocks to be relocated, etc.
5. Blocks would have to be locked in some manner while they were
actually in use. We don't want to move a texture image while it's
being used.
6. There should be a mechanism for the allocator to notify a process
when one of its blocks is moved/ejected/changed.
7. The public interface to the allocator should be OS-independent so
that it can be implemented on Linux, FreeBSD, etc. Perhaps the public
API would be exposed through a library which wraps an OS-specific
interface based on ioctls, etc.
8. Try to keep both the interface and implementation as simple as
possible with an eye toward future extensions.
I think it would be worthwhile to start a specification document for
this project (or perhaps a wiki page) where the requirements, issues
and proposed interface could be recorded. Any volunteers?
-Brian
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
