User: Password:
|
|
Subscribe / Log in / New account

Memory management for graphics processors

Memory management for graphics processors

Posted Nov 8, 2007 23:53 UTC (Thu) by jwb (guest, #15467)
Parent article: Memory management for graphics processors

This article touches on something I've always wondered.  Is there anything on these GPUs which
prevents a user from addressing random bits of the video memory?  Suppose I use "fast user
switching" in Mac OS to give the system over to some other user.  Does the OS flush the VRAM?
Could the other user program the GPU to display random memory addresses as textures?  If there
are remnants of other people's windows in texture memory, that would be Bad(TM).


(Log in to post comments)

Memory management for graphics processors

Posted Nov 9, 2007 1:11 UTC (Fri) by zlynx (subscriber, #2285) [Link]

I believe that the Linux kernel DRM (direct rendering) modules are supposed to check the
command stream to ensure that cannot happen.

I suppose that with a very optimized DMA design, this might not be possible. In that case
you'd have to trust the X server and OpenGL driver to take care of it.

Memory management for graphics processors

Posted Nov 9, 2007 19:05 UTC (Fri) by nix (subscriber, #2304) [Link]

Unless the commands are so simple they aren't Turing-complete, or their 
form is extremely restricted and stereotyped, I suspect this reduces to 
solving Rice's theorem, which is of course impossible in the general case 
for just the same reason solving the halting problem is, and is 
ridiculously difficult even in most useful special cases.

Memory management for graphics processors

Posted Nov 9, 2007 8:59 UTC (Fri) by airlied (subscriber, #9104) [Link]

Later GPUs such as Intel 965 and up, and ATI r500, and Nvidia g80, have page table support
that can be leverage at a hw level...

However we can mostly protect things using the kernel with the TTM layer described above. It
won't let you access video ram directly everything must go through a buffer object which has
basic sharing permissions.

In the future we hope to implement better permission models and maybe even some sort of
SELinux integration.

Security Implications: Use cases

Posted Nov 9, 2007 18:19 UTC (Fri) by AnswerGuy (subscriber, #1256) [Link]

The "fast user switching" feature that's being added to systems like Ubuntu might have some security downsides. However, we should consider the use case for which "fast user switching" is intended an keep in mind that there are other user switching methods available.

Perusing the Wikipedia article on fast user switching will cover some of the security considerations. Since the "virtual console" features of Linux, FreeBSD and other PC UNIX clones fit roughly into the category of "fast user switching" then the fact that the contents of all those additional terminal (text) screens is visible is roughly the same risk as you express concern about.

The obvious suggestions are: employ screen blankers which are (optionally) hooked into the fast user switching, don't use fast user switching in security sensitive situations (such as Internet cafes).

This latter point is the most obvious. In any case where you're worried about the next user potentially trying to snoop or exploit your session you should be using a "secure attention key" to force the system to kill all processes associated with your terminal and revoke all credentials from it.

Clearly the intended use cases for "fast user switching" are the common situations where folks want to share a computer while maintaining their own desktop configurations, etc. For example I have a couple of computers in the living room, one at the end of the couch and another by the easy chair. Everyone in the household uses whichever of these is closest to do a little web browsing, re-attach to his or her screen session, read e-mail or whatever. Since my wife and I both have root on all of machines around the house we're clearly not worried about the other being able to bypass security, etc.

Given that "fast user switching" implies console access ... there are far greater security risk associated with PC console access in general.

JimD


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds