能力值:
( LV1,RANK:0 )
|
-
-
151 楼
1.每一次对Hook函数地址的读/写/执行都会触发一次内核陷入,TLB刷新,CPU周期耗时远大于正常代码页 2.在 wake_up_new_task 手动克隆幽灵内存、Shadow配置短时间连续fork产生大量子进程,子进程缺页异常时延同样异常 3.高频函数被HWBP断点命中时,极端场景会漏泄SIGTRAP信号
最后于 2天前
被mb_iiulbilc编辑
,原因:
|
能力值:
( LV1,RANK:0 )
|
-
-
152 楼
更致命的硬伤是架构级的缺陷:你用vmalloc分配内存,然后手动填充PTE,但刻意不挂入VMA为了过maps扫描,但内核硬性规则:mincore、process_vm_readv、mprotect等系统调用强制依赖find_vma()来校验地址合法性,难以修复的物理矛盾在于你既然没有VMA,这些系统调用必然返回-EFAULT,但你为了让Hook生效,又必须让PTE拥有READ和EXEC权限,两者在逻辑上是互斥的,系统调用说查无此页,CPU却说这页能执行,无痕Hook言过其实
|
能力值:
( LV2,RANK:10 )
|
-
-
153 楼
mark
|
能力值:
( LV1,RANK:0 )
|
-
-
154 楼
厉害
|
能力值:
( LV2,RANK:10 )
|
-
-
155 楼
支持 支持
|
能力值:
( LV2,RANK:10 )
|
-
-
156 楼
6666666666666
|
能力值:
( LV1,RANK:0 )
|
-
-
157 楼
学习一下哇
|
能力值:
( LV1,RANK:0 )
|
-
-
158 楼
666
|
能力值:
( LV2,RANK:10 )
|
-
-
159 楼
66666
|
能力值:
( LV1,RANK:0 )
|
-
-
160 楼
6666
|
能力值:
( LV3,RANK:20 )
|
-
-
161 楼
mb_iiulbilc
1.每一次对Hook函数地址的读/写/执行都会触发一次内核陷入,TLB刷新,CPU周期耗时远大于正常代码页2.在 wake_up_new_task 手动克隆幽灵内存 ...
是的,还是有待优化
|
能力值:
( LV3,RANK:20 )
|
-
-
162 楼
哈哈, ai味浓浓的哈, “架构级的缺陷”, 感谢指点. 根据我浅薄的理解, cpu取指令不查vma, mmu会根据pte把va转换为pfn+offset也就是pa, 然后cpu根据pa读/写/取指, 所以mincore/mprotect/preadv走find_vma探测不到vma和cpu能不能取指&执行疑似没有关系 
|
能力值:
( LV2,RANK:10 )
|
-
-
163 楼
66
|
能力值:
( LV2,RANK:10 )
|
-
-
164 楼
严肃学习
|
能力值:
( LV1,RANK:0 )
|
-
-
165 楼
学习学习
|
能力值:
( LV1,RANK:0 )
|
-
-
166 楼
66666666
|
能力值:
( LV1,RANK:0 )
|
-
-
167 楼
SharkFall
哈哈, ai味浓浓的哈, “架构级的缺陷”, 感谢指点. 根据我浅薄的理解, cpu取指令不查vma, mmu会根据pte把va转换为pfn+offset也就是pa, 然后cpu根据pa读/写/取指, ...
CPU 取指确实只走 MMU 查 PTE,跟 VMA 没有关系。我的观点不是没有 VMACPU 就不能执行,而是 CPU 不查询 VMA刚好让这种映射产生了两个不一致的地址空间视图,你隐藏 maps 的代价是破坏 VMA 与 PTE 的一致性,它确实能执行但能执行却不存在才是这套架构的硬伤。如果指出问题需要被打上ai标签会让你好受些那你就认为我是ai就行,但我是不是Ai都不影响问题的真假
|
能力值:
( LV1,RANK:0 )
|
-
-
168 楼
你在内存上花费的精力和时间值得赞叹,但别忘记了有些必须保持一致的地方,有些指纹检测是硬件层面的逻辑必然
|
能力值:
( LV1,RANK:0 )
|
-
-
169 楼
|
能力值:
( LV2,RANK:10 )
|
-
-
170 楼
nb
|
能力值:
( LV1,RANK:0 )
|
-
-
171 楼
666
|
能力值:
( LV3,RANK:20 )
|
-
-
172 楼
好的 谢谢哈, 讲话非常正式的感觉, 我以为是ai
|
能力值:
( LV1,RANK:0 )
|
-
-
173 楼
6666
|
|
|