Ensure that guests cannot communicate with GPU media engines #8984
Labels
C: GPU acceleration
C: tests
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
security
This issue pertains to the security of Qubes OS.
waiting for upstream
This issue is waiting for something from an upstream project to arrive in Qubes. Remove when closed.
How to file a helpful issue
Qubes OS release (if applicable)
R4.3, hopefully
Brief summary
On both Intel and AMD, the media engines use closed-source firmware to parse certain media headers. These headers come from the media file and so are completely untrusted. Unfortunately, this firmware likely runs with very high privileges and is almost certainly written in a memory-unsafe language. Therefore, this parsing is a serious security risk.
To eliminate this attack surface, it is necessary to ensure that the firmware does not parse these headers unless they have first been validated. This means that guests must not be allowed to interact with the media engines. My understanding (per discussions with @robclark) is that on at least AMD GPUs, media engine submission uses different queues than are used for the rest of the GPU, so enforcing these restrictions is feasible. Ideally, they would be enforced by the kernel-mode driver, but it is also sufficient to enforce them in the virtio-GPU native context implementation.
@robclark has expressed interest in using this feature in ChromeOS, and I suspect @alyssais will want to use it in Spectrum.
Exposing the GPU media capabilities is highly desirable. This issue does not mean that hardware media decoding will not be supported. It merely means that hardware media decoding will need to be exposed via a different interface, one that validates all input before the GPU firmware sees it.
The text was updated successfully, but these errors were encountered: