最近的一篇文章提示了该材料的准备工作：“ 视频卡驱动程序错误可能会显示以隐身模式查看的内容。”这篇文章是在发布用于显示属于任何（包括终止的）过程的图像的普通方法之后诞生的，甚至可能声称可以保护信息。由于我也参与了图形驱动程序的开发，因此，我将尝试简要地解释一下原始错误报告的作者存在的问题，问题的责任以及如何解决。
无论使用什么操作系统，其相关的系统API和用于开发图形应用程序的应用程序接口，任意视频卡驱动程序都可以解决以下系统范围的任务：- 显示控制器的初始化（设置视频模式，管理GPU端口，形成一个/几个独立的图像等）；
- 可寻址内存管理（命令队列，线性/图块寻址，表面分配，地址转换表，PCI孔径扩展等）；
- 2D加速（光标，硬件层，alpha /色度键，ROP，基元等）；
- 3D加速（OpenGL，OpenGL ES / EGL，OpenVG / EGL，OpenCL，Open *）;
- 视频解码/音频播放/ EDID减法/帧缓冲区压缩，...
解决每个阶段所应用任务的方法早已被简化为既定做法。这仅说明了所说明问题在各种制造商的设备上的可重复性。展望未来，我可以说您可以在Intel控制器上获得类似的效果。错误报告的作者在会产生问题的解决方案的框架中绝对准确地确定了-可寻址内存管理。
记忆体管理
驾驶员在此阶段操作的主要实体是表面。表面通常称为连续的视频或RAM，用于通过某些应用程序形成图像。对于没有自己的内存的控制器，从RAM分配的资源可以通过地址转换表（图形转换表，GTT）进行寻址。否则，仅当通过DMA控制器（如果有）或由于CPU资源而将表面复制到视频内存中时，才能显示图像。实际上，即使在大多数情况下甚至具有自己的离散存储器的控制器也可以通过GTT对其进行寻址，因为这样可以通过类似于中央处理器TLB的方式创建虚拟地址空间，以提供线性或切片寻址。在每种情况下，寻址方法都决定了驱动程序，并且在本文的框架中它们之间没有根本区别。图形控制器驱动程序是OS与GPU功能的接口，仅此而已。确保信息保护的所有任务都分配给对此负责的任何更高级别。为此，驱动程序具有所有可用的功能，因此希望使用它。因此，应某些客户端驱动程序的请求，操作系统为其保留（分配）了一组表面。根据作者的说法，由于图像的碎片化相对较少，因此我们可以争辩说在这些情况下不经常使用图块寻址。使用线性寻址时，每个表面的主要特征是与控制器存储器的虚拟地址空间的起始位置偏移。当分配内存时，驱动程序将恰好将此偏移量返回给OS，该偏移量对应于一个可用的内存块，该内存块可以容纳具有应用程序软件所要求特性的表面。在这种情况下，驱动程序仅执行以下操作：修改GTT以进一步使用虚拟内存页，监视对物理地址对齐要求的遵守情况，定义应用程序软件访问表面的机制（PCI / GPU孔径，通过孔径外部的物理地址，动态进行GTT扩展），为自身需求保留一部分内存。基于上述内容，我们可以得出结论，有了有关可用控制器内存总量和所需表面特性的信息，可以统一解决所有控制器的偏移量确定问题。实际上，是这种情况（根据各种类似Unix的操作系统的经验进行指导）：操作系统提供了系统服务/库，该服务存储了已使用的内存块的列表，并允许您快速计算该库中用于逻辑备份的第一个可用偏移量。同时，通过从驱动程序获得有关访问内存块机制的信息，OS通常允许在共享/相交表面的相同物理地址处形成应用程序软件。如果驾驶员未明确控制表面，那么如何实现加速度？. - , , ( ), .
( ) , ( ), .
回到原来的问题
可以肯定的是，许多人已经猜到了批评的根源。在执行各种应用程序时，操作系统会向视频驱动程序询问其需求，并在内存释放（进程终止）时重新使用它们。同时，驱动程序无法意识到某些内存块需要立即重置，因为它具有一定的安全要求并且没有其他链接。调零内存本身是硬件填充矩形的琐碎任务。实际上，为发布错误报告而编写的测试是多余的。在一般情况下（当视频内存适合PCI / GPU孔时），类Unix系统不需要应用程序API。使用“ lspci”实用程序的输出已知的偏移量来联系/ dev / mem就足够了。对于英特尔控制器，情况有所不同，但差别不大。由于控制器没有自己的内存，因此通过从RAM分配内存来动态形成GTT。重新分配表面时，考虑到在这种情况下OS虚拟寻址机制已经起了决定性的作用，因此对于RAM块的实际位置可能并不幸运。有几种解决方案，我相信结论将是显而易见的：- 所有驱动程序制造商都必须实现冗余功能来存储有关现有表面的信息（控制共享表面的问题仍然存在）；
- 操作系统必须监视对此应用程序进行整理的需求（这是对受保护表面的某种标记，或者是RAM和视频内存中任何表面的过度清零）；
- 应用软件自称应该参与信息安全性，因此应正确清理自己。
希望该笔记有趣。