From 183b1963ff91368e339cdcf7e9b19611ce87f9bf Mon Sep 17 00:00:00 2001 From: gameloader Date: Tue, 5 Apr 2022 21:54:43 +0800 Subject: [PATCH] change picture url --- content/posts/UAFpaper.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/content/posts/UAFpaper.md b/content/posts/UAFpaper.md index 8ceedd6..270f702 100644 --- a/content/posts/UAFpaper.md +++ b/content/posts/UAFpaper.md @@ -64,7 +64,7 @@ UAF的根本成因在于攻击者可以重新声明被释放的内存并修改 ### Metadata of Allocations {#metadata-of-allocations} 该部分是为了实现这种内存分配所定义的数据结构。首先需要弄清楚几个结构之间的关系,即pool,allocator,page,chunk。small被定义为less than half a page。其余为large。 -![](https://images.gitee.com/uploads/images/2021/1115/230444_15dde024_8810712.png) +![](https://testingcf.jsdelivr.net/gh/game-loader/picbase@master/uPic/0405oUDNko.jpg) ### Freeing Memory {#freeing-memory} @@ -93,7 +93,8 @@ realloc 允许程序改变现有的已分配区块的区块大小,如果变小 ### FCmalloc {#fcmalloc} FCmalloc是OTA最简单的实现方式,处理内存请求时的内存分配一直是连续的,内存页不够用就调用mmap分配新的内存页,对于free请求,只有当一整页的内存都被free,才调用munmap释放该页。但是这种分配方式最严重的问题就是造成的系统开销过大。在gcc benchmark中,对一个c-typeck的输入文件,使用FCmalloc和glibc的malloc会产生60.2%的mmap munmap系统调用开销,严重的内存开销,还有对系统VMA结构的浪费。Linux限制每个进程最多创建65535个VMA结构体。下图显示了FCmalloc的VMA浪费情况 -![](https://images.gitee.com/uploads/images/2021/1116/193553_7629c96a_8810712.png) + +![](https://testingcf.jsdelivr.net/gh/game-loader/picbase@master/uPic/0405uOB3xk.jpg) 针对FCmalloc的这些问题,作者提出了一种解决方案,即Batch Processing。当请求内存时,调用mmap一次请求多页,然后交由FCmalloc来分配请求的这些页,直到所有内存页都被用完,才再次请求。对于free同理,等待连续多页要free时才调用munmap free全部页。取得的改进效果是非常突出的,同样的gcc benchmark,可以节省58.7%的munmap调用和65.8的VMA开销。 @@ -113,7 +114,8 @@ FBmalloc的设计思想通常被称为BiBop allocator.其采用的方法与FCmal 通过上面的叙述,FFmalloc的具体原理已经很清楚了。那么他与现有glibc中malloc的差别在哪里,我们通过对两者内存分配流程解析来对比下FFmalloc的独特之处。 malloc同样使用了pool来管理内存,最重要的就是bin,内存池保存在bins这个长128的数组中,每个元素都是一双向个链表。 -![](https://images.gitee.com/uploads/images/2021/1117/191042_0fccb166_8810712.png) + +![](https://testingcf.jsdelivr.net/gh/game-loader/picbase@master/uPic/0405pfsxy6.jpg) - bins[0]目前没有使用 - bins[1]的链表称为unsorted_list,用于维护free释放的chunk。