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
