现代 Linux GPU 驱动程序的安全性如何？
威胁模型是可以在非特权用户进程的上下文中执行任意代码的攻击者，该进程被 seccomp-bpf、命名空间和其他机制严重锁定。具体来说，它有一个到 GPU 的打开文件描述符，一个到默认帧缓冲区，一个到一个匿名文件/tmp（用于分配内存）。它无法打开任何文件或执行分配堆内存或使用 GPU 不需要的任何系统调用。
现代桌面 Linux GPU 驱动程序是否足够安全以提供针对恶意用户程序的隔离？
我希望使用它的目标应用程序是 Qubes OS，它目前只能使用 GPU 进行合成，因此安全级别需要与 Xen 管理程序提供的安全级别相当，否则这个想法是行不通的。
现代 GPU 驱动程序（不仅限于 Linux）确实非常不安全。应用程序与 GPU 通信的方式是通过Direct Rendering Manager或 DRM 接口，使用ioctl(2). 这些系统调用用于在用户空间和内核之间传递对复杂数据结构的引用。DRM 接口以两种字符设备的形式提供：
主节点，处理特权操作（例如显示控制）。它作为字符设备公开/dev/dri/cardX。它通常只能由video组中的用户写入。该设备传统上由 X 服务器保持打开状态，它使自己成为DRM 主控。DRM 主节点具有相当大的攻击面并使用复杂的 API。
渲染节点，通常处理非特权操作（例如 GPGPU 计算和渲染）。它作为字符设备公开/dev/dri/renderDX。尽管只处理非特权操作，但该设备具有相当大的攻击面。
DRM 节点的权限检查是在打开设备文件时完成的，但有一些例外。一旦文件描述符出现，任何在其集合中具有该描述符的应用程序都将能够向图形子系统发送任意特权命令。这意味着一旦您的不受信任的进程对 DRM 节点具有有效的文件描述符，您的隔离就会结束。图形子系统的安全性取决于 DRM 层（具有非常复杂的接口）的安全性，以及图形驱动程序本身定义的特定于硬件的接口。不同的驱动程序定义了不同的接口，其中一些比其他的更复杂。
你说你正在使用 seccomp-bpf。这很好！您将能够大大减少复杂图形子系统中固有的安全问题。确保您正在过滤针对 DRM 节点调用的任何 IOCTL。将允许 IOCTL 发送的命令列入白名单。尽管您无法将传递给内核的数据结构列入白名单，但将整个命令列入白名单通常就足够了，并且会大大减少攻击者可用的表面积。
严重的图形驱动程序错误列表远非详尽：
现代 x86 硬件是一头可怕的野兽。它很复杂，并且在设计时没有考虑到安全性。即使没有驱动程序软件漏洞，GPU 仍然可以构成威胁，这仅仅是因为它们的复杂性以及与复杂的计算机体系结构的交互，通过由会员制数千页长的规范管理的神秘协议。安全是硬™。