》 TLB 是为了增加访问内存的效率

即如果是 29 9 12 分页请求数据可能需要访问 4次内存；为了解决这个问题；出现了 TLB （虚拟地址到物理地址的转换关系），如果目标地址在TLB缓存中，那么直接从TLB 取出物理地址；

》这个实验做起来很麻烦,因为：

TLB 是CPU 内部的，没法通过汇编指令访问TLB；

调试器，也没有办法知道 TLB 中有哪些项

只有通过实验现象结果，来证明其存在。

内存访问的步骤：

》注意 TLB 产生异常 3；不会回到 2；而是产生 0x0E 异常。

1 简单实验查看快表带来的影响：

图解：

代码：

效果：

蓝屏：

太快了。。。截图不到。。。额

解决蓝屏：

由于是对同一个物理页释放了两次造成了蓝屏；

所以保存好原来的pte值；

所以在中断返回之前，将那个虚拟页的 pte 修改回来即可

刷新TLB，解决结果和我们预期差异

这个cr3 的切换会导致没有 g 属性的tlb 失效。即清除；

原因很简单，因为这个 cr3都切换了 tlb 中的虚拟地址没有g属性的；已经在当前cr3 中没有意义了。虽然这里切换的是自己的，但是一样可以达到效果。

改后的代码：

之后的效果：

数据正确了，而且没有蓝屏

2 有G属性的TLB 项

查看 pte 有无G位：

一般3环的 pte 没有G位。内核属性为 G位这样TLB 就不会被刷新出去。

设置我们3环的页G位有效--不被刷出TLB:

代码：

测试结果：

果然 G位的TLB 不会被刷新出去：

当然还可以强行更新 TLB 项，无视G位：

这时候 TLB 中就没有之前那个虚拟地址的TLB 虚拟项了。这时候就是正常的值了。

利用：inline Hook

前面我们 hook 系统函数 systemfastcallentry 是修改 cr0 无视 WP位页写保护。

现在我们可以使用直接修改 systemfastcallentry( ) 所在的pte；为可写的状态；并且使用强行刷新TLB 将那个pte在TLB中的数据刷新

15_TLB中的G属性