Graphic violence -

Graphic violence


Beware of the GPU: it may be the portal for malware. Here's what you can do about it.

The Intel Core i7 that powers my laptop contains 700 million transistors.

The Nvidia GeForce GTX 460M laptop GPU sports 3 Billion transistors. 336 processing cores. A Gig of its own RAM.

Increasingly, embedded systems are incorporating user interfaces that require a GPU. Examples include smartphones, car infotainment systems, advanced home appliances, and aircraft cockpit displays.

New programming models have made GPU software development more natural and mainstream for the worldwide programming community.

There are a couple Rated R themes regarding GPUs that systems designers often don’t realize or underestimate when considering security. First, the GPU is a bus master, with direct access to your host CPU’s memory (that is how the GPU reads graphics commands from the CPU). And now the GPU can write whatever it wants to shared host memory. Secondly, graphics cards can be programmed by untrusted user mode applications by way of the pass-through user-supervisor driver architecture employed by most general purpose host operating systems.

Given that horsepower, programmability, and accessibility, you know what happens next in this film.

Computer science researchers recently demonstrated the harnessing of the GPU to dramatically shift the balance in the age old battle between malware and anti-malware: detect and avoid detection. The basic ideas are to hide malware within GPU-resident programs, use GPU resources to unpack encrypted malware (note: decryption keys are absconded in private GPU memory), and even use the GPU to launch attacks–such as brute forcing passwords–against security defenses. By using the GPU, malware avoids anti-X, traditionally designed to monitor and analyze software and hardware within the host complex. GPU malware can screen scrape sensitive information and store it for future nefarious purposes. If the malware can exploit one of the many vulnerabilities enabling escalated privilege in general purpose operating systems, then the malware can phone home with your secrets using the computer’s networking facilities.

If that seems far fetched, check out this report on infected disk drives which did exactly that. Yes, that disk drive is another actor in this horror flick–it too is a privileged bus master containing microprocessor, memory, and sophisticated software.

The aforementioned research is not the first time a GPU has been used to circumvent system security–Green Hills researchers found a way to use a GPU to circumvent Intel VT-d DMA protections, enabling code in one virtual machine to arbitrarily access another virtual machine or overwrite and commandeer the system hypervisor–that is, if you apply VT-d in a naive way (the weakness does not affect the Green Hills hypervisor). Green Hills reported the problem to Intel which has since acknowledged the hardware limitation.

The key message here is that system security depends on a complete understanding and management of all security-relevant platform hardware/software/firmware. In today’s modern embedded SoCs, that’s often a lot of popcorn to chew. Sorry, no free admission.

The protection profile that specifies the highest Common Criteria security level for any software on the planet has more than 30 extended (not part of the standard Common Criteria menu) requirements relating to platform assurance.

While formal methods are not feasible for a multi-billion transistor processor, the platform software vendor can achieve high assurance by managing hardware extremely carefully. We avoid parts of the hardware that are hopelessly insecure. We configure and use hardware with least privilege and mandatory mediation to prevent what would otherwise be easy to abuse. We're not talking about setting some knobs and options, we're talking a thorough, deep understanding of every single processor, co-processor, interconnect, and peripheral capability that could impact system security. Anything less is a Kill Bill.

Dave Kleidermacher is CTO of Green Hills Software. He writes about security issues, sharing his insights on techniques to improve the security of software for highly critical embedded systems.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.