[Bug 4207] New: Build is failing unable to find r200_vtxtmp_x86.S
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4207 Summary: Build is failing unable to find r200_vtxtmp_x86.S Product: Mesa Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] make[6]: Entering directory `/home/bill/src/RPM/BUILD/Mesa-6.3.2/src/mesa/drivers/dri/r200' ../Makefile.template:110: depend: No such file or directory make[6]: *** No rule to make target `r200_vtxtmp_x86.S', needed by `depend'. Stop. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4207] Build is failing unable to find r200_vtxtmp_x86.S
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4207 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-23 06:47 --- I've fixed this for the next release. In the mean time, you can grab the file from: http://cvs.freedesktop.org/*checkout*/mesa/Mesa/src/mesa/drivers/dri/r200/r200_vtxtmp_x86.S?rev=1.5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
Stephane Marchesin wrote: Now, there is one question that sounds to me like it will have implications over the whole memory manager design : do we want to enforce video memory ownership ? Ok, here is what came out of the irc meeting : - we don't need to enforce video memory ownership, but the drm needs to be able to track allocation owners anyway, for example if a process dies unexpectedly. - regions that are marked as preserve have a matching backing store region in system ram. That region is made of pinned pages. Stephane --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote: Ok, here is what came out of the irc meeting : - we don't need to enforce video memory ownership, but the drm needs to be able to track allocation owners anyway, for example if a process dies unexpectedly. How expensive would it be to protect one processes video memory from another? I would like to be able to run applications for different users on the screen at the same time and prevent both reading and writing of the images. If not possible on current hardware, what would it take from new hardware to make this possible? - regions that are marked as preserve have a matching backing store region in system ram. That region is made of pinned pages. Do they really need to be pinned? That's a huge waste of memory. -keith signature.asc Description: This is a digitally signed message part
Re: Kernel / user interface for new memory manager
On Tue, 2005-08-23 at 10:00 -0700, Ian Romanick wrote: Keith Packard wrote: On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote: Ok, here is what came out of the irc meeting : - we don't need to enforce video memory ownership, but the drm needs to be able to track allocation owners anyway, for example if a process dies unexpectedly. How expensive would it be to protect one processes video memory from another? I would like to be able to run applications for different users on the screen at the same time and prevent both reading and writing of the images. If not possible on current hardware, what would it take from new hardware to make this possible? You'd need the same stuff that you need to protect system memory. You'd need a hardware MMU that could block the accesses. It might be possible to do it in software by looking at the command stream, but I suspect that would be pretty expensive. It would be worth a try, I suppose. Yeah, I don't expect it to be prohibitive; we're basically doing just that for Radeons already. Another part would be to only allow mapping owned parts of the framebuffer. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Tue, Aug 23, 2005 at 01:31:43PM -0400, Michel Dänzer wrote: On Tue, 2005-08-23 at 10:00 -0700, Ian Romanick wrote: Keith Packard wrote: On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote: Ok, here is what came out of the irc meeting : - we don't need to enforce video memory ownership, but the drm needs to be able to track allocation owners anyway, for example if a process dies unexpectedly. How expensive would it be to protect one processes video memory from another? I would like to be able to run applications for different users on the screen at the same time and prevent both reading and writing of the images. If not possible on current hardware, what would it take from new hardware to make this possible? You'd need the same stuff that you need to protect system memory. You'd need a hardware MMU that could block the accesses. It might be possible to do it in software by looking at the command stream, but I suspect that would be pretty expensive. It would be worth a try, I suppose. Yeah, I don't expect it to be prohibitive; we're basically doing just that for Radeons already. Another part would be to only allow mapping owned parts of the framebuffer. Is there any way to make that work without going to the kernel for each allocation? Personally I'd like to have the protection even if it degrades performance slightly. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephane Marchesin wrote: Stephane Marchesin wrote: Now, there is one question that sounds to me like it will have implications over the whole memory manager design : do we want to enforce video memory ownership ? Ok, here is what came out of the irc meeting : - we don't need to enforce video memory ownership, but the drm needs to be able to track allocation owners anyway, for example if a process dies unexpectedly. Correct. The kernel can do that tracking via the log. Each process gets a block of region IDs from the kernel. Each time a process makes an allocation, it writes the offset, size, and ID to the log. - regions that are marked as preserve have a matching backing store region in system ram. That region is made of pinned pages. Okay. There are also regions that are maked as 'pinned'. The only regions that should need this marking are memory areas that are being scanned out (e.g., cursor, current front buffer, etc.) by the video hardware. We'll eventually want to be able to move those regions, but I think we can skip that for now. The thing that killed this project for me the first time around was trying to tackle everything all at once. I've been told that I have a big mouth, but I can only bite off so much at once. ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDC1MvX1gOwKyEAw8RAvz9AJ9pd2Wy7B6rgV72n/Tb3ipdhZPIgQCfXfar WOxN/CBydERASH8ZDFocmlQ= =yx/R -END PGP SIGNATURE- --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Packard wrote: On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote: Ok, here is what came out of the irc meeting : - we don't need to enforce video memory ownership, but the drm needs to be able to track allocation owners anyway, for example if a process dies unexpectedly. How expensive would it be to protect one processes video memory from another? I would like to be able to run applications for different users on the screen at the same time and prevent both reading and writing of the images. If not possible on current hardware, what would it take from new hardware to make this possible? You'd need the same stuff that you need to protect system memory. You'd need a hardware MMU that could block the accesses. It might be possible to do it in software by looking at the command stream, but I suspect that would be pretty expensive. It would be worth a try, I suppose. - regions that are marked as preserve have a matching backing store region in system ram. That region is made of pinned pages. Do they really need to be pinned? That's a huge waste of memory. We had this discussion too. The problem is you need the memory allocated in advance to avoid the allocation failures when the kernel needs to back up the data. If the memory isn't pinned, it can get paged out, and, apparently, the kernel can page-in user pages in the way that we want. Dave Airlie made some comments about that, but I don't remember exactly what he said. Ideally, we want to reserve some pages, but we don't care about their contents. When the kernel needs to back the data, it just needs to get a bunch of blank pages. Dave also mentioned that there were some dirty kernel tricks that would allow that, but that it might not be portable (to BSD) or even stable across Linux kernel versions. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDC1YsX1gOwKyEAw8RAvqkAJ9qfMowGZ6e1B0ejRJaLX3X9gKRrACeNim7 oUZia1N544Mzvx/sLx2mtNs= =G8iT -END PGP SIGNATURE- --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephane Marchesin wrote: Also, with the current log design for the memory manager, it is possible for a rogue process to make the log wrap and not call the force_log_update ioctl, thus being able to create some kind of race condition where the drm believes it still owns the memory but another process has allocated it. 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDC2UmX1gOwKyEAw8RArVVAKCUqkLLjCc0r3EkW5HrKDqbAZTRAgCfcCF6 Iam+OSVg2EOiNOY39EhlkYA= =P5mt -END PGP SIGNATURE- --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
Michel Dänzer wrote: You'd need the same stuff that you need to protect system memory. You'd need a hardware MMU that could block the accesses. It might be possible to do it in software by looking at the command stream, but I suspect that would be pretty expensive. It would be worth a try, I suppose. Yeah, I don't expect it to be prohibitive; we're basically doing just that for Radeons already. Well, right now any app can use BITBLT_MULTI to read/write to others video memory, for example. Not that it's a problem to me, or that I wish to solve it by auditing all the dri drivers to add the necessary checks :) As for the performance, what is done right now (checking that the offset falls within a given region) is some orders of magnitude simpler than what we would have to do (checking the offset against all regions allocated by a process). Also, with the current log design for the memory manager, it is possible for a rogue process to make the log wrap and not call the force_log_update ioctl, thus being able to create some kind of race condition where the drm believes it still owns the memory but another process has allocated it. Another part would be to only allow mapping owned parts of the framebuffer. You'd have to get the cliprects from a trusted source then... Stephane --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Tue, 2005-08-23 at 20:45 +0300, Ville Syrjälä wrote: On Tue, Aug 23, 2005 at 01:31:43PM -0400, Michel Dänzer wrote: Another part would be to only allow mapping owned parts of the framebuffer. Is there any way to make that work without going to the kernel for each allocation? You mean the mapping? No, only the kernel can do that, but again, the overhead of that shouldn't be too bad when you have to do software fallbacks. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Tue, 2005-08-23 at 20:08 +0200, Stephane Marchesin wrote: Michel Dänzer wrote: You'd need the same stuff that you need to protect system memory. You'd need a hardware MMU that could block the accesses. It might be possible to do it in software by looking at the command stream, but I suspect that would be pretty expensive. It would be worth a try, I suppose. Yeah, I don't expect it to be prohibitive; we're basically doing just that for Radeons already. Well, right now any app can use BITBLT_MULTI to read/write to others video memory, for example. Not that it's a problem to me, or that I wish to solve it by auditing all the dri drivers to add the necessary checks :) As for the performance, what is done right now (checking that the offset falls within a given region) is some orders of magnitude simpler than what we would have to do (checking the offset against all regions allocated by a process). Sure, that's the wrong way to go about it. The rendering primitives should be associated with memory objects in the first place. Another part would be to only allow mapping owned parts of the framebuffer. You'd have to get the cliprects from a trusted source then... Not with redirected windows, which will all be distinct objects. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Tue, Aug 23, 2005 at 11:04:22AM -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephane Marchesin wrote: Also, with the current log design for the memory manager, it is possible for a rogue process to make the log wrap and not call the force_log_update ioctl, thus being able to create some kind of race condition where the drm believes it still owns the memory but another process has allocated it. 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. Considering one of the major uses for direct rendering is games I don't think that idea will work. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4150] r300 cairo with glitz backend locks X
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4150 --- Additional Comments From [EMAIL PROTECTED] 2005-08-23 12:49 --- (In reply to comment #12) (In reply to comment #11) (In reply to comment #9) (In reply to comment #4) Is bitblt secure? I don't think so - it could be used to view system memory, so a check is needed. See comment #6. Thing is the patch switches BITBLT to use a r300 raw packet, so this would bypass usual radeon checks. Usual readeon checks arent used for r300 as far as I can see. Looking at radeon_check_and_fixup_packet3, it seems to me like LOAD_VBPNTR would go trough it without any checks. I am not certain why this patch affects things at all, as I would have expected packets inherited from radeon driver to work fine - certainly Xserver should use BITBLT quite often. Perhaps, there is some subtle issue that I am missing ? Remember that xorg uses indirect buffers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Maw, 2005-08-23 at 20:45 +0300, Ville Syrjälä wrote: Is there any way to make that work without going to the kernel for each allocation? Personally I'd like to have the protection even if it degrades performance slightly. X allows applications to read the displayed video memory anyway so what is the big deal here ? You can do memory protection outside of command streams pretty cheaply. If the DRM kernel modules controls which blocks of video ram are mapped into which task then you get memory protection. You will need some kind of reclaim handler to steal memory from other tasks and revoke their pages. That *is* expensive especialy on SMP. --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Maw, 2005-08-23 at 20:08 +0200, Stephane Marchesin wrote: Another part would be to only allow mapping owned parts of the framebuffer. You'd have to get the cliprects from a trusted source then... Memory management hardware isn't that fine grained. Doing cliprect register access via the kernel would work for some chipsets and not be too heavy handed (and no cost in the usual game case). --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: found the problem with the kernel DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Mackerras wrote: I found why my G5 was crashing when using the linux-2.6 version of the DRM + git-drm.patch from 2.6.13-rc6-mm1, but not with the CVS DRM. The reason was that dev-agp-cant_use_aperture wasn't getting set, and the reason for that was that linux/version.h no longer gets included and the #if LINUX_VERSION_CODE 0x020408 in drm_agpsupport.c was going the wrong way. With this patch (and a few others) a 32-bit server works correctly, as does DRI. I still don't have a 64-bit X server working though. The X server gets a certain distance and then the CPU that it is running on just freezes solid - it doesn't even respond to a soft reset. This isn't a DRI problem, though, since it happens without the DRM loaded. I can't get a 32-bit or 64-bit build to work properly on pSeries. I'm stuck on bugzilla #433. My digging so far is leading me into generic PCI code. Is it possible that your 64-bit server on G5 problems are related? https://bugs.freedesktop.org/show_bug.cgi?id=433 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDC4/2X1gOwKyEAw8RAgkzAJ9kDJuqiQC8JJf9Cdw+mhM/VTjzgACfd+jR zu25/22gxzQaDukdc1EB7UA= =Qs6e -END PGP SIGNATURE- --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Tue, 2005-08-23 at 21:46 +0100, Alan Cox wrote: X allows applications to read the displayed video memory anyway so what is the big deal here ? X will not always be in control of the full screen. I'm starting to look at multi-user environments where each user has an X server which isn't in control of the whole screen, but rather just paints X windows into off-screen memory where an external trusted application can take those applications and merge their contents to the final screen. -keith signature.asc Description: This is a digitally signed message part
Re: Kernel / user interface for new memory manager
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. 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. 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. Alan --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
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. 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. 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. Stephane --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
- regions that are marked as preserve have a matching backing store region in system ram. That region is made of pinned pages. Do they really need to be pinned? That's a huge waste of memory. We had this discussion too. The problem is you need the memory allocated in advance to avoid the allocation failures when the kernel needs to back up the data. If the memory isn't pinned, it can get paged out, and, apparently, the kernel can page-in user pages in the way that we want. Dave Airlie made some comments about that, but I don't remember exactly what he said. I've thought a bit more and I think you have a couple of choices. 1. pin the memory into a process address space (bad.) 2. make the memory shared and maybe have a controlling app that can re-page it back into its address space and write the pages out to it, (sounds slow if you are doing a lot of app switching) 3. Well if the app is keeping the memory around why not just make it back it up on lock drop?? (slow...) Dirty tricks abound, I can think of doing something with ptrace maybe... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Wed, 24 Aug 2005, 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. Something like that has already been added to R300 driver and should not be portable to radeon and r200. best Vladimir Dergachev --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
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? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Tue, Aug 23, 2005 at 10:49:28PM -0400, Michel Dänzer wrote: On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote: Alan Cox wrote: 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. To make this bullet proof it would also have to make sure the operation is clipped so that it doesn't extend beyond the allocated memory. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
