For software that process untrusted data and have an option to use hardware acceleration, does enabling hardware acceleration increase the attack surface of the software? Examples of situations where typical software process untrusted data: using a web browser to access websites on the internet, using a video player to play videos downloaded from the internet, importing media assets downloaded from the internet into a 3D modeling/rendering software, etc.

In terms of Linux AppArmor confinement, my guess is that disabling hardware acceleration reduces the attack surface of software. This is because software that does not use hardware acceleration can be confined more tightly (i.e. granted less access to files) than software that do use hardware acceleration. However, I am not sure whether or not this reasoning is valid outside the context of Linux AppArmor.

1 Answer 1


The attack surface is increased if the hardware acceleration adds more complexity than the previously used software implementation - since more complexity makes bugs more likely. This might be true in some cases, but is not true in general.

The attack surfaces increases also if the hardware acceleration changes the isolation properties, for example if due to the way the acceleration works in or due to bugs in the implementation a process can now derive, access or modify data belonging to another process, another user or maybe even belonging to the kernel. This could be direct access but it could also be the side channel attacks like mentioned in Modern GPUs vulnerable to new GPU.zip side-channel attack.

And even if not increasing the attack surface the hardware acceleration might lead to a different threat analysis. This is specifically true if the software implementation is open source, comes from a trusted vendor, is widely used and well tested or is somehow certified - while the hardware implementation is closed, less well tested and on has to blindly trusted the vendor. This is for example relevant with critical components like hardware accelerated cryptography.

A more general pattern might also be that the implementation of hardware acceleration is designed for speed and is usually also much more restricted by memory constrains for code and data than a software implementation would be. This is often an anti-pattern for security, i.e. there will be unchecked assumptions about the validity of data, boundary checking will be skipped since the data are assumed to be valid etc. This anti-pattern have been seen in the past with audio and video codec implementation in software, which were often developed with similar constraints but slowly get better. But lots of critical bugs came from this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .