Re: DRM and permanent SAREA

[Thomas Hellström]

Jon Smirl wrote: On 6/22/05, Thomas Hellström <[EMAIL PROTECTED]> wrote: Hi. Jon Smirl wrote: On 6/21/05, Jon Smirl <[EMAIL PROTECTED]> wrote: 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. So back to the original topic. I'll add a new map type DRM_VSHM. When initializing, the chip specific driver needs to do something like this: if ((ret = drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0))) goto err_g1; The map needs to be created in the driver. Opening it up to a normal user is a DOS hole where the kernel can be run out of memory. Use getmap to find the map from user space. Really what is needed is a shmget thingy that returns a handle to a map which is only mappable by authorized clients. If I understand your solution above, there would be only one extra shared map, and it needs to be looked up from user space, which would be equivalent to allocating a twice as large primary sarea and reserve half of it to applications other than OpenGL, and is hence not needed. The are two maps: 1) the normal sarea, it is always there and it gets allocated by the drm core. Used by core and drive GL like the current code. 2) an optional second shared memory. It is allocated by the card specific driver which also controls its size. Used for additional driver specifc features like XvMC. The second map will always be available in the driver if it has been allocated. If user space wants to use the second map it has to get its address; getmap is used to find the address. Both the first and second maps follow the authorization rules. Why not have a thing similar to drmAddMap doing this (but not root-only)? With proper checks I can't see why that would be a bigger security hole than shmget? To achieve the best security AddMap in its current form needs to be eliminated. All maps would be created by the drivers, not user space. For backwards compatibility AddMap is kept and it returns the matching permanent map instead of creating a new one. Yes, I figured both these items out reading your previous mail, but you didn't give an answer to any of my questions. 1) How is allocating a second fixed sarea different from splitting the first SAREA in two parts? The problem is not space but future expandability and generality. 2) How is a non-root drmAddMap for shared memory a bigger security risc than shmget? I understand why SAREA containing the lock needs to be permanent, but not subsequent ones. Why can't they be created on demand by the master? /Thomas /Thomas