Re: [Dri-devel] mach64 and new tree
Dave Airlie wrote: So should we just work on getting everything running on newtree then and not worry about the security issues for now? Sounds good to me, I'll look into disabling DMA by default, if we have the option we are okay, my only issue is though should there be something in the DRM that it affects? I can't see how XF86Config could make it safe, if I have a DRM that allows it I can access it from userspace process without DRI or XFree86... XF86Config should only be modifiable by root, so if root decides to be insecure, that's root's business. BTW, if you're working with vertices, you should definitely be using the new t_vertex.c code (see the i830 driver) if at all possible. It can be extended to cover some more scenarios if necessary -- perhaps we need to allow driver extensions to that code. Keith --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
On Fri, Feb 13, 2004 at 01:31:59AM +, Dave Airlie wrote: So should we just work on getting everything running on newtree then and not worry about the security issues for now? Sounds good to me, I'll look into disabling DMA by default, if we have the option we are okay, my only issue is though should there be something in the DRM that it affects? I can't see how XF86Config could make it safe, if The thing with normal DMA in Mach64 is that the DMA buffers can have not only geometry, textures, but also bus mastering commands which almost give access of the system full physical memory to the client. But the current DRM has a pseudo-DMA mode which from the client POV works just like the normal DMS, except that is syncronous. That pseudo-DMA mode was original written as a debugging aiding tool to help transition for the full DMA. It sends the commands to the card one by one using MMIO. If we add a simple sanity/security check to the mach64_do_dispatch_pseudo_dma() in mach64_dma.c then client no longer can issue naughty commands. I have a DRM that allows it I can access it from userspace process without DRI or XFree86... That's not correct. Many DRM IOCTLs can only be used by root (such as the one to enable/disable DMA). [...] And Jose if you have any work done on the DRM interface change in any state or any ideas, could you drop it somewhere so I can start looking at it maybe.. I don't care if it does anything I'm more trying to get the ideas you were proposing than a working DRM ... I'm afraid I have many ideas but not work in the same proportion... There is a newdrm-0-0-1-branch which has some of the necessary infrastuture (especially the DMA pool mangament code is complete). Unfortunately at the time I got carried away and also tried to make the DRM common code in a true library (replacing DRM_* macros by functions like a mania) and eventually didn't finish either task. I'll see if I have any uncommited code in my hard-drive and generate the doxygen documentation for you this weekend. But to avoid past mistakes I strongly advise you to take this slowly, with one little step at a time. Having Mach64 on the trunk seems a step big enough, without any prejudice to your goals. Jose Fonseca --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
If it's OK to sacrifice some speed in order to make the mach64 driver secure and elegible to go the the trubk then there is quite a simple solution: disable DMA by default (using the MMIO pseudo-DMA). Users still have the option to force DMA in XF86Config if they so wish. I think this would make most people happy, as users no longer had to download snapshots, and for the developers it would be easier too as no further HEAD merges would be necessary. The mach64 will only be secure with a redesign of the DRM DMA engine. Without it there will always be a tradeoff between speed to get security. Jose Fonseca On Mon, Feb 09, 2004 at 11:59:37AM -0800, James Jones wrote: Dave, I was the one that brought this up. I have a little time (a few hours a week only) to work on it, and since no one else seemed to care I was going to tackle this very slowly. I was going to work on the DRM insecurities once I dug up the old conversations with Jose detailing what needed to be done. I know he had a whole new dma system in the works that was supposed to be flexible enough to solve these problems. I was hoping to come up with a simpler fix to get things working just good enough for mach64 to be considered secure. I assumed it could then be included in the main branches (wherever they may be now) where it would be easier to keep up to date at least. I'm glad others are still interested and its good to hear that progress is already being made. -James --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
So should we just work on getting everything running on newtree then and not worry about the security issues for now? -James - Original Message - From: Keith Whitwell [EMAIL PROTECTED] To: José Fonseca [EMAIL PROTECTED] Cc: James Jones [EMAIL PROTECTED]; [EMAIL PROTECTED]; Dave Airlie [EMAIL PROTECTED] Sent: Thursday, February 12, 2004 10:53 AM Subject: Re: [Dri-devel] mach64 and new tree José Fonseca wrote: If it's OK to sacrifice some speed in order to make the mach64 driver secure and elegible to go the the trubk then there is quite a simple solution: disable DMA by default (using the MMIO pseudo-DMA). Users still have the option to force DMA in XF86Config if they so wish. I think this would make most people happy, as users no longer had to download snapshots, and for the developers it would be easier too as no further HEAD merges would be necessary. This seems like a good way forward. Keith --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
So should we just work on getting everything running on newtree then and not worry about the security issues for now? Sounds good to me, I'll look into disabling DMA by default, if we have the option we are okay, my only issue is though should there be something in the DRM that it affects? I can't see how XF86Config could make it safe, if I have a DRM that allows it I can access it from userspace process without DRI or XFree86... I think the branch now works as well as the older branch the last couple of commits I did last night fixed up the issues with specular/fog stuff that I messed up a bit.. we are now using packed vertices, So texmem changes, and a bit more testing, my issue is I can't keep both trees built on my laptop :-), so I'm hoping I don't need to change the old tree for debugging to track down anything I break!!.. And Jose if you have any work done on the DRM interface change in any state or any ideas, could you drop it somewhere so I can start looking at it maybe.. I don't care if it does anything I'm more trying to get the ideas you were proposing than a working DRM ... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
Dave, I was the one that brought this up. I have a little time (a few hours a week only) to work on it, and since no one else seemed to care I was going to tackle this very slowly. I was going to work on the DRM insecurities once I dug up the old conversations with Jose detailing what needed to be done. I know he had a whole new dma system in the works that was supposed to be flexible enough to solve these problems. I was hoping to come up with a simpler fix to get things working just good enough for mach64 to be considered secure. I assumed it could then be included in the main branches (wherever they may be now) where it would be easier to keep up to date at least. I'm glad others are still interested and its good to hear that progress is already being made. -James Dave Airlie wrote: I noticed it came up during the IRC meeting this week about moving the mach64 up to the top of tree, So how should this be done in terms of CVS, the mach64 driver as is insecure, so I'd rather not put into an official tree until those issues are sorted out, I know Jose has some ideas on these and I'll see if I can track him down at some point, but for now I'd like to bring the current branch up to the top of tree at least, So should I use the mesa tip and start a new mach64 branch on the DRI tree or should I make a branch on both trees? oh yeah I'm unsure who brought it up on IRC so if you are on the list speak up :-) Dave. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64 and new tree
I noticed it came up during the IRC meeting this week about moving the mach64 up to the top of tree, So how should this be done in terms of CVS, the mach64 driver as is insecure, so I'd rather not put into an official tree until those issues are sorted out, I know Jose has some ideas on these and I'll see if I can track him down at some point, but for now I'd like to bring the current branch up to the top of tree at least, So should I use the mesa tip and start a new mach64 branch on the DRI tree or should I make a branch on both trees? oh yeah I'm unsure who brought it up on IRC so if you are on the list speak up :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
Dave Airlie wrote: track him down at some point, but for now I'd like to bring the current branch up to the top of tree at least, So should I use the mesa tip and start a new mach64 branch on the DRI tree or should I make a branch on both trees? oh yeah I'm unsure who brought it up on IRC so if you are on the list speak up :-) I've just brought the mesa driver from mach64-0-0-6 so it compiles in the top of the Mesa tree (I doubt it works, but building is a good start) so if someone tells me where to put it I'll commit it for a start point tomorrow (I'm GMT+10, should probably use .au a/c :-) I'll work on the XFree bits and the DRM should be similiar enough soon.. I think it should be fine to go in at Mesa head. Keith --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
track him down at some point, but for now I'd like to bring the current branch up to the top of tree at least, So should I use the mesa tip and start a new mach64 branch on the DRI tree or should I make a branch on both trees? oh yeah I'm unsure who brought it up on IRC so if you are on the list speak up :-) I've just brought the mesa driver from mach64-0-0-6 so it compiles in the top of the Mesa tree (I doubt it works, but building is a good start) so if someone tells me where to put it I'll commit it for a start point tomorrow (I'm GMT+10, should probably use .au a/c :-) I'll work on the XFree bits and the DRM should be similiar enough soon.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
tomorrow (I'm GMT+10, should probably use .au a/c :-) I'll work on the XFree bits and the DRM should be similiar enough soon.. I think it should be fine to go in at Mesa head. Okay what about the DRI tree bits? DRM and changes to ATI driver?, should I go with mach64-0-0-7 or should I just make sure the ati bits work and not add mach64 to the host.def (I can see that messing up the snapshots a bit though), or maybe I just add a big huge warning to the DRM module and the X startup stating the mach64 DRM is inherently insecure and shouldn't be used on multi-user systems? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
