mmap

正好遇到 华庭（庄命强）的glibc内存管理Ptmalloc2 源代码分析 一文，非常开心。真是大佬。我只是借着这篇文章稍微整理一下，为了以后自己回顾的时候能够更好的排查问题。 6.1 linux进程内存布局 x86 平台 Linux 进程内存布局   Linux 系统在装载 elf 格式的程序文件时，会调用 loader 把可执行文件中的各个段依次 载入到从某一地址开始的空间中（载入地址取决 link editor(ld)和机器地址位数，在 32 位机 器上是 0x8048000，即 128M 处）。如下图所示，以 32 位机器为例，首先被载入的是.text 段， 然后是.data 段，最后是.bss 段。这可以看作是程序的开始空间。程序所能访问的最后的地 址是 0xbfffffff，也就是到 3G 地址处，3G 以上的 1G 空间是内核使用的，应用程序不可以直 接访问。  &emsp应用程序的堆栈从最高地址处开始向下生长，.bss 段与堆栈之间的空间是空闲的， 空闲空间被分成两部分，一部分为 heap，一部分为 mmap 映射区域，mmap 映射区域一般 从 TASK_SIZE/3 的地方开始，但在不同的 Linux 内核和机器上，mmap 区域的开始位置一般是 不同的。Heap 和 mmap 区域都可以供用户自由使用，但是它在刚开始的时候并没有映射到 内存空间内，是不可访问的

启用swoole时报的错误，可以确定是内存问题 [2019-04-09 09:04:32 @220.0] WARNING swShareMemory_mmap_create: mmap(260046944) failed. Error: Cannot allocate memory[12] [2019-04-09 09:04:32 @220.0] ERROR calloc[1] failed 我们查看下内存： [root@VM_0_17_centos docker]# free -m total used free shared buff/cache available Mem: 992 495 85 116 412 216 Swap: 0 0 0 swap全都是0明显有问题，那就加点swap： sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 #增加1G的 sudo mkswap /swapfile sudo swapon /swapfile [root@VM_0_17_centos docker]# free -m total used free shared buff/cache available Mem: 992 494 72 116 426 217 Swap: 1023 419 604 然后就顺利启用swoole了。

glibc下的内存管理 几周前我曾提到，我被项目组分配去做了一些探究linux下内存管理机制的活儿。因为我们的产品遇到了一些与之相关的“诡异”问题。这些问题以及相关情况可以概括如下： 先介绍一下相关的背景。由于我们是3D软件，所以用户经常会有“导入/导出”各种geometry的需求。而一个存储这些数据的文件，可能含有不止一个geometry，而且每个geometry中也可能存在着成千上万个面片/多边形等各种基本元素。这些元素本身都不大，但数量很多。 第一次导入geometry时，会占据大量内存（比如说吧，有1.5G）以上；在不关闭软件而进行各种“清理”操作后，内存却基本不释放；接着再次导入相同的geometry时，内存也没有明显增加；然而如果再进行一次导入操作的话，内存又会被大量占用（约1G以上）。 将以上试验，换成先导入geometry1, 然后清理场景, 再导入geometry2，此时geometry2的内存占用量，要比单独首次导入geometry2时所占用的内存量要小。 valgrind是一款在linux下经常使用检查各种内存管理问题的工具集合。我们用valgrind的memcheck组件进行过专门的内存泄露测试，并未发现明显的泄露情况。 我们的产品在mac平台上也有相应的版本。拿到mac os x上做实验，发现同样的代码，表现并不相同。其中每次清理场景后，都会有可观的内存

一、底层结构 采用三层结构，实际使用中可以方便映射到两层或者三层结构，以适用不同的硬件结构。最下层的申请内存函数get_free_page。之上有三种类型的内存分配函数： 1.kmalloc类型。内核进程使用，基于切片（slab）技术，用于管理小于内存页的内存申请。思想出发点和应用层的内存缓冲池同出一辙。但它针对内核结构，特别处理应用场景固定，不考虑释放。 2.vmalloc类型。内核进程使用。用于申请不连续内存。 3.brk/mmap类型。用户进程使用。malloc/free实现的基础。 二、内存管理的相关函数图 STL -> 内存自动分配和自动回收（C++） | C++ -> new分配内存，delete回收内存 | C -> malloc分配内存，free回收内存 | Unix 系统函数 -> sbrk/brk 分配和回收内存 | Unix底层系统函数 -> mmap/munmap分配回收 （用户层） ---------------------------------------------------------------------------- （内核层） Unix内核函数 kmalloc/vmalloc/get_free_page 三、进程与内存 a.所有进程（执行的程序）都必须占用一定数量的内存 b.对任何一个普通进程来讲，它都会涉及到5种不同的数据段

之前看了《 新爆内核高危漏洞sock_sendpage的利用分析的讨论 》这篇帖子，在九贱兄和诸位CUer的指引下，大致弄清了整个漏洞的始末。现与大家分享（引用自 我的空间 ）。 有什么不足之处还望多多指教~ 内核的BUG 这个BUG首先得从sendfile系统调用说起。 考虑将一个本地文件通过socket发送出去的问题。我们通常的做法是：打开文件fd和一个socket，然后循环地从文件fd中read数据，并将读取 的数据send到socket中。这样，每次读写我们都需要两次系统调用，并且数据会被从内核拷贝到用户空间(read)，再从用户空间拷贝到内核 (send)。 而sendfile就将整个发送过程封装在一个系统调用中，避免了多次系统调用，避免了数据在内核空间和用户空间之间的大量拷贝。 ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); 虽然这个系统调用接收in和out两个fd，但是有所限制，in只能是普通文件，out只能是socket（这个限制不知道后来的内核版本有没有放宽）。 sendfile系统调用在内核里面是怎么实现的呢？这个还是比较复杂，它在内核里面做了原来要在用户态做的事情：创建一个pipe对象作buffer用、从in_fd中读数据到pipe中、将pipe中的数据写到out_fd

kernel 最近出了一个新的本地提权安全漏洞CVE-2013-1763，影响范围比较广泛，ubuntu，Arch，fedora都受到其影响，漏洞刚公布就有牛人发布了利用该漏洞获取root权限的攻击代码，下面会分析该代码是如何获取root权限的。 首先对CVE-2013-1763这个安全漏洞简单介绍一下。 1. 漏洞描述 在net/core/sock_diag.c中，__sock_diag_rcv_msg函数未对sock_diag_handlers数组传入的下标做边界检查，导致可能越界，进而导致可执行代码的漏洞。没有root权限的用户可以利用该漏洞获取到root权限。 2. 漏洞的影响范围 linux kernel 3.0-3.7.10 3. 漏洞曝光时间 2013/02/19 4. 漏洞产生的原因 首先看一下这个漏洞的patch： 1 2 3 4 5 6 7 8 9 10 11 net/core/sock_diag.c View file @ 6e601a5 @@ -121,6 +121,9 @@ static int __sock_diag_rcv_msg( struct sk_buff *skb, struct nlmsghdr *nlh) if (nlmsg_len(nlh) < sizeof (*req)) return -EINVAL; + if (req->sdiag

跨进程读写内存想要高效，肯定是能不加锁就不加锁，进程锁对效率有很大影响。 通常进程之间交换数据最快就是共享内存了，于是写了关于如下测试程序，只是实现一个进程写，一个进程读的单生产单消费者模型 测试不休息，一秒可传输30万次，虽然不如线程之间高效，但在进程之间还可以吧 import time import random from multiprocessing import Process import mmap class Write(Process): def __init__(self,name,share_memname): super().__init__() self.name=name self.share_memname = share_memname self.share_memlen= 100 def run(self): self.process_run_init() start_time = time.time() for i in range(0,100000): bytes_buffer = str(i).encode('UTF-8') self.write(bytes_buffer) self.wait_read() end_time = time.time() print(end_time-start_time) def write(self

mmap函数下段，然后F9运行断下，然后F8往下，一直运行到这里： F7进来，在R2寄存器这里打一个断点： F9运行到这里，然后F7进来； F8往下走，这里有比较指令： 这个函数的返回值在R0里面存储，（可以直接把光标放在cmp那条指令然后F4跳过去 ） 把R0置零： 置零之后呢，F9： 再一次F8：继续在mmap函数末尾断下，然后继续F8：来到这里： 紧接着F9，继续来到mmap 然后继续F8：发现还是libc.so，继续F9，然后F8，知道来到libjiagu.so： （注意，这是第二处反调试的点，虽然后逻辑代码和第一处的一样，但是是不同的区段，所以还需要进去看看是不是上一次哪两个下断的函数，不要直接f9,以为和第一次一样，不一样！） 继续F8往下，来到这里： 然后F9在这里断下： 然后F7进去，然后F9在这个 LR 处断下， 然后F7进去：进去后一路F8，继续来到cmp比较指令， 继续修改上面函数的返回值R0寄存器的值；从而过掉反调试 直接置零即可； 修改后，继续F9：在mmap函数处断下： 同样的，继续往下走，来到libjiagu.so，来时和上面一样，来到这里比价的地方：这是第三次修改R0 和cmp处比较： 继续F9，在mmap函数处断下，然后在函数头位置下一个断点； 然后ctrl+S,可以看一下各个区段： 到这里，已经三次反调试的点已经过去了，现在要做的