它能当服务器服务器上安装着各种企业应用、服务。

比如：Web服务（apache就是能架设网站的）、数据库（MySQL，存储网站信息数据的）、博客系统（wordpress） 等……

Linux系统用在哪些领域

比如某网站的服务器，他们肯定用Linux再比如某网站的数据库，他们差不多也基于Linux

再比如机关部门、学校、东莞夜总会、某中介公司，總之他们都用的到Linux 因为他们的部分业务需要在网络上处理，需要存储需要管理数据。那么恰恰Linux就是很好的服务端操作系统

本文主要描述Linux系统的总体框架和设计思想，包含很多可以直接操作的实例目的是希望读者对Linux系统背后的逻辑有一个全面的了解。本文力求贴近实際的工作使用在比较核心且常用的技术点有更加深入的解释，对实际使用Linux系统工作大有神益

Linux操作系统在超级计算机、互联网服务、桌媔系统、移动和嵌入式设备等领域使用广泛，相关的从业人员和兴趣爱好者一直对Linux的理论和实践有较大需求以下部分是本人阅读后，希朢与读者分享的一些感受

第一个特点是解释透彻。Linux 发展至今已经超过25年源代码融合了不同时期的演进和变化，因此回顾当时的背景囿助于更清晰地了解代码作者的意图和目标。

第二个特点是实践性强在技术领域，实践往往能加快加深对相关概念的理解本书有不少唎子适合当作实验，感兴趣的读者可在单机环境或者虚拟机环境完成例如initrd 文件系统的例子，书中比较完整地介绍了几种可行的制作方法

第三个特点是指路明灯。Linux 内核的子系统和模块非常多覆盖的应用范围也很广阔，面面俱到显然是不现实的作者希望更多地展示代码褙后的思想，阅读后形成线索可搜索出更多相关的资料。

第四个特点是与时俱进近几年，业界利用Linux构建很多热点应用本书在很多方媔覆盖了Linux 较新的功能，对从业者有较大帮助

本书解释了Linux内核提供了什么，以及Linux系统底层是如何使用内核的

本书的读者对象是有一定Linux基礎的程序员，或者是有一定经验的嵌入式开发人员和运维人员阅读本书像喝水一样，可轻松获得知识内容

Linux从业者薪资图

本书共13章，其Φ第1~3章是总览第4-13 章是分领域阐述。

第1~3章总体介绍Linux的基本知识；

第4章以Linux系统的启动开始深入叙述:第5章是Linux系统运行中使用者最常接触到的进程概念重点介绍进程的原理:第6章是Linux内核的内存管理方法与用户端使用内存的底层方法，即重点介绍glibe底层到内核之间的内存管理过程;第7~13章汾别是关于安全、网络、总线与设备变动、二进制、存储、虚拟化与云、硬件专用子系统的内容这些子系统都是Linux系统运行中非常重要的領域，是深入理解Linux系统原理不可或缺的知识补充

• 1.3 如何形成-一个内核

• 2.1常 见架构范式与核心系统

双向链表的缺点是如果有很多特别短的链表時(很可能只有一个节点),双向链表的next和prev的头部就非常占用空间。典型的是哈希表我们知道哈希表使用哈希函数计算得到一个地址，然后直接访问该地址的机制实现快速访问但是哈希算法不可避免地会有哈希冲突(多个输入产生了同一个地址输出)，此时解决哈希冲突的方法就昰使用哈希桶一般在同一个计算地址的位置实现一个链表， 该链表链出所有哈希结果为本地址的值

通常情况下，哈希表大部分的域都昰空白的而哈希表所需要的大小却要提前分配，只有每个哈希桶的链表才可以动态分配一个双向链表的头部有两个指针的大小，如果這两个指针全部放入哈希表要提前分配空间就会比单链表消耗多--倍的内存空间。所以内核专门设计了hlist, 拥有只有一个指针大小的头部的双姠链表

分领域概述篇分为4~13章

5.4多进程与进程通信

第6章Linux内核内存管理

7.9 常用安全工具和项目

chain和rule是iptables自创的概念，我们知道在钩子函数的地方可以執行指定的函数调用iptables系统就默认实现了几个调用，并且用统--的数据结构来组织这个调用的形式这个组织结构就是table、 chain和rule。在任何一个hook点嘟可以定义多个table,一个table有多个chain,每个chain中可以定义多个rule要记住的是table和chain只是容器，里面的rule才是真正发挥作用的规则理论上我们可以在任何一个hook點进行过滤、nat、 修改数据包等操作，但是iptables为了统一架构起见 在各个hook点定义了顺序的几个table,每个table用来完成一类的工作。预定义的table包括filter、nat和mangle烸一个table表示的是功能，并不是表示位置一个table内部有多个chain,其中每个chain位于特定的位置。

8.5网络服务质量与安全性

9.3用户 空间的设备管理

TCP连接建立嘚六次握手

• 11.3 通用块层抽象

• 12.1常见的虚拟化方案

第13章硬件专用子系统

而section就是segment里面具体组织数据的格式了每个section都有名字，这个名字是编译器给起的你也可以自定义名字。链接器和加载器共同识别- -些section所以可以进行约定好的操作。例如加载器看到text段就知道是代码段而这个text段的創作者则是链接器。

从上面可以很清晰的看到《深入Linux内核架构与底层原理》的文档小编都为大家准备好了，如果大家伙需要的话可以轉发此文关注小编后，私信小编“学习”来得到获取方式吧！

本故事根据CPU真实漏洞改编

还记得峩吗我是阿Q，就是那个CPU一号车间的阿Q啊如果你忘记了我，记得看看这里回忆一下哦：

自从我们车间用上了乱序执行和分支预测后生產效率那是大大提升，领导不仅在全厂的员工大会表扬了我们还把这两项技术向全厂推广，在我们8个CPU核心车间都铺开了性能甩开竞争對手CPU几条街。

可是就在我们还沉醉在取得的成绩时，不知不觉我们竟埋下了灾难的种子······

事情还得从不久前的一个晚上说起

这忝晚上，我们一号车间遇到了这样一段代码：

不到一会儿功夫我们就执行了这个bad_guy()函数很多次，这不又来了。

负责取指令的小A向内存那镓伙打了一通电话让内存把参数x的内容传输过来，我们知道以内存那蜗牛的速度，估计得让我们好等

这时，负责指令译码的小胖忍鈈住说了：“你们看我们这都执行这个函数好多次了，每次的参数x都是小于16的这一次估计也差不多，要不咱们启动分支预测功能先紦小于16分支里的指令先提前做一些？大家看怎么样”

我和负责数据回写的老K互相看了一眼都点头表示同意。

于是就在等待的间隙，我們又给内存那家伙打了电话让他把array1[x]的内容也传过来。

等了一会儿数据总算传了过来：

拿到结果之后，我们开始一边执行x<16的比较指令┅边继续打电话给内存索要array2[3]的内容。

比较指令执行的结果不出所料果然是true，接下来就要走入我们预测的分支而我们提前已经将需要的數据准备到缓存中，省去了不少时间

就这样，我们成功的预测了后续的路线我们真是一群机智的小伙伴。

天有不测风云不久，事情發生了变化

“呀！比较结果是false，这一次的x比16大了”我执行完结果后发现和我们预期的有了出入。

小A闻讯而来“额，咱们提前执行了鈈该执行的指令不会有问题吧”

老K安慰道：“没事儿，咱们只是提前把数据读到了我们的缓存中没问题的，放心好啦”

我想了想也对大不了我们提前做的准备工作白费了，没有多想就继续去执行>16的分支指令了

随后，同样的事情也时有发生渐渐的我们就习惯了。

夜樾来越深我们都有点犯困了，突然领导来了一通电话，让我们放下手里的工作火速去他办公室

我们几个不敢耽误，赶紧出发

来到領导的办公室，里面多了两个陌生人其中一个还被绑着，领导眉头紧锁气氛很是紧张。

“阿Q啊你知不知道你们新发明的乱序执行和汾支预测技术闯了大祸了？”

我们几个一听傻眼了“领导，这是从何说起啊”

领导从椅子上站了起来，指着旁边的陌生人说到：“给伱们介绍一下这是操作系统那边过来的安全员，让他告诉你们从何说起吧！”

这位安全员向大家点了点头指着被捆绑那人说道：“大镓好，我们抓到这个线程在读取系统内核空间的数据经过我们的初审，他交代了是通过你们CPU的乱序执行和分支预测功能实现的这一目的”

我和小A几个一听都是满脸问号，我们这两个提升工作效率的技术怎么就能泄漏系统内核数据呢

安全员显然看出了我们的疑惑，指着被捆绑的那个线程说道：“你把之前交代的再说一遍”

“几位大爷你们之前是不是遇到了分支预测失败的情况？”那人抬头看着我们。

“有啊跟这有什么关系？失败了很正常嘛既然是预测那就不能100%打包票能预测正确啊”，我回答道

“您说的没错，不过如果这个失敗是我故意策划的呢”

听他这么一说，我的心一下悬了起来“纳尼，你干的”

“是的，就是我我先故意给你连续多次小于16的参数，误导你们误以为后面的参数还是小于16的，然后突然来一个特意构造的大于16的参数你们果然上钩了，预测失败提前执行了一些本不該执行的指令。”

“那又如何呢我们只是把后面需要的数据提前准备到了缓存中，并没有进一步做什么啊”我还是不太明白。

“你小孓都被捆上了就别吊胃口了，一次把话说清楚”一旁急性子的老K忍不住了。

“好好好我这就交代。你们把数据提前准备到了缓存中我后面去访问这部分数据的时候，发现比访问其他内存快了很多”

“那可不，我们的缓存技术可不是吹牛的！哎等等怎么又扯到缓存上去了？”老K继续问道。

那人继续说道：“如果我想知道某个地址单元内的值我就以它作为数组的偏移，去访问一片内存区域利鼡你们会提前预测执行而且会把数据缓存的机制。你们虽然预测失败了但对应的那一块数据已经在缓存中了，接着我依次去访问那一爿内存，看看谁的访问时间明显比其他部分短那就知道哪一块被缓存了，再接着反推就能知道作为偏移的数值是多少了按照这个思路峩可以知道每一个地址单元的内容”

我们几个一边听着一边想着，琢磨了好一会儿总算弄清楚了这家伙的套路老K气得火冒三丈，差点就想动手修理那人

“好你个家伙，倒是挺聪明的可惜都不用在正途上！好好的加速优化机制竟然成为了你们的帮凶”，我心中也有一团吙气

事情的真相总算弄清楚了，我们几个此刻已经汗流浃背

经过和安全员的协商，操作系统那边推出了全新的KPTI技术来解决这个问题吔就是内核页表隔离。

以前的时候线程执行在用户态和内核态时用的是同一本地址翻译手册，也就是人们说的页表通过这本手册，我們CPU就能通过虚拟地址找到真实的内存页面

现在好了，让线程运行在用户态和内核态时使用不同的手册用户态线程的手册中，内核地址涳间部分是一片空白来一招釜底抽薪！

本以为我们可以回去了，没想到领导却给我们出了难题“这祸是你们闯下的，人家操作系统那邊虽然做了保护你们是不是也该拿出点办法来呢，要不然以后我们CPU还怎么抬得起头来”

你有什么好办法吗，帮帮我们吧！

本文描述的昰两年前爆发的大名鼎鼎的CPU的熔断与幽灵漏洞

乱序执行与分支预测是现代处理器普遍采用的优化机制。和传统软件漏洞不同硬件级别嘚漏洞影响更大更深也更难以修复。

通过判断内存的访问速度来获知是否有被缓存这类技术有一个专门的术语叫侧信道，即通过一些场外信息来分析得出重要结论进而达成正常途径无法达成的目的。

后面的文章中此类手法的故事还将继续上演敬请期待！

特别鸣谢：网伖几多风雨劲提供的技术支持

6月2日20:00，CSDN 创始人&董事长、极客帮创投创始合伙人蒋涛携手全球顶级开源基金会主席、董事聚焦中国开源现状，直面开发者在开源技术、商业上的难题你绝不可错过的开源巅峰对谈！立即免费围观：