一、kmem -s 查看slab
1 2 3 4 5 6 |
|
二、kmem -S 查看slab中详细内容
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
request_sock_TCP 是 struct request_sock 类型,所以对于已分配的地址可以直接查看
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
request_sock_TCP 是 struct request_sock 类型,所以对于已分配的地址可以直接查看
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
http://blog.csdn.net/justlinux2010/article/details/21028797
1
|
|
或
1
|
|
上面的命令也是从/proc/net/tcp
和/proc/net/tcp6
中读取的
/proc/net/tcp中的内容由tcp4_seq_show()函数打印,该函数中有三种打印形式,我们这里这只列出状态是TCP_SEQ_STATE_LISTENING或TCP_SEQ_STATE_ESTABLISHED的情况,如下所示:
http://security.tencent.com/index.php/blog/msg/38
简单地说,bootloader 就是在操作系统内核运行之前运行的一段小程序。通过这段小程序,我们可以初始化硬件设备、建立内存空间的映射图,从而将系统的软硬件环境带到一个合适的状态,以便为最终调用操作系统内核准备好正确的环境。
Android系统基于Linux,所以bootloader部分也是与传统的嵌入式设备上运行的Linux没有什么区别。由于除Google外的大部分Android厂商都没有提供bootloader的源代码,所以分析手机设备的bootloader需要使用逆向工程的手段,当然由于有了Google官方的开源bootloader代码做参考,能让分析工作轻松不少。本文中使用的分析工具为IDA 6.5,针对的手机设备为N9006,固件版本为N9006ZCUDMK2。
这部分会以高通MSM8960为例子介绍下Bootloader的典型结构。
高通MSM8960中包含多个运算单元,分别负责引导过程中的不同功能,sbl1的代码负责加载sbl2,sbl2加载tz和sbl3,sbl3加载apppsbl,appsbl加载HLOS。
图1 SecureBoot 3.0 的Code Flow
图2 MSM8960引导过程简化流程图
国行版Note3(N9006)使用的CPU是MSM8974,它的bootloader结构与典型的MSM8960差不多,最大的区别就是把sbl1,sbl2,sbl3整合进了一个文件sbl1中,TrustZone和APPSBL都由sbl1进行验证和加载,以下为几个主要功能的加载代码分析。
sbl1的功能是对硬件进行初始化并加载其他模块,需要加载的模块信息按顺序保存在sbl1中,对应每个模块的数据是一段大小为0x64字节的模块信息数据内,sbl1中有一个循环负责验证和加载所有需要的其他模块(tz,rpm,wdt,appsbl),加载代码会根据模块信息内的数据调用不同的加载器加载和验证的代码,具体代码如下图。
图3 sbl1中循环加载全部模块的代码
图4 sbl1中对待加载模块进行验证
图5 TZ模块信息数据
图6 APPSBL模块信息数据
固件包里的tz.mbn是加载在TrustZone中的模块,模块格式为elf,这个模块中的代码和系统其他模块代码运行在互相隔离的区域内,权限也比其他模块更高,三星KNOX的很多底层安全特性也是在这部分中实现,关于TrustZone的更多资料可以参考arm官方的说明。
固件包里的aboot.mbn就是APPSBL模块,模块格式为bin,文件最前面的0x28字节的头部描述了bin的加载地址等信息,后面的数据就是实际加载到内存中的映像,整个bootloader中这个模块的代码量最大(很大一部分是openssl的代码),linux内核的验证和加载(正常启动和Recovery模式),ODIN模式等等代码都包含在这个模块内。
图7 aboot.mbn文件头
图8 根据按键和共享内存中的数据确定引导模式
图9 三星特有的ODIN刷机模式代码
Note3提供了一个企业安全套装KNOX,这个系统包含了底层的Customizable Secure Boot和TrustZone-based Integrity Measurement Architecture(TIMA,目前为2.0版本),系统层的SecurityEnhancements for Android(SE-Android)和应用层的Samsung KNOX Container,Encrypted File System(EFS),Virtual Private Network(VPN),其中Customizable Secure Boot和TIMA的代码包含在Bootloader的aboot.mbn,tz.mbn,NON-HLOS.bin中,功能为保障加载的内核在加载时和运行期的完整性。
通过前面的分析,我们已经知道了tz.mbn和aboot.mbn在加载时已经由sbl1验证过完整性,tz.mbn加载后会在CPU的安全环境下运行,从高权限的隔离区域内对系统的完整性进行监控,而负责加载android内核的aboot.mbn中包含对内核的完整性检测,三星在bootloader每一部分的结尾都会加上自己的签名,加载前会对签名进行验证,以保障系统未被修改过。
图10 tz.mbn中初始化TIMA系统的的代码
图11 aboot.mbn中对内核是否使用SEANDROID进行验证
当任何一部分检测代码发现系统异常状况后,就会调用SMC指令通知TrustZone中运行的TIMA系统设置fuse为系统完整性被破坏,此fuse数据一旦被设置后没有办法被重置,系统也无法再次进入KNOX系统。
图12 加载内核前对内核签名和TIMA的测点进行验证
图13 系统完整性检测失败后设置fuse值
当以上所有检测都通过后,bootloader会把内核复制到指定的内存地址并跳到内核的入口继续执行,到此,就进入了系统内核代码的范畴,bootloader的使命也就完成了,跳到linux内核入口的代码见图14。
图14 内核加载和校验完成后跳到内核的入口点继续执行
另外,除了这两个模块外Modem固件相关的NON-HLOS.bin中也有大量TIMA系统相关的文件,由于TIMA系统包含大量硬件相关代码(使用三星猎户座CPU的N900中TIMA系统的实现与高通CPU的N9006差别很大),如果需要进行进一步的分析TIMA在modem中的行为,需要对TrustZone,modem工作方式等有更多了解。
图15 NON-HLOS.bin中包含的大量TIMA相关文件
http://www.cnblogs.com/super-king/p/ipv6_implement.html
code extract from 2.6.24. 在文件 net/ipv6/af_inet6.c 中包含了ipv6协议初始化的主函数。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 |
|
下面我们主要看ipv6协议部分流程,其他部分在各自相关文章中介绍。
ipv6扩展头,路由包头注册
1 2 3 4 5 |
|
ipv6扩展头,分片包头注册
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
ipv6扩展头,目的选项包头注册
1 2 3 4 5 6 7 8 9 10 |
|
当netif_receive_skb函数向上层递交skb时会根据协议类型调用相关的协议处理函数,那么就会调用到 ipv6_rcv函数了。
1 2 3 4 5 6 |
|
ipv6协议处理函数
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 |
|
解析扩展头逐个跳段中的巨量负载选项
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
解析tlv编码的扩展选项头
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
|
处理未知的选项
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
到这需要解释一下,上面解析ipv6选项只是解析了第一层的扩展头,在后面可能还有其他扩展头会在后面解析。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
现在我们假设包是到本地的,那么上面的input函数就是
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 |
|
1 2 3 4 5 6 7 8 9 10 11 |
|
解析路由警告选项
1 2 3 4 5 6 7 8 9 10 11 12 |
|
解析jumbo frame选项
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
|
目的选项处理
1 2 3 4 5 6 7 8 9 |
|
解析目的选项
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
|
我们只介绍根ipv6扩展头相关的实现,像其他的扩展头(tcp, udp)等虽然也是叫扩展头但实际是传输层的内容,将在其他文章中介绍。
路由扩展首部
1 2 3 4 5 6 7 8 |
|
路由扩展首部处理结构
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 |
|
ipv6分配包扩展首部处理
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 |
|
创建分片队列
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
|
入队重组
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 |
|
重组ip头
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 |
|
1 2 3 4 5 6 7 8 9 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|
http://simohayha.iteye.com/blog/503856
我们这次主要来分析相关的两个断开函数close和shotdown以及相关的套接口选项SO_LINGER。这里要注意SO_LINGER对shutdown无任何影响。它只对close起作用。
先来坎SO_LINGER所对应的数据结构:
1 2 3 4 5 6 |
|
这里对这个套接口选项就不详细介绍了,在unix网络编程中有详细的介绍,我们这里只会分析内核的处理代码。
首先来看close函数,我们知道缺醒情况下,close是立即返回,但是如果套接口的发送缓冲区还有未发送的数据,系统将会试着把这些数据发送给对端。而这个缺醒情况我们是可以通过SO_LINGER来改变的。还有一个要注意就是close调用并不一定会引发tcp的断开连接。因为close只是将这个socket的引用计数减一(主要是针对多个进程),而真正要直接引发断开,则需要用shutdown函数。
内核中socket的close的系统调用是sock_close,而在sock_close中,直接调用sock_release来实现功能,因此这里我们直接看sock_release的源码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
|
然后来看inet_release的实现,这个函数主要用来通过SO_LINGER套接字来得到超时时间,然后调用tcp_close来关闭sock。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
tcp_close函数比较长我们这里分段来分析它,首先来看第一部分。这里要注意几点:
1 当close掉一个服务端的父socket的时候,内核会先处理半连接队列然后是已经accept了的队列,最后才会处理父sock。
2 处理接收缓冲区的数据的时候,直接遍历receive_queue(前面blog有介绍),然后统计未发送的socket。我们知道close是不管接收buf的,也就是他会把接收buf释放掉,然后发送rst给对端的。
3 当so_linger有设置并且超时时间为0,则发送rst给对端,并且清空发送和接收buf。这个也不会引起最终的四分组终止序列。
4 当接收缓冲区有未读数据,则直接发送rst给对端。这个也不会引起最终的四分组终止序列。
5 当so_linger有设置,并且超时不为0,或者so_linger没有设置,此时都会引起最终的四分组终止序列来终止连接。(通过send_fin来发送fin,并引发四分组终止序列).而在send_fin中会发送掉发送缓冲区中的数据。
来看代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
|
1 2 3 |
|
ok,现在来看上面遇到的3个函数,一个是inet_csk_listen_stop,一个是tcp_close_state,一个是tcp_disconnect.我们一个个来看他们。
首先是inet_csk_listen_stop函数。我们知道这个函数主要用来清理所有的半连接队列。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
接下来来看tcp_disconnect函数。这个函数主要用来断开和对端的连接.它会释放读写队列,发送rst,清除定时器等等一系列操作。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
|
紧接着是tcp_close_state函数这个函数就是用来判断是否应该发送fin:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
接下来来看tcp_close的剩余部分的代码,剩下的部分就是处理一些状态以及通知这里只有一个要注意的就是TCP_LINGER2这个套接字,这个套接字能够设置等待fin的超时时间,也就是tcp_sock的域linger2.我们知道系统还有一个sysctl_tcp_fin_timeout,也就是提供了一个sys文件系统的接口来修改这个值,不过我们如果设置linger2为一个大于0的值的话,内核就会取linger2这个值。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
|
然后来看send_fin的实现,这个函数用来发送一个fin,并且尽量发送完发送缓冲区中的数据:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
|
这里我们要知道shutdown会将写缓冲区的数据发出,然后唤醒阻塞的进程,来读取读缓冲区中的数据。
这个系统调用所对应的内核函数就是os_shutdown_socket。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
来看inet_shutdown的实现.这个函数的主要工作就是通过判断sock的状态不同来调用相关的函数:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 |
|
来看tcp_shutdown函数。
这里要注意,当只关闭读的话,并不会引起发送fin,也就是只会设置个标记,然后在读取数据的时候返回错误。而关闭写端,则就会引起发送fin。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
最后来看sock_def_readable它就是sk->sk_state_change。也就是用来唤醒阻塞的进程。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
可以看到shutdown函数只会处理SEND_SHUTDOWN。并且当调用shutdown之后,读缓冲区,还可以继续读取。