Speaker
Description
In the context of a web browser, GL and Vulkan drivers are exposed to hostile content, in the form of webgl and webgpu. In the case of Vulkan, the spec explicitly declares that invalid usage is undefined behavior. But even for a GL driver it isn't so hard to find a way to trigger a potentially exploitable crash. The browser can sandbox the usermode gl/vk driver (UMD) into it's own process with limited privileges. But the UMD still needs access the drm kernel driver (KMD).
Or does it? Building on, and re-using, the drm native-context approach for running native UMD in a VM guest, tunneling the interface to host KMD over virtgpu, we can split kernel access into a hardened helper process with minimal performance penalty. In this way, if (when) an attacker achieves code execution in the UMD, they do not have a clear path to chain that exploit with a kernel bug to achieve code execution in the kernel.
Code of Conduct | Yes |
---|---|
In-person or virtual presentation | In-person |
GSoC, EVoC or Outreachy | No |