|
|
Subscribe / Log in / New account

XDC2012: Graphics stack security

XDC2012: Graphics stack security

Posted Sep 27, 2012 16:37 UTC (Thu) by ortalo (guest, #4654)
In reply to: XDC2012: Graphics stack security by mupuf
Parent article: XDC2012: Graphics stack security

I remember reading hardware documentation of something similar to adress translation tables for onboard VRAM on a Cirrus Logic Laguna3D graphics chipset circa... 1996. Good wheels get reinvented so often... ;-)

But even if common hardware protection features are not (uniformly at least) available on GPUs, from what we know about other hardware, it seems that memory protection and priviledged instructions are foundational features for practical security mechanisms.

If these features are not in the hardware I wonder if it's even possible to adress the issue of graphics stack security for multiple applications without:
1) either emulating them (something which apparently has started to appear but does not seem to be universally agreed upon);
2) or evolving the security model to adress a different kind of security features (for example: forbidd applications with conflicting security requirement to use the same "screen").

By the way, maybe option 2 is really workable in the context of graphical applications. Maybe there is a need for a risk/attacks analysis at a higher level and more thinking about the most important security features in order to provide a decent (if not completely satisfactory) implementation.

For example, I would not mind trading a long context switch time (~1s) for access to full hardware control for a fullscreen application (game) while I may be reluctant to do that for a text editor and framebuffer security may even be a reason not to use a GUI for an encryption tool.


to post comments


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