我们可以通过objdump -D看到内核模块或者用户态程序里面的函数开头的指令，以便知道如果想hook它的话，要预先备份多少指令。
Linux调试内核代码是非常麻烦。它们一般加printk, 或者使用JTAG调试。
Linux内核代码的调试非常麻烦，一般都是加printk, 或者用JTAG调试。这里的方法是用QEMU来调试Linux内核。因为QEMU自己实现了一个gdb server, 所以可以非常方便的使用gdb来调内核。
Linux内核的构建工具用的是GNU Make，在其相关的Makefile中，有一个变量叫做cmd-check，其定义如下：
接上一篇BIOS启动，BIOS完成了基础的硬件检测和硬件的中断向量表的初始化，然后BIOS找到MBR并且把MBR加载在内存中，跳转到该位置。加载的位置在内存中的0x7C00,至于为什么是这个位置，主要是因为历史的原因吧，最初的内存只有32K,历史选择了0x7C00(31k)。
本文总结了通过分析Linux内核编译过程，特别是vmlinux文件的生成过程，以及分析uImage和zImage的生成方式，深入了解了Linux内核编译的底层原理和过程，对于实际参与Linux内核开发和推广有很大帮助。
本文主要分析了Linux内核编译过程中生成vmlinux文件的过程，包括编译、链接、初始化、配置、编译和打包等步骤。同时，本文还提供了相应的工具链、编译选项和编译规则，以方便开发人员更好地理解和掌握Linux内核编译的相关知识。
自从Linux内核代码迁移到Git之后，Linux内核配置/构建系统(也称为Kconfig/kBuild)已经存在了很长时间。然而，作为支持基础设施，它很少受到关注；即使在日常工作中使用它的内核开发人员也从未真正考虑过它。
脚本extract-vmlinux:https://github.com/torvalds/linux/blob/master/scripts/extract-vmlinux sh extract-vmlinux vmlinuz > vmlinux
分析makefile从顶层开始，顺藤摸瓜的分析下去，会涉及到所有的makefile文件。各级子目下的makefile完成的动作obj -y += obj -m += make uImage时，uImage在arch/arm/makefile中，顶层makefile中一定包含了底层的makefile。
vmlinux 属于 ELF 文件，要想了解如何启动 vmlinux，首先需要知道 ELF 的格式。
题目给了 bzImage，core.cpio，start.sh 以及 vmlinux 四个文件，接下来简单介绍一下。
所谓thread local变量，就是对于同一个变量，每个线程都有自己的一份，对该变量的访问是线程隔离的，它们之间不会相互影响，所以也就不会有各种多线程问题。
arm-eabi-gdb 先用命令找到这个东西，然后在去找去找到vmlinux 还有就是我arm-eabi-4.7/ 这个版本才可以用，这个是我试出来的。
Linux kernel官网：https://kernel.org/ Active kernel releases（查看EOL信息）：https://kernel.org/category/releases.html
Rusoto 是一个 Rust 实现的 AWS SDK，目前在 beta 版本 v0.43.0-beta.1 中兼容了std::future::Future.
（文章大部分转载于：https://consen.github.io/2018/01/17/debug-linux-kernel-with-qemu-and-gdb/）
建议关闭地址随机化，否则会出现gdb中无法在断点处停下来的情况（尤其是qemu中）。可以参考：https://blog.csdn.net/gatieme/article/details/104266966
①这里所谓的“二进制”，英文称为raw binary。这种程序只包含机器码。而ELF程序还包含有其它额外的信息，如段的加载地址，运行地址，重定位表，符号表。
---- 前言 调试内核肯定不是什么轻松的事情, 这里是使用kgdb进行调试, 你理解的没错, 就是kernel版的gdb. ---- 虚拟机串口设置 首先克隆下已经重新编译内核的虚拟机 然
本文适用于CentOS 6.4, CentOS 6.5，估计也适用于其他Linux发行版。
本文以Linux3.14版本源码为例分析其启动流程。各版本启动代码略有不同，但核心流程与思想万变不离其宗。
Linux操作系统在作为服务器的场景下应用最为广泛,但是在使用过程中也会遇到莫名崩溃的情况.这时我们就希望能对崩溃前一刻内存中的数据进行分析,从而找到崩溃的原因.本文将对整个过程所涉及到的技术做一个简单但是全面的介绍,包括:如何安装kdump,如何设置系统参数来捕获崩溃前的内存;如何使用crash做简单的分析;并且介绍如何使用更加简便的工具PyKdump来做crash文件的分析.通过了解这些知识, 可以帮助Linux运维人员更快更方便地排查问题.
直接摘抄自己《揭秘家用路由器0day漏洞挖掘技术》，网上查了一下也没有找到令人满意的QEMU的使用说明，就采用这本书上的介绍。如果后期能够找到比较满意的QEMU的使用方法的说明，再添加上来。
由于在debian6系统下不小心误删除了部分文件，导致系统不能关机，不能重启，故重装。
crash 是目前广泛使用的 linux 内核崩溃转储文件的分析工具，掌握 crash 的使用技巧，对于分析定位内核崩溃的问题，有着非常重要的作用。本文首先介绍了 crash 的基本概念和安装方法，其次详细介绍了如何使用 crash 工具分析内核崩溃转储文件，包括各种常用调试命令的使用方法，最后以几个实际工作中遇到的真实案例向读者展示了 crash 的强大功能。在这篇文章中，既有详细的工具使用方法，又有丰富的实际案例分析，相信您读过以后定会受益匪浅。
1、各种文件的意义 vmlinux 编译出来的最原始的内核文件，未压缩。 zImage 是vmlinux经过gzip压缩后的文件。 bzImage bz表示“big zImage”，不是用bzip2压缩的。两者的不同之处在于，zImage解压缩内核到低端内存(第一个640K)，bzImage解压缩内核到高端内存(1M以上)。如果内核比较小，那么采用zImage或bzImage都行，如果比较大应该用bzImage。 uImage U-boot专用的映像文件，它是在zImage之前加上一个长度为0x4
如果回显中显示CONFIG_INFO_BTF=y表示开启。如果未开启需要重新编译内核开启。
就是这样一个常见的问题，面试过的大部分同学都未能很好地回答，这里希望能够做很彻底地解答。
上章链接入口: https://blog.csdn.net/qq_16933601/article/details/104327937 在上章里,我们分析了oops的PC值在哪个函数出错的
在某些情况下，我们需要对于内核中的流程进行分析，虽然通过 BPF 的技术可以对于函数传入的参数和返回结果进行展示，但是在流程的调试上还是不如直接 GDB 单步调试来的直接。本文采用的编译方式如下，在一台 16 核 CentOS 7.7 的机器上进行内核源码相关的编译（主要是考虑编译效率），调试则是基于 VirtualBox 的 Ubuntu 20.04 系统中，采用 Qemu + GDB 进行单步调试，网上查看了很多文章，在最终进行单步跟踪的时候，始终不能够在断点处停止，进行过多次尝试和查询文档，最终发现需要在内核启动参数上添加 nokaslr ，本文是对整个搭建过程的总结。
本文记录了对某发行版Linux中一个安全模块（LSM）的逆向过程，该LSM对系统中待运行的程序进行安全校验，数据流穿越内核态与用户态，涉及系统内核及系统服务。此LSM对系统安全性的增强效果明显，其设计思路值得防守方研究学习，可于个人终端或服务器安全防护中应用。特此对逆向内容记录，希望能为读者在终端防护方面拓宽思路，同时欢迎感兴趣的师傅们交流学习。
交叉编译器: http://ftp.loongnix.org/loongsonpi/pi_2/toolchain/
之前学习了利用KGDB双机调试内核,这种方式需要在两个主机上，通过串口线进行连接，或者是通过VMware开启两个虚拟机进行调试，对机器要求相对高一些。通过qemu创建虚拟机，然后利用gdb进行调试相对更轻量级一点。 我先在centos7下面配置调试环境，但是centos7下没有qemu_system_x86等命令，所以需要重新编译qemu源码再进行安装，再加上各种依赖问题，于是转用ubuntu进行配置，过程简单了许多。
内核启动的过程中会通过函数 do_initcalls，将按顺序从 __initcall_start 开始，到 __initcall_end 结束的 section 中以函数指针的形式取出这些编译到内核的驱动模块中初始化函数起始地址，来依次完成相应的初始化。这些初始化函数由 __define_initcall(level,fn) 指示编译器在编译的时候，将这些初始化函数的起始地址值按照一定的顺序放在这个section中。
此软件包仍在开发中，但大多数对1.0.0的API调用已完成。如果发现任何错误，请在GitHub上提交问题或诉求。
在上一篇文章中介绍了提高socket性能的几个socket选项，其中给出了几个源于内核源码树中的例子，如果选择使用内核树中的Makefile进行编译的话，可能会出现与本地头文件冲突的情况，如重复定义变量，结构体类型不对等错误。这些问题大大影响了BPF程序的可移植性。
在BPF的可移植性和CO-RE一文的末尾提到了一个名为runqslower的工具，该工具用于展示在CPU run队列中停留的时间大于某一值的任务。现在以该工具来展示如何使用BPF CO-RE。
对用户态进程，利用gdb调试代码是很方便的手段。而对于内核态的问题，可以利用crash等工具基于coredump文件进行调试。
上篇文章 编译一个默认输出hello world的linux内核 中，我们已经知道如何编译一个可以自运行的linux内核，这篇文章我们来看下如何对内核进行断点调试。
虚拟机好久没有用了，居然忘记了dedora12的root密码，只记得另一普通用户的密码，怎么办？
BPF 是 Linux 内核中基于寄存器的虚拟机，可安全、高效和事件驱动的方式执行加载至内核的字节码。与内核模块不同，BPF 程序经过验证以确保它们终止并且不包含任何可能锁定内核的循环。BPF 程序允许调用的内核函数也受到限制，以确保最大的安全性以防止非法的访问。
nysm是一款针对红队审计的隐蔽型后渗透安全测试容器，该工具主要针对的是eBPF，能够帮助广大红队研究人员在后渗透测试场景下保持eBPF的隐蔽性。
本文旨在介绍下几种常见的调试方法gdb、crash、kgdb and kdb 以及dynamic debug. 关于在 Linux 内核上使用debuggers，Linus Torvalds 长期以来对它们不太喜欢。简短地解释这种态度是，依赖调试器可能鼓励用权宜之计而非深思熟虑来解决问题，这会导致代码质量恶化。详细解释可以参考https://lwn.net/2000/0914/a/lt-debugger.php3
一个最小可运行Linux操作系统需要内核镜像bzImage和rootfs，本文整理了其制作、安装过程，调试命令，以及如何添加共享磁盘。
2）获取对应软件版本的符号表文件（如vmlinux），可以将该文件放置 crash工具同一目录下。
crash 是 Linux 内核开发中流行的调试工具。特别是它提供了强大的使用搜索命令进行内存搜索的功能。但是，它有点不方便，因为在移动每个进程的调用堆栈时没有查看局部变量的功能。 应读者要求，这篇文章，我将介绍如何从 vmcore 中提取堆栈转储并将调用堆栈上传到 Trace32。 使用命令“./crash64 vmcore vmlinux”运行崩溃实用程序。 $./crash64 vmcore vmlinux ...... please wait... (gathering kmem slab cach
之前没有用过addr2line和gdb等内核调试工具定位问题代码，这里记录一下在将某个网络驱动从4.9内核移植到5.7内核时出现内核崩溃起不来的问题。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
