成功入侵系统后，入侵者一般会通过Rootkits工具来隐藏行踪，提供后门方便后续入侵访问。Rootkits一般会隐藏文件，隐藏进程，隐藏网络端口，过滤日志，总之会隐藏任何未授权行为，使入侵者的活动很难被检测到，入侵者可以持续掌控受害系统。
Rootkits的实现手段多种多样，从应用层到动态链接库层，再到内核层，甚至Hypervisor层，都有各种方法实现Rootkits。在应用层直接替换二进制文件如ls、ps、top、netstat等，在动态连接库层Hook库函数如open()、opendir()、readdir()、unlink()等，在内核层Hook系统调用及内核函数，更改内核行为。
上一篇博客使用QEMU和GDB调试Linux内核，最后使用内核提供的GDB扩展功能获取当前运行进程，发现内核已经不再使用thread_info获取当前进程，而是使用Per-CPU变量。而且从内核4.9版本开始，thread_info也不再位于内核栈底部，然而内核提供的辅助调试函数lx_thread_info()仍然通过内核栈底地址获取thread_info，很明显这是个Bug，于是决定将其修复并提交一个内核Patch，提交后很快就得到内核维护人员的回应，将Patch提交到了内核主分支。
Linux内核Patch提交还是采用邮件列表方式，不过提供了自动化工具。
排查Linux内核Bug，研究内核机制，除了查看资料阅读源码，还可通过调试器，动态分析内核执行流程。
QEMU模拟器原生支持GDB调试器，这样可以很方便地使用GDB的强大功能对操作系统进行调试，如设置断点；单步执行；查看调用栈、查看寄存器、查看内存、查看变量；修改变量改变执行流程等。
Cuckoo沙箱是一款开源自动化恶意软件分析系统，将可疑文件或URL在隔离环境中运行，生成详细的行为报告。
Cuckoo支持在Windows、macOS、Linux、Android四种操作系统平台下分析恶意文件（包括可执行文件、Office文档、PDF文档、邮件等多种类型）和恶意网站。相较于静态分析，沙箱动态分析可获得可疑文件的详细行为信息，如可疑文件创建的进程、调用的函数、创建删除或下载的文件、请求的网络流量等，进而对可疑文件进行深度判定。
SystemTap是一款Linux跟踪探测（trace/probe）工具，可收集Linux运行信息，用于性能诊断和问题排查等。SystemTap不需要每次都对内核修改、编译、安装、重启等繁杂冗余的操作，通过其自定义的脚本语言，即可编写功能丰富强大的探测模块，动态载入内核，对系统进行监控，获取指定信息。
SystemTap可以监控系统调用、内核函数及其他发生在内核的事件（event），当事件触发时，运行指定处理例程（handler）。
最近尝试基于Xen运行macOS操作系统，之前已经有人做过类似的研究：
虽然可正常运行，但缺少后续研究，也没有官方支持，所以目前为止Xen只能勉强运行老版本OSX操作系统。运行OSX系统，需要对Xen hypervisor进行修改，如支持MSR 0x35，OSX系统启动时需要据此确定CPU核心数和线程数，但是这个特性连Intel官方开发文档都没有明确说明，所以Xen官方拒绝将此修改合并到Xen主分支代码。
自己在本地修改Xen源码，虽然可安装、启动OSX-10.10系统，但还是遇到了其他问题，如外设模拟、系统驱动等，所以系统还是没法正常使用，只好作罢，转而投向更加活跃、有社区支持的OSX-KVM项目，基于KVM运行macOS系统。
最近拜读了Eli Bendersky写的Concurrent Servers系列博客，作者由简单到复杂，由串行到并行，由多线程到事件驱动，再到第三方库对并发的实现，梳理了并发服务相关思想，在此对相关重点做一总结。
作者写就此文的目的是检验几种流行的并发模型，评判这些模型的伸缩性(scalability)和是否容易实现。作者自定义了一种简单的协议(protocol)，用于服务端与客户端交互，协议是有状态的(stateful)，服务端根据客户端发送的数据更改状态，并根据状态产生不同行为。
segfault段错误是软件开发中经常会遇到的错误，该错误是由非法内存访问造成的，如空指针引用；在只读内存区域进行写操作；访问受保护的内存区域等。在不同场景下，segfault的解决难度大不相同，比如有源代码并且segfault很容易复现，重新编译一个调试版可执行文件，用gdb调试马上就能定位问题。但是如果segfault很难复现，或者没有调式版可用呢？又如何去定位问题呢？
最近就在线上环境遇到一个qemu-ndb造成的segfault错误，影响很严重。qemu-nbd要用到nbd内核模块，segfault错误出现时，qemu-nbd相关进程卡主无响应，造成业务无法正常运行，甚至无法强制kill掉qemu-nbd进程，只能断电重启服务器使业务临时恢复正常运行。根据现象判断，qemu-nbd进程处于uninterruptible sleep状态，通过ps命令可以看出qemu-nbd进程的状态为D(uninterruptible sleep)。相较于interruptible sleep状态，uninterruptible sleep状态下的进程对信号没有响应，无法对它发送SIGKILL信号，也就无法kill掉，只能重启服务器。该状态出现一般是IO出了问题，必须从根本上解决该问题，才能避免一些不必要的麻烦。
在使用Xen的过程中，会遇到各种问题，掌握一些常见的调试技巧，对于解决问题能起到事半功倍的效果。网上一些Xen调试相关的资源：
Xen hypervisor的运行信息写到了内存中，可以通过xl dmesg命令显示，并没有写入到日志文件，所以不太方便查看。如果遇到更严重的情况，Xen在启动阶段就出错了，则无法进入Dom0运行xl dmesg命令查看启动信息，只能通过串口查看。
使用串口调试Xen，需要两台物理机，通过串口线连接，一台运行Xen，另一台通过串口查看输出信息。
人与计算机交互，常见的方式有GUI（Graph User Interface，图形界面）、CLI（Command Line Interface，命令行）、TUI（Touch User Interface，触屏）等。交互方式也会影响软件开发，比如在Windows下，就可以使用强大的IDE — Visual Studio，而大多数Linux开发环境只提供了命令行界面，只能用命令行工具进行开发。
虽然命令行的学习成本比图形界面高，但熟练运用命令行后开发效率一点不比图形界面低，而且没有图形界面的干扰，更容易抓住技术的本质。下面就介绍Linux开发的四件利器，几乎是做Linux开发绕不开的工具。