本文介绍的方法，旨在利用基于 BusyBox 制作的简易文件系统来快速启动内核并进入一个 shell 环境，以此来验证内核的功能和稳定性。其优点在于制作简单，资源占用小，验证环境的启动时间短（仅需启动内核，省去了各种用户态应用及框架的启动过程）；缺点是可拓展性较差，难以支撑一些需要用到用户态工具的复杂内核功能的验证。 本文主要以 ARM64 为例讲解整个过程。实际操作中，应结合实际使用的体系结构与工具链对步骤细节进行调整。介绍的验证环境有基于 initrd 和基于 SD 卡两种，可以根据实际情况选择。 BusyBox 编译 1# BusyBox 源代码下载，解压 2# https://busybox.net/downloads/ 3 …

遗留问题：把 struct mm 放到 file->private_date 中，是否有可能导致泄漏？ 情况简述 XXX(xxxxxxxx)2021-07-29 14:32 @XX 有修改引入引起这边容器AT大面积失败 问题引入补丁：bfb819ea20ce (“proc: Check /proc/$pid/attr/ writes against file opener”) 修补补丁： 591a22c14d3f (“proc: Track /proc/$pid/attr/ opener mm_struct”) ，在修复原问题的基础上引入了新问题。 问题现场：Launchpad …

源代码定位方法 我们经常需要根据内核错误日志，在源代码中比较精确地定位到发生错误的那一行。一般而言，我们通过错误发生的地址来定位对应的源代码：（链接 ） 1# 注意：这里的 vmlinux 需要带有调试信息 2addr2line -f -e vmlinux <asm_addr> 然而在内核错误日志中，调用栈常以形如 bdi_register+0xec/0x150 的形式1展示函数调用地址，而 addr2line 无法解读这样的格式。此时我们可以使用 GDB 来解析该地址： 1# In `gdb vmlinux`, compiled with CONFIG_DEBUG_INFO=y 2 3list …

VM 启动后没有输出？莫慌~ 一般而言，在运行 qemu-system-xxx 启动虚拟机后，我们希望在主机的当前终端上看到内核的启动日志，并在虚拟机启动后用该终端直接操作虚拟机。然而有时，当前终端在运行了 qemu-system-xxx 后却毫无动静。此时，在确认内核可以正常启动的前提下，要去确认几件事情： 当前终端对 QEMU 虚拟机而言是什么设备； 当前内核使用的 /dev/console 指向了哪个设备。 先找到一个可用的虚拟机终端（比如通过 VNC 连接的方式），然后向 /dev/{console,tty{,S}{0,1,...}} 等物理终端设备文件逐个尝试输入一些内容，看看哪个文件能让主机的当前终端有输出1。确定了是哪 …

0x01 虚拟机（VM）安装及启动 1. 选择一个发行版，下载其安装镜像 选择格式为 .iso 的安装镜像进行下载。 2. 制作根文件系统（rootfs）镜像 总体思路：启动一个 QEMU 虚拟机，以 rootfs 镜像文件为硬盘，以安装镜像 iso 文件为光盘。设置虚拟机从光盘启动，将系统安装至硬盘。 1# create an empty rootfs image file 2qemu-img create -f qcow2 rootfs.qcow2 128G 3 4# boot from CD-ROM, so that OS can be installed into the rootfs image …