Re: [rfc] VIA dri and security.
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.
Re: [rfc] VIA dri and security.
Thomas Hellström wrote: 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 don't think that's entirely true. I'm not too familiar with this part of the Unichrome DRI driver, but you basically want to be able to send buffers of register / value pairs into the kernel for verification, right? If so, I don't think the changes will be that difficult, though they may be time consuming. On the user side, we just need a mechanism to fill submit the buffers. The tricky part is finding all the places that currently access the MMIO region, though that probably won't be too difficult. On the kernel side, we just have to verify those buffers. No detailed 3D knowledge is needed for that. A person can just look at the DRI driver to see what kinds of things it sends! :) Can you make it to the #dri-devel chat next Monday? Perhaps we could discuss the details then. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
Hi, Ian! Ian Romanick wrote: Thomas Hellström wrote: 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 don't think that's entirely true. I'm not too familiar with this part of the Unichrome DRI driver, but you basically want to be able to send buffers of register / value pairs into the kernel for verification, right? If so, I don't think the changes will be that difficult, though they may be time consuming. On the user side, we just need a mechanism to fill submit the buffers. The tricky part is finding all the places that currently access the MMIO region, though that probably won't be too difficult. On the kernel side, we just have to verify those buffers. No detailed 3D knowledge is needed for that. A person can just look at the DRI driver to see what kinds of things it sends! :) Can you make it to the #dri-devel chat next Monday? Perhaps we could discuss the details then. I'll try to do that. Upon closer inspection of the unichrome_dri.so driver source it seems like there is a PCI path that takes a command buffer and parses it, and this should be an excellent start of the command verifier. According to Erdi, the driver currently alternates between two static AGP buffers. To port this to use the ring-buffers one would probably only need to malloc() memory for those and replace the current flush code with an IOCTL. The problem for me is, like for most people, time. Regards. Thomas --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-deve l --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
On Maw, 2004-10-12 at 01:14, Dave Airlie wrote: 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... Unless the data set is very large this is the right answer - just copy them. You can revoke pages but that is messy and involves cross CPU calls so sucks on SMP or HT machines. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
Thomas Hellström wrote: Hi! Sorry for the double posting. This is a thing that needs to be discussed in both communities. The via DRM has started it's journey into the linus kernel, but the 3D driver / DDX still suffers from a security flaw: When the MMIO area is exported read-write it is assumed possible for a dri client to manipulate registers to blit otherwise protected areas of the system memory to video memory. It is the DDX that tells the DRM whether to export the MMIO area read-only or read-write. The OpenGL 3D driver unichrome_dri.so currently needs write access to this area, until someone fixes it up to use register writing ioctls now present in the via drm. The obvious fix is for the DDX to tell DRM to export the MMIO area as read-only. In this way a normal user would get a segfault when trying to run accelerated OpenGL, while it would work as root. This sort of thing has been discussed in the past, going all the way back to UtahGLX, which had a root-only direct rendering system of sorts. The trouble with doing this, and this was well established in UtahGLX, is that if you make a high-performance path available only to root, you get people running as root when they ordinarily wouldn't do so in order to access that performance path. Specifically, you're encouraging people to run binary-only games toys with full superuser permissions. This is actually worse than a DRM model with theoretical insecurities - under that model a program would have to be cleverly crafted to expose and exploit the insecurity. Under this run games as root model, all of a sudden games have to be cleverly crafted and audited to *avoid* exposing insecurities... Nobody has done a security audit on q3 that would allow you to feel comfortable running it as root, to my knowledge... Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
Hi, Keith! Thomas Hellström wrote: Hi! Sorry for the double posting. This is a thing that needs to be discussed in both communities. The via DRM has started it's journey into the linus kernel, but the 3D driver / DDX still suffers from a security flaw: When the MMIO area is exported read-write it is assumed possible for a dri client to manipulate registers to blit otherwise protected areas of the system memory to video memory. It is the DDX that tells the DRM whether to export the MMIO area read-only or read-write. The OpenGL 3D driver unichrome_dri.so currently needs write access to this area, until someone fixes it up to use register writing ioctls now present in the via drm. The obvious fix is for the DDX to tell DRM to export the MMIO area as read-only. In this way a normal user would get a segfault when trying to run accelerated OpenGL, while it would work as root. This sort of thing has been discussed in the past, going all the way back to UtahGLX, which had a root-only direct rendering system of sorts. The trouble with doing this, and this was well established in UtahGLX, is that if you make a high-performance path available only to root, you get people running as root when they ordinarily wouldn't do so in order to access that performance path. Specifically, you're encouraging people to run binary-only games toys with full superuser permissions. This is actually worse than a DRM model with theoretical insecurities - under that model a program would have to be cleverly crafted to expose and exploit the insecurity. Under this run games as root model, all of a sudden games have to be cleverly crafted and audited to *avoid* exposing insecurities... Nobody has done a security audit on q3 that would allow you to feel comfortable running it as root, to my knowledge... Keith Agreed. So what is your actual suggestion? Export read-write as default or, as proposed, export read-write when AllowInsecureDRI is enabled in the X server config? Regards Thomas. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
Thomas Hellström wrote: Hi, Keith! Thomas Hellström wrote: Hi! Sorry for the double posting. This is a thing that needs to be discussed in both communities. The via DRM has started it's journey into the linus kernel, but the 3D driver / DDX still suffers from a security flaw: When the MMIO area is exported read-write it is assumed possible for a dri client to manipulate registers to blit otherwise protected areas of the system memory to video memory. It is the DDX that tells the DRM whether to export the MMIO area read-only or read-write. The OpenGL 3D driver unichrome_dri.so currently needs write access to this area, until someone fixes it up to use register writing ioctls now present in the via drm. The obvious fix is for the DDX to tell DRM to export the MMIO area as read-only. In this way a normal user would get a segfault when trying to run accelerated OpenGL, while it would work as root. This sort of thing has been discussed in the past, going all the way back to UtahGLX, which had a root-only direct rendering system of sorts. The trouble with doing this, and this was well established in UtahGLX, is that if you make a high-performance path available only to root, you get people running as root when they ordinarily wouldn't do so in order to access that performance path. Specifically, you're encouraging people to run binary-only games toys with full superuser permissions. This is actually worse than a DRM model with theoretical insecurities - under that model a program would have to be cleverly crafted to expose and exploit the insecurity. Under this run games as root model, all of a sudden games have to be cleverly crafted and audited to *avoid* exposing insecurities... Nobody has done a security audit on q3 that would allow you to feel comfortable running it as root, to my knowledge... Keith Agreed. So what is your actual suggestion? Export read-write as default or, as proposed, export read-write when AllowInsecureDRI is enabled in the X server config? To tell the truth, I wasn't making one. If I were to though, it would follow on from the above fairly directly: - Don't allow any situation where root clients have better access to hardware than non-root clients. So, to my mind that would mean 1) Don't export insecure registers read-write, and 2) Don't distribute anything until there exists a working non-root 3d driver. That way there would be no incentive to run insecure programs as root. It's clear that this circumstance wasn't considered by the original DRM designers, or there would be a way to create mappings that are private to the X server, so that not even root clients would be able to use them. Note that this isn't about restricting the ability of root processes to damage the system, but rather about removing an incentive to run insecure programs as root. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
On Llu, 2004-10-11 at 09:42, Thomas Hellstrm wrote: So what is your actual suggestion? Export read-write as default or, as proposed, export read-write when AllowInsecureDRI is enabled in the X server config? 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) If I setuid an app then it depends if that one app is trojanned. If I have AllowInsecureDRI then any trojanned or hostile app gets you. What I think you do want to avoid would be something like DRI is faster as root, which sends all the wrong signals. Alan --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
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 ..).. 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... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[rfc] VIA dri and security.
Hi! Sorry for the double posting. This is a thing that needs to be discussed in both communities. The via DRM has started it's journey into the linus kernel, but the 3D driver / DDX still suffers from a security flaw: When the MMIO area is exported read-write it is assumed possible for a dri client to manipulate registers to blit otherwise protected areas of the system memory to video memory. It is the DDX that tells the DRM whether to export the MMIO area read-only or read-write. The OpenGL 3D driver unichrome_dri.so currently needs write access to this area, until someone fixes it up to use register writing ioctls now present in the via drm. The obvious fix is for the DDX to tell DRM to export the MMIO area as read-only. In this way a normal user would get a segfault when trying to run accelerated OpenGL, while it would work as root. There's been a discussion at the unichrome site, where most of the via DDX development is taking place at the moment, on whether to leave the user with this only option. We propose a solution where the user could use a driver option AllowInsecureDRI to have the MMIO area exported read-write. The security hazards of doing this is briefly explained in the via man-page and warning message will be output in the X server log if this option is enabled. Since we also plan on syncing the development with the via driver in Xorg it's important that this does not violate any security policy in Xorg. We figure that to open up the system in this way, you still need to be root and the option name speeks for itself. Also the average user would more likely damage his system running a 3D application as root than be the subject of somebody exploiting this vulnerability. The current via DDX in Xorg allows read-write access to these registers. It would be good to have some comments / ideas about whether the proposed solution could be considered OK. Regards Thomas --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
