Thinking it through...

The GPU Sniffing scenario is intriguing. The idea is that modifications are made to the graphics driver so that it loads and runs shaders onto the GPU. This would enable the shaders to do whatever they want to the the pixel-stream.

Problem(s):

1. Running in the kernel context there are no OpenGL libraries so how could the code work?
2. Dr. B seems to have been interested in NOT doing kernel-level changes. This would mean doing an application or application framework-based solution

Lessons from HelloGPGPU:

GPGPU CONCEPTS Introduced:

• Texture = Array


• Fragment Program = Computational Kernel.


• One-to-one Pixel to Texel Mapping: Data-Dimensioned Viewport, and Orthographic Projection.


• Viewport-Sized Quad = Data Stream Generator.


• Copy To Texture = feedback.

GPU Sniffing...

It seems that there are 3 scenarios:

1. Application-based:

One-off solutiion. Custom code.

2. Application-framework-based:

Use a framework to support development for the GPU. This solution could include introducing compiler tricks to introduce shader code. This is

3. GPU Sniffing:

Modify the kernel-level code that touches the hardware. This could be very tricky since there won't be any OpenGL libraries in the kernel to call to setup. Changes to the Xserver/DRI code (drivers) would be required.

Interestingly, this might be a new kind of security issue. In some ways it reminds me of my graphics-virus idea!!!! I assume that the vertex/pixel shaders need to run with a continuous execution context. But if not, then perhaps it's possible to make them memory (GPU memory) resident

Aside: GPU Virus

By modifying the video driver, code could be introduced that would bind shaders to the GPU. These shaders would act on the video stream to accomplish some task. Since the code is running on the GPU the host-system would not see or experience a performance degradation and as such could remain hidden (however, since the video driver would have been changed, an IDS such as Tripwire could be used to detect the GPU-virus). Such a GPU-virus could be used to sureptitiously gather data on the framebuffer.

Linux vs Windows vs Mac OS X

Q: What platform should I use?

Observations:

- Linux: I can make changes at the kernel level to support GPU-Sniffing, but there are fewer perf tools, etc.
- WindowsXP: only have access to application-level changes, but, lots of nice perf tools.
- Mac OS X: Can I use kernel extensions? That might be cool. The problem is that I will only be able to work at home.

From the bottom of /usr/src/linux/Documentation/fb/framebuffer.txt:

7. References
-------------

For more specific information about the frame buffer device and its
applications, please refer to the Linux-fbdev website:

http://linux-fbdev.sourceforge.net/

and to the following documentation:

- The manual pages for fbset: fbset(8), fb.modes(5)
- The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
- The mighty kernel sources:
o linux/drivers/video/
o linux/include/linux/fb.h
o linux/include/video/

Master's Project Stuff: Using the GPU to do intrusion detection.

Q: can the GPU do analysis on the mouse-stream as it flows through the graphic pipeline?

Some ideas:

• what about modifying the video sofware driver to do include some shader code that runs on the GPU to do the
  vertex analysis? Good idea


• this approach could be called: "video sniffing" or "GPU sniffing"


• check out the docs on the framebuffer on linux in the /usr/src/linux/Documentation/fb subdir


• also check out DRI for linux


• maybe there's some good stuff in the XFree86 project


• what about hardware solutions: multiple graphics cards, PCI-Express


• another idea would be to check out some references on SIMD