15_TLB中的G属性

》 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中的数据刷新