Re: [rfc] VIA dri and security.

[Thomas Hellström]

Hi, Dave. Dave Airlie wrote: AllowInsecureDRI is less secure than forcing users to run things as root or fix the code. And we want that code in kernel and causing pain in order to make people fix it 8) I'm really with Keiths don't let them do anything until someone fixes it .. makes life easier.. I don't think having in the mainline will force people to fix it any quicker, anyone capable of fixing it is probably on this list, (and in the via case on the unichrome one ..).. The problem is that if we decide to disable it altogether, that means XvMC won't work, OpenGL won't work and all our users will instead use VIA's drivers which probably suffer from the exact same vulnerability but they don't care. Nothing will get fixed up. Also, the people on the unichrome site including me are totally lost when it comes to 3D, and you'll need a quite detailed documentation to fix things up. I guess the 3D command verification will be quite some work. The best would be to convince VIA that they would very much benefit from having a secure DRI, and have them do it in an open source framework. I've just thought of another issue with the validation (and I haven't reviewed the via code throughly...) but for the mach64 the problem was that after the validation the buffers were still mapped into the user application so it could modify them after validation if it was sufficently sneaky enough... for the mach64 the idea was to allocate a pool of private buffers using pci interfaces and use those to pass command streams after verification.. the user app wouldn't be able to map these... The design by Erdi means that the AGP command buffer is not mapped by clients, and is not "drmAddMapped" at all (maybe it should be done using DRM_RESTRICTED). It means that once the kernel has copied the commands to the buffer and they are verified, a client has no means of changing them. Regards /Thomas Dave.