Re: [Dri-devel] Pseudo DMA?
On Thursday 07 February 2002 12:37 pm, Jose Fonseca wrote: Could someone of the 3D gurus enlighten this question? More specifically, what is pseudo DMA and what is the relationship between DMA and the PIO and MMIO modes? psuedo DMA is where you pass a DMA-able command buffer to an interpreter engine that then submits the commands via MMIO. It's of mixed use- it's slower than straight MMIO, if you've got the command structure figured out it can give you a litmus to tell you if you've got problems with the DMA pass (Ex. It ran in psuedo DMA, why isn't it working right in DMA? The mach64 has an issue with PPC machines where it just isn't happy with one of the gears rotating in gears, but only if it's being DMAed to the chip- PDMA works fine and both work as expected on x86 platforms... I still haven't quite figured that one out yet.) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Monday 18 February 2002 10:35 pm, Keith Whitwell wrote: The rings are in agp space. It's a bug in the security model of the i810, it's arcane, but believe me it's real. Which leaves it open to attack because the AGP space isn't covered by the protection system. Got to wonder what they were thinking with that- to come up with a nice scheme for protecting the system against rogue code submitted from userspace to leave it open like that. I guess they thought it'd be difficult to implement an exploit with that. I ought to read up more on the rings- I got the impression from the documentation that they were just out in memory and were purely DMAed from anywhere in system memory. Thank you for being patient and putting up w/me here... :-) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
Frank C. Earl wrote: On Monday 18 February 2002 10:35 pm, Keith Whitwell wrote: The rings are in agp space. It's a bug in the security model of the i810, it's arcane, but believe me it's real. Which leaves it open to attack because the AGP space isn't covered by the protection system. Got to wonder what they were thinking with that- to come up with a nice scheme for protecting the system against rogue code submitted from userspace to leave it open like that. I guess they thought it'd be difficult to implement an exploit with that. I ought to read up more on the rings- I got the impression from the documentation that they were just out in memory and were purely DMAed from anywhere in system memory. I'm pretty sure it was an oversight. I don't think I can talk about why I think that, though... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
Frank C. Earl wrote: On Thursday 14 February 2002 10:33 am, Keith Whitwell wrote: I haven't had a good look at security on either of these cards, but it's definitely worth doing, both to find out if we're doing too little and if we're doing too much. I've been looking at the i810 programmer's guide trying to understand why it's acceptable to send commands mixed with the verticies to it (since that is the same boat we're in with the RagePRO), and we might be doing too much in one aspect, and not enough in others. Someone should look over my shoulder here and see if I'm plain flat missing something... The i810 has a security model that makes insecure commands in batch buffers into noops. Unfortunately there is a hole in the security model: you can emit a batch buffer with blit commands in it that blit insecure commands onto the ring, where they may then be executed... In addition to unmapping the buffer, the i810 kernel module emits commands into the buffer itself, ensuring that the data can only be interpreted as vertices. Eg, imagine receiving a buffer full of bogus commands from a spoofing app - the kernel module unmaps it from userspace, then writes at the top of the buffer a command that says: emit the next 4096 (or whatever) bytes as a tristrip. No commands from the app can ever be executed. The mapping/unmapping doesn't seem to buy us much in the way of protection and is slow. According to the documentation from Intel, the chip is designed to handle these situations for us. While I know the chip is slow, is it really needed to do this operation which is a very big bottleneck on performance? Yes, unfortunately. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Monday 18 February 2002 12:07 pm, Keith Whitwell wrote: The i810 has a security model that makes insecure commands in batch buffers into noops. Unfortunately there is a hole in the security model: you can emit a batch buffer with blit commands in it that blit insecure commands onto the ring, where they may then be executed... I didn't see that in the documentation. If it's only working from the premise that the command stream is untrusted, it's supposed to stop operation at that point. Since the ring buffers are supposed to be in system memory, I'd have thought that if you controlled the buffers so that the rings are NEVER accessable to the user from the driver they couldn't be used to ammend commands to it (real memory access...) with a batch buffer. I'll re-read things since you're claiming different from what I got from it. In addition to unmapping the buffer, the i810 kernel module emits commands into the buffer itself, ensuring that the data can only be interpreted as vertices. Eg, imagine receiving a buffer full of bogus commands from a spoofing app - the kernel module unmaps it from userspace, then writes at the top of the buffer a command that says: emit the next 4096 (or whatever) bytes as a tristrip. No commands from the app can ever be executed. If the commands don't allow any access to anything system memory-wise (which is what you're doing in the command to start the buffer) then they can't overwrite anything or be used to snag memory that doesn't belong to the app. I'd have to double check the source code- I didn't see anything that parsed vertex info into DMA commands in the driver layer. I'd expect that if it's entirely as you claim it is. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Monday 18 February 2002 01:07 pm, Keith Whitwell wrote: A followup here... I'm looking at the i810 documentation and the source tree now. The i810 has a security model that makes insecure commands in batch buffers into noops. Unfortunately there is a hole in the security model: you can emit a batch buffer with blit commands in it that blit insecure commands onto the ring, where they may then be executed... The documentation lends the idea that it doesn't convert them to no-ops, but rather does the rough equivalent of a segfault, signalling an interrupt on the bus. The hole you describe is an interesting issue though- hadn't thought of that one. Has there been an actual test to see if it was doable from an unsecured batch buffer? I couldn't find any discussion in the list archives as to whether this is a theoretical exploit or an actual one for this chip. In addition to unmapping the buffer, the i810 kernel module emits commands into the buffer itself, ensuring that the data can only be interpreted as vertices. Eg, imagine receiving a buffer full of bogus commands from a spoofing app - the kernel module unmaps it from userspace, then writes at the top of the buffer a command that says: emit the next 4096 (or whatever) bytes as a tristrip. No commands from the app can ever be executed. Ok, I see what the code's doing there- missed it in both my passes over it (Don't know how I missed it- if it'd been a snake...). So the mesa side of things isn't supposed to write in the very first part of the buffer to allow for the insertion of that command, then. Is it a good thing to un-map it _after_ you write in the command at the head of the batch buffer? I'd think it'd leave a loophole in there (because they could sneak in another command in the place of the one the driver is placing)- difficult to exploit, but there all the same. Ugh... Ok, I see, I understand. What a shame. Really, it is- the driver as it stands ends up being SLOWER than a mach64 under Utah-GLX. Yes, Utah-GLX was less secure, but to be so much slower as to have the same gears framerate with a PIII-600 as I got with a PII-450 on a supposedly slower chipset- well, it really sickens me. What's the mach64 card going to end up being like performance wise? Are there any cards out there that don't have seriously borked DMA models that we have to do intrinsically inefficient things just to secure the driver? I had hoped that the i810 would be a workable chipset for the pilot project with my employer's planned product offerings- it would be a slow chip, but it would allow me a way of demoing some 3D games, etc. on a set-top box system. Now, well... -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
Frank C. Earl wrote: On Monday 18 February 2002 12:07 pm, Keith Whitwell wrote: The i810 has a security model that makes insecure commands in batch buffers into noops. Unfortunately there is a hole in the security model: you can emit a batch buffer with blit commands in it that blit insecure commands onto the ring, where they may then be executed... I didn't see that in the documentation. If it's only working from the premise that the command stream is untrusted, it's supposed to stop operation at that point. Since the ring buffers are supposed to be in system memory, I'd have thought that if you controlled the buffers so that the rings are NEVER accessable to the user from the driver they couldn't be used to ammend commands to it (real memory access...) with a batch buffer. I'll re-read things since you're claiming different from what I got from it. The rings are in agp space. It's a bug in the security model of the i810, it's arcane, but believe me it's real. In addition to unmapping the buffer, the i810 kernel module emits commands into the buffer itself, ensuring that the data can only be interpreted as vertices. Eg, imagine receiving a buffer full of bogus commands from a spoofing app - the kernel module unmaps it from userspace, then writes at the top of the buffer a command that says: emit the next 4096 (or whatever) bytes as a tristrip. No commands from the app can ever be executed. If the commands don't allow any access to anything system memory-wise (which is what you're doing in the command to start the buffer) then they can't overwrite anything or be used to snag memory that doesn't belong to the app. I'd have to double check the source code- I didn't see anything that parsed vertex info into DMA commands in the driver layer. I'd expect that if it's entirely as you claim it is. Let me try to summarize: There are commands that access the system memory, but you can only emit them from the ring. You can get them onto the ring via the blitter from batch buffers. Unless the batch buffers are unmapped from userspace after they are submitted to the ring, an untrusted app can overwrite them with the blit-to-ring commands while they are queued for execution. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
Ugh... Ok, I see, I understand. What a shame. Really, it is- the driver as it stands ends up being SLOWER than a mach64 under Utah-GLX. Yes, Utah-GLX was less secure, but to be so much slower as to have the same gears framerate with a PIII-600 as I got with a PII-450 on a supposedly slower chipset- well, it really sickens me. What's the mach64 card going to end up being like performance wise? Raster wise - exactly the same. Geomtry wise - a bit worse, but maybe there are some good opts in mesa 4.0 to make up some of the difference. Are there any cards out there that don't have seriously borked DMA models that we have to do intrinsically inefficient things just to secure the driver? I had hoped that the i810 would be a workable chipset for the pilot project with my employer's planned product offerings- it would be a slow chip, but it would allow me a way of demoing some 3D games, etc. on a set-top box system. Now, well... The i810 is seriously raster bound for most games, I'd be suprised if it made much difference in those situations. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Friday 08 February 2002 07:09 pm, José Fonseca wrote: Does this mean that client code can lock the card but is not really capable of putting the security of the system in danger? Depends on what you define as in danger. It won't allow a user to commit local or remote exploits to gain root, etc., but it could be used to lock up the console such that it requires a remote session of some sort to do a reboot. This is why, when it passes muster, I'm putting it in a seperate branch- it's usable, and should be fairly stable, but it's not protected from malicious clients, etc. To be a proper secure driver, it HAS to be such that you can't DoS the box via the driver if at all possible. Since there is no specialized groupings of commands (such as one to push a lot of verticies to the card), I would have to create a shorthand system that the module would interpret and then generate the right commands for the DMA channel to use, or come up with a way to detect a lockup on the chip and do a proper reset. The first option has an extra inner loop to process against (It took cycles to FILL the list, now you're taking cycles to unpack and re-express them in a form that the card can handle...), eating cycles that could be used elsewhere in the system. The second option presumes one can detect cleanly a locked up chip always and do a reset always. Sorry for the dumb question (my knowledge of the DMA mechanism is still rather incomplete..), but in what way the distinction of the set of commands (in the DMA buffers I presume) affects the security? Depends on the chip. In the case of the RagePRO, there is literally nothing keeping you from submitting commands in the DMA stream that can lock up the chip. Not very many (if any of them...) of the routines in the XAA driver for the RagePRO expect a hung card (because they're not doing anything that COULD lock the card) and there's a couple of locked up states from the DMA pass that leave the engine state as being busy forever- and end up being deadlocked, thus hanging the console but good. If the XAA driver and the kernel module could check unobtrusively for a locked up state and do a reset if it is locked up, the situation would go from being an insecure one to a relatively secure one (As secure as it's going to get and not impair performance...) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Pseudo DMA?
Frank C. Earl wrote: On Friday 08 February 2002 07:09 pm, José Fonseca wrote: Does this mean that client code can lock the card but is not really capable of putting the security of the system in danger? Depends on what you define as in danger. It won't allow a user to commit local or remote exploits to gain root, etc., but it could be used to lock up the console such that it requires a remote session of some sort to do a reboot. This is why, when it passes muster, I'm putting it in a seperate branch- it's usable, and should be fairly stable, but it's not protected from malicious clients, etc. To be a proper secure driver, it HAS to be such that you can't DoS the box via the driver if at all possible. Since there is no specialized groupings of commands (such as one to push a lot of verticies to the card), I would have to create a shorthand system that the module would interpret and then generate the right commands for the DMA channel to use, or come up with a way to detect a lockup on the chip and do a proper reset. The first option has an extra inner loop to process against (It took cycles to FILL the list, now you're taking cycles to unpack and re-express them in a form that the card can handle...), eating cycles that could be used elsewhere in the system. The second option presumes one can detect cleanly a locked up chip always and do a reset always. I don't think you should count on being able to reset the chip once you detect a lockup. Things like bus lockups are pretty fatal events. Besides, I've yet to see the sample code for resetting the ATI chips actually work reliably, if at all :-) W.r.t. your first comment, think long and hard about what you could do with a user-space programmable DMA engine that can read and write arbitrary locations in system memory. It may be hard, but it's entirely within the real of possibility that you can become root. Similarly, you should not design a mechanism that allows the chip to lock up for any other reason than a bug in the driver. There is nothing but proper security -- it's either a secure driver, or it's not. It is unacceptable to have a non-alpha quality driver that has backdoors like this. Sorry for the dumb question (my knowledge of the DMA mechanism is still rather incomplete..), but in what way the distinction of the set of commands (in the DMA buffers I presume) affects the security? Depends on the chip. In the case of the RagePRO, there is literally nothing keeping you from submitting commands in the DMA stream that can lock up the chip. Again, nothing stopping you from submitting commands that changes your UID to '0', hence becomming root... Difficult, but not impossible. Not very many (if any of them...) of the routines in the XAA driver for the RagePRO expect a hung card (because they're not doing anything that COULD lock the card) and there's a couple of locked up states from the DMA pass that leave the engine state as being busy forever- and end up being deadlocked, thus hanging the console but good. If the XAA driver and the kernel module could check unobtrusively for a locked up state and do a reset if it is locked up, the situation would go from being an insecure one to a relatively secure one (As secure as it's going to get and not impair performance...) Please think about what you're suggesting. These chips can read and write arbitrary locations in system memory. For all chips that have this feature, the only safe way to program them is from within a DRM kernel module. Only clients that have been authenticated via the usual (X auth) means are able to talk to such modules. There is simply no other way to do it. You can trust the X server and the kernel module. You CANNOT trust anything else -- a client-side 3D driver, something masquerading as one, whatever... There is a reason why all the DRI drivers for commodity cards are designed like this. It's a pain, but that's the price you pay for a secure system. -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Pseudo DMA?
Frank C. Earl wrote: The command pathway doesn't seem to allow for that. Only the blit pathway. I've coded only inbound to the aperture writes with that pathway, but not outbound (there's very little that anything other than the X server needs to do that sort of thing). How do you prevent a client-side driver from sending down blit commands, without inspecting the DMA buffer? Ok, that's going to make the machine do the work twice- once for filling the buffer with verticies and then again to unpack them and submit commands to the engine. I was trying to avoid a bottleneck- but, okay, if that's not acceptable, I'll do it the other way. You can't allow the user-space portion of the driver to fill in the register programming words in the DMA buffer. Vertex data, sure, that's okay. The registers are mapped into two separate pages for PIO access, but all that goes away when you're doing DMA transfers... The engine doesn't seem to allow for that if you disallow the user to set up blit operations. I'd have to run a test to be sure, but I think the engine would lock up if you messed with the setup registers and tried to transform the gui-master into a blit and that'd be only way what you suggest could happen with the RagePRO from what I can tell. Exactly how do you do this? The other cards seem to mainly have nice pathways for submitting verticies, etc. This one doesn't. I'll recode it to accomodate no commands but pure data- it's not just a pain, it's horribly inefficient with this card the way it's designed. It's a damned slow chip. With anything over about a 4-500MHz processer, you'll still be able to saturate the chip -- we got it to hit the hardware limit doing PIO with a 600MHz PIII, I seem to recall... -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
From what I understood from Alexander and Keith replies, DMA allows not only to copy raw data (e.g., textures, z-buffers, vertexs) from the system memory to the card's memory but also allows to automate the card's registers programming in a way which is different of the PIO or MMIO modes. Am I right on this? And from what I saw in the AGP specification document, AGP is not only a faster fully replacement to DMA but (in cards that support it) it effectively extends the card memory with system memory. Is this correct? Keith, is pseudo DMA a hardware feature of Matrox cards or just a software hack for debugging purposes? Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Friday 08 February 2002 11:03 am, Jose Fonseca wrote: Keith, is pseudo DMA a hardware feature of Matrox cards or just a software hack for debugging purposes? I'm not Keith, but I'll venture an answer. It's a software hack that was in the Utah-GLX drivers for the G200/G400 and RagePRO (a.k.a. Mach64). I don't know if it was included in any of the other drivers or not. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
Hi Frank, On 2002.02.08 22:04 Frank C . Earl wrote: On Thursday 07 February 2002 12:37 pm, Jose Fonseca wrote: Their glossary (http://utah-glx.sourceforge.net/faq.html#AEN364) gives the definition of PIO, DMA and Pseudo DMA. PsuedoDMA is pushing the command data in a DMA-able format to an engine that issues PIO commands one-by-one. It's actually slower than doing PIO commands, but allows you to have one pathway for all conditions instead of two differing ways of sending commands to the chip, which makes for easier development in the blocks of code issuing the rendering commands. On a different note, I had some things come up that kept me away from completing the initial cut of the Mach64 DMA code- I should be getting back on track over this weekend and should be building a sub-branch of the Mach64 It's good news indeed! I was expecting hearing from you some time ago but I didn't dare to bother you since I know how busy your life has been lately.. branch shortly. It will NOT be secure (in the sense that ill-behaved code can't take a box out) for this revision while I work out the details of Does this mean that client code can lock the card but is not really capable of putting the security of the system in danger? securing it. Unlike the other chips, apparently there's no distinction between sets of commands such that I can say, here's a set of verticies, go Sorry for the dumb question (my knowledge of the DMA mechanism is still rather incomplete..), but in what way the distinction of the set of commands (in the DMA buffers I presume) affects the security? to it, to the chip, so I either have to come up with a PDMA-ish convention that will degrade performance or come up with some sort of watchdog process inside the module to detect a hang and reset the chip accordingly. (My vote is for seeing if we can come up with a quick check for a locked up state and doing a reset as we now know how to do a full reset that resets the DMA, etc. on the chip from all of our hacking about to get the DMA test working.). -- Frank Earl Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Pseudo DMA?
I'm in the process of gathering all the interesting information on the Utah-GLX project to the FAQ. Their glossary (http://utah-glx.sourceforge.net/faq.html#AEN364) gives the definition of PIO, DMA and Pseudo DMA. The PIO definition presented there raises no polemics but I don't see what's different between Pseudo DMA and plain DMA. (It seems that their concept of plain DMA is in fact MMIO since no reference to MMIO is given there.) Could someone of the 3D gurus enlighten this question? More specifically, what is pseudo DMA and what is the relationship between DMA and the PIO and MMIO modes? Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Pseudo DMA?
PIO = Programmable IO. Registers that are possibly in x86 IO address space or PCI config space. Today these are just memory mapped registers where the CPU has direct access. DMA = DirectMemoryAccess. Typically an engine on a chip which trasnfers data forth and back. It needs initialisation via some sort of register programming or other meance. Other terms might be specific to individual chipsets, chipset vendors or software projects. Some other keywords are just subsets of special variants of the above. (AGP transfers are just a special case of a DMA.) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
