Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure that guests cannot communicate with GPU media engines #8984

Open
Tracked by #8552
DemiMarie opened this issue Feb 28, 2024 · 1 comment
Open
Tracked by #8552

Ensure that guests cannot communicate with GPU media engines #8984

DemiMarie opened this issue Feb 28, 2024 · 1 comment
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.

Comments

@DemiMarie
Copy link

DemiMarie commented Feb 28, 2024

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.

@DemiMarie DemiMarie added T: task security This issue pertains to the security of Qubes OS. P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. C: GPU acceleration labels Feb 28, 2024
@DemiMarie DemiMarie moved this to Todo in GPU acceleration Feb 28, 2024
@DemiMarie
Copy link
Author

@puckipedia will likely also be interested.

@DemiMarie DemiMarie added the waiting for upstream This issue is waiting for something from an upstream project to arrive in Qubes. Remove when closed. label Jan 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
Status: Todo
Development

No branches or pull requests

2 participants