瑙哥空间

利用Linux NS和cGroups机制简单实现容器进程划分

Sun, 12 Oct 2025 18:48:53 +0800

利用NS和cGroup区分容器进程和非容器进程

核心思路

在 Linux 系统中，容器技术的核心是命名空间 (Namespace) 和控制组 (Cgroups)。我们可以利用这些内核特性来识别一个进程是否运行在容器内。

PID 命名空间 (PID Namespace): 每个容器都有自己独立的进程ID空间。容器内的1号进程对应于宿主机上的一个普通进程。因此，一个进程的 PID 命名空间如果与宿主机 init 进程（PID为1）的 PID 命名空间不同，那么它极有可能是一个容器进程。

Cgroups: 容器运行时（如 Docker、containerd）会为每个容器创建特定的 Cgroup 路径，用于资源限制。通过检查进程的 /proc/[pid]/cgroup 文件，我们可以看到它所属的 Cgroup 路径。容器进程的 Cgroup 路径通常包含 docker、kubepods 或 container 等特征字符串。

本项目将主要采用第一种方法（PID 命名空间），因为它是一种更通用和根本性的区分方式。

我们将通过 eBPF 实现以下逻辑：

内核态 (eBPF Program): 附加一个 eBPF 程序到内核的进程创建相关的跟踪点（例如 sched_process_exec）。当系统中有新进程执行时，该 eBPF 程序会被触发。程序会获取新进程的 task_struct 结构体，并从中读取其 PID 命名空间的 inode 号。

用户态 (User-space Application):

    启动时，首先获取宿主机 init 进程（PID 1）的 PID 命名空间 inode 号，并将其作为“基准”写入一个 eBPF Map 中，供内核态的 eBPF 程序查询。

    加载 eBPF 程序并将其附加到指定的内核跟踪点。

    通过 eBPF 的 Perf Event Array 机制，接收内核态 eBPF 程序发送的事件。

    内核态程序会将每个新进程的 PID、COMM（进程名）及其 PID 命名空间 inode 号与宿主机基准 inode 号的对比结果发送给用户态。

    用户态程序接收到数据后，进行格式化输出，明确标识出哪些是容器进程，哪些是宿主机进程。

系统架构

+————————————————-+
| User Space (C/Go/Rust) |
| +——————————————-+ |
| | Loader Application | |
| |——————————————-| |
| | 1. Get host init ns inode | |
| | 2. Load eBPF object file | |
| | 3. Write host ns inode to BPF_MAP <—-
| | 4. Attach eBPF program to tracepoint | | | BPF_MAP_TYPE_HASH
| | 5. Read events from Perf Buffer <—- (for host ns)
| +——————————————-+ | |
+———————-^————————–+
| Perf Buffer
| (BPF_MAP_TYPE_PERF_EVENT_ARRAY)
+———————-|————————–+
| v |
| Kernel Space |
| +——————————————-+ |
| | eBPF Program | |
| |——————————————-| |
| | TRACEPOINT(sched_process_exec) | |
| | { | |
| | task = bpf_get_current_task(); | |
| | process_ns_inode = task->nsproxy->…; | |
| | host_ns_inode = bpf_map_lookup(…); | | —-> Read host_ns_inode
| | | |
| | is_container = (process_ns_inode != | |
| | host_ns_inode); | |
| | | |
| | bpf_perf_event_output(…); | | —-> Send event data
| | } | |
| +——————————————-+ |
+————————————————-+

完整源码

本项目包含三个文件：

process_classifier.bpf.c: 内核态的 eBPF C 程序。

process_classifier.c: 用户态的加载器和事件处理 C 程序。

Makefile: 用于编译和构建项目的脚本。

内核态 eBPF 程序 (process_classifier.bpf.c)

此文件定义了 eBPF 程序的核心逻辑。


// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_core_read.h>
#include "vmlinux.h"

// 定义发送给用户态的事件结构体
struct event {
    u32 pid;
    u32 ppid;
    char comm[TASK_COMM_LEN];
    bool is_container;
};

// Perf event map to send data to user space
struct {
    __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
    __uint(key_size, sizeof(u32));
    __uint(value_size, sizeof(u32));
} events SEC(".maps");

// Map to store the host's init PID namespace inode number
// The user-space program will write to this map.
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 1);
    __type(key, u32);
    __type(value, u64);
} host_pid_ns_map SEC(".maps");

// Attach to the sched_process_exec tracepoint.
// This is not a raw tracepoint, so the context is task_struct.
SEC("tp/sched/sched_process_exec")
int handle_exec(struct trace_event_raw_sched_process_exec *ctx)
{
    struct task_struct *task;
    struct event event = {};
    u64 pid_tgid;
    u32 key = 0;
    u64 *host_pid_ns_inode;
    u64 proc_pid_ns_inode;

    // Get PID and TGID
    pid_tgid = bpf_get_current_pid_tgid();
    event.pid = pid_tgid >> 32;

    // Get current task_struct
    task = (struct task_struct *)bpf_get_current_task();

    // Get parent PID
    event.ppid = BPF_CORE_READ(task, real_parent, tgid);

    // Get command name
    bpf_get_current_comm(&event.comm, sizeof(event.comm));

    // Get the PID namespace inode number for the current process
    // task->nsproxy->pid_ns_for_children->ns.inum
    proc_pid_ns_inode = BPF_CORE_READ(task, nsproxy, pid_ns_for_children, ns.inum);

    // Look up the host PID namespace inode from the map
    host_pid_ns_inode = bpf_map_lookup_elem(&host_pid_ns_map, &key);

    if (host_pid_ns_inode) {
        // If the process's PID namespace inode is different from the host's,
        // it's a container process.
        if (proc_pid_ns_inode != *host_pid_ns_inode) {
            event.is_container = true;
        } else {
            event.is_container = false;
        }
    } else {
        // If map lookup fails, we can't determine, assume not a container.
        event.is_container = false;
    }

    // Send the event to user space via the perf buffer.
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &event, sizeof(event));

    return 0;
}

char LICENSE[] SEC("license") = "Dual BSD/GPL";

用户态加载器 (process_classifier.c)

此文件负责加载 eBPF 程序、与内核交互并显示结果。


// SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
#include <stdio.h>
#include <unistd.h>
#include <sys/resource.h>
#include <bpf/libbpf.h>
#include <time.h>
#include <errno.h>
#include <fcntl.h>
#include "process_classifier.skel.h"

// 定义与内核态一致的事件结构体
struct event {
    __u32 pid;
    __u32 ppid;
    char comm[16];
    bool is_container;
};

// 获取指定PID的PID命名空间inode号
static unsigned long long get_pid_ns_inode(pid_t pid) {
    char path[128];
    struct stat s;

    snprintf(path, sizeof(path), "/proc/%d/ns/pid", pid);
    if (stat(path, &s) != 0) {
        perror("Failed to stat pid namespace");
        return 0;
    }
    return s.st_ino;
}

// Perf buffer 事件处理回调函数
static int handle_event(void *ctx, void *data, size_t data_sz) {
    const struct event *e = data;
    time_t t;
    struct tm *tm;
    char ts[32];

    time(&t);
    tm = localtime(&t);
    strftime(ts, sizeof(ts), "%H:%M:%S", tm);

    printf("%-8s %-7d %-7d %-16s %-10s\n",
           ts, e->pid, e->ppid, e->comm,
           e->is_container ? "Container" : "Host");

    return 0;
}

int main(int argc, char **argv) {
    struct process_classifier_bpf *skel;
    struct perf_buffer *pb = NULL;
    int err;
    unsigned long long host_init_pid_ns;
    int map_fd;
    int key = 0;

    // 提升资源限制
    struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
    if (setrlimit(RLIMIT_MEMLOCK, &r)) {
        perror("setrlimit(RLIMIT_MEMLOCK)");
        return 1;
    }

    // 1. 打开、加载并验证 eBPF 程序
    skel = process_classifier_bpf__open_and_load();
    if (!skel) {
        fprintf(stderr, "Failed to open and load BPF skeleton\n");
        return 1;
    }

    // 2. 获取宿主机 init 进程 (PID=1) 的 PID Namespace Inode
    host_init_pid_ns = get_pid_ns_inode(1);
    if (host_init_pid_ns == 0) {
        fprintf(stderr, "Failed to get host init pid namespace inode\n");
        goto cleanup;
    }
    printf("Host init PID namespace inode: %llu\n", host_init_pid_ns);

    // 3. 将宿主机 PID Namespace Inode 写入 eBPF map
    map_fd = bpf_map__fd(skel->maps.host_pid_ns_map);
    err = bpf_map_update_elem(map_fd, &key, &host_init_pid_ns, BPF_ANY);
    if (err) {
        fprintf(stderr, "Failed to update host_pid_ns_map: %s\n", strerror(errno));
        goto cleanup;
    }

    // 4. 附加 eBPF 程序到跟踪点
    err = process_classifier_bpf__attach(skel);
    if (err) {
        fprintf(stderr, "Failed to attach BPF skeleton: %d\n", err);
        goto cleanup;
    }

    printf("Successfully started! Please run processes on host or in containers to see events.\n");
    printf("%-8s %-7s %-7s %-16s %-10s\n", "TIME", "PID", "PPID", "COMM", "TYPE");

    // 5. 设置 Perf Buffer 来接收事件
    pb = perf_buffer__new(bpf_map__fd(skel->maps.events), 8, handle_event, NULL, NULL, NULL);
    if (!pb) {
        err = -errno;
        fprintf(stderr, "Failed to create perf buffer: %d\n", err);
        goto cleanup;
    }

    // 6. 轮询 Perf Buffer
    while (true) {
        err = perf_buffer__poll(pb, 100 /* timeout, ms */);
        if (err < 0 && err != -EINTR) {
            fprintf(stderr, "Error polling perf buffer: %s\n", strerror(-err));
            break;
        }
    }

cleanup:
    perf_buffer__free(pb);
    process_classifier_bpf__destroy(skel);
    return -err;
}

Makefile

这个 Makefile 会处理所有编译步骤，包括使用 bpftool 生成 skeleton 文件。


# Dirs
SRC_DIR = .
OUT_DIR = .

# Files
BPF_SRC = $(SRC_DIR)/process_classifier.bpf.c
BPF_OBJ = $(OUT_DIR)/process_classifier.bpf.o
BPF_SKEL = $(OUT_DIR)/process_classifier.skel.h
USER_SRC = $(SRC_DIR)/process_classifier.c
USER_BIN = $(OUT_DIR)/process_classifier

# Tools
CC = gcc
CLANG = clang
BPFTOOL = bpftool

# Flags
CFLAGS = -g -Wall
LDFLAGS = -lbpf

.PHONY: all clean

all: $(USER_BIN)

# Generate BPF skeleton header
$(BPF_SKEL): $(BPF_OBJ)
    $(BPFTOOL) gen skeleton $< > $@

# Compile BPF C code to object file
$(BPF_OBJ): $(BPF_SRC)
    $(CLANG) -g -O2 -target bpf -c $< -o $@ -I/usr/include/bpf -I.

# Compile user-space C code
$(USER_BIN): $(USER_SRC) $(BPF_SKEL)
    $(CC) $(CFLAGS) $< -o $@ $(LDFLAGS)

clean:
    rm -f $(BPF_OBJ) $(BPF_SKEL) $(USER_BIN)

准备和编译环境

安装依赖:

你需要一个较新的 Linux 内核（推荐 5.8+），以及 clang, llvm, libbpf-dev, 和 bpftool。
在 Ubuntu/Debian 上:


sudo apt-get update
sudo apt-get install -y clang llvm libelf-dev libbpf-dev bpftool build-essential

获取 vmlinux.h:
eBPF 程序需要内核类型定义。bpftool 可以从你正在运行的内核生成此文件。
Bash

# 确保你的系统支持 BTF (BPF Type Format)
ls /sys/kernel/btf/vmlinux

# 如果上述文件存在，则可以生成 vmlinux.h
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

如果 /sys/kernel/btf/vmlinux 不存在，你需要确保你的内核编译时开启了 CONFIG_DEBUG_INFO_BTF=y 选项。

编译项目:

将以上三个文件 (process_classifier.bpf.c, process_classifier.c, Makefile) 放在同一个目录下，然后运行 make。


    make

如果一切顺利，你会在当前目录下看到一个名为 process_classifier 的可执行文件。

运行和验证

运行程序:
因为 eBPF 程序需要加载到内核，所以需要 root 权限。

sudo ./process_classifier

程序启动后，会打印出宿主机的 init 进程 PID 命名空间 inode，然后开始监听新的进程执行事件。

验证:
打开第一个终端，运行程序:

sudo ./process_classifier
Host init PID namespace inode: 4026531836
Successfully started! Please run processes on host or in containers to see events.
TIME     PID     PPID    COMM             TYPE

打开第二个终端 (宿主机终端)，执行一些命令:

ls -l
sleep 5

在第一个终端，你会看到类似这样的输出，TYPE 都是 Host:

20:42:10 12345   12300   ls               Host
20:42:15 12346   12300   sleep            Host

打开第三个终端，启动一个 Docker 容器并执行命令:


# 启动一个交互式 busybox 容器
docker run --rm -it busybox

# 在容器内执行命令
/ # ls
/ # ps aux
/ # sleep 10

现在回到第一个终端，你会看到来自容器的进程事件，TYPE 被正确地标识为 Container:

20:45:30 13010   12990   ls               Container
20:45:35 13011   12990   ps               Container
20:45:40 13012   12990   sleep            Container

Ubuntu2204安装OpenVas【译+一些适配上的见解】

Mon, 19 May 2025 17:22:33 +0800

译自：https://medium.com/@raivishnu1013/install-openvas-gvm-22-4-0-on-ubuntu-22-04-e351fd132a1b
要在 Ubuntu 22.4.0 中安装 GVM 22.04 而没有任何问题，请在您的计算机中打开一个终端，然后按照本指南进行作。如果您仍然遇到一些问题，请随时发表评论。此外，所有服务都有类似的构建方式，所以我只会解释第一个部分，您可以直接复制和粘贴命令，如果您仍然想知道一些我想提及的内容，评论部分仅供您参考，请让我知道:)

推荐一定要科学上网，否则真的很慢

创建新用户

sudo useradd -r -M -U -G sudo -s /usr/sbin/nologin gvm

将用户添加到 gvmd 组

sudo usermod -aG gvm $USER
su $USER

设置 PATH 环境

export PATH=$PATH:/usr/local/sbin

设置 Installation Prefix 环境变量

export INSTALL_PREFIX=/usr/local

export SOURCE_DIR=$HOME/source
mkdir -p $SOURCE_DIR
export BUILD_DIR=$HOME/build
mkdir -p $BUILD_DIR
export INSTALL_DIR=$HOME/install
mkdir -p $INSTALL_DIR

下载并安装以下依赖项：

sudo apt update
sudo apt install –no-install-recommends –assume-yes
build-essential
curl
cmake
pkg-config
python3
python3-pip
gnupg

导入 greenbone 密钥

curl -f -L https://www.greenbone.net/GBCommunitySigningKey.asc -o /tmp/GBCommunitySigningKey.asc
gpg –import /tmp/GBCommunitySigningKey.asc
echo “8AE4BE429B60A59B311C2E739823FAA60ED1E580:6:” > /tmp/ownertrust.txt
gpg –import-ownertrust < /tmp/ownertrust.txt

将 GVM 版本设置为如果不设置版本，下载可能会出现问题。（版本可以稍后更改）

export GVM_VERSION=22.4.0

配置 gvm-libs

export GVM_LIBS_VERSION=$GVM_VERSION

sudo apt install -y
libglib2.0-dev
libgpgme-dev
libgnutls28-dev
uuid-dev
libssh-gcrypt-dev
libhiredis-dev
libxml2-dev
libpcap-dev
libnet1-dev
libpaho-mqtt-dev
libldap2-dev
libradcli-dev

curl -f -L https://github.com/greenbone/gvm-libs/archive/refs/tags/v$GVM_LIBS_VERSION.tar.gz -o $SOURCE_DIR/gvm-libs-$GVM_LIBS_VERSION.tar.gz
curl -f -L https://github.com/greenbone/gvm-libs/releases/download/v$GVM_LIBS_VERSION/gvm-libs-$GVM_LIBS_VERSION.tar.gz.asc -o $SOURCE_DIR/gvm-libs-$GVM_LIBS_VERSION.tar.gz.asc
gpg –verify $SOURCE_DIR/gvm-libs-$GVM_LIBS_VERSION.tar.gz.asc $SOURCE_DIR/gvm-libs-$GVM_LIBS_VERSION.tar.gz

tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/gvm-libs-$GVM_LIBS_VERSION.tar.gz

mkdir -p $BUILD_DIR/gvm-libs && cd $BUILD_DIR/gvm-libs

cmake $SOURCE_DIR/gvm-libs-$GVM_LIBS_VERSION
-DCMAKE_INSTALL_PREFIX=$INSTALL_PREFIX
-DCMAKE_BUILD_TYPE=Release
-DSYSCONFDIR=/etc
-DLOCALSTATEDIR=/var

make -j$(nproc)

make DESTDIR=$INSTALL_DIR install

sudo cp -rv $INSTALL_DIR/* /

配置 gvmd

export GVMD_VERSION=$GVM_VERSION

sudo apt install -y
libglib2.0-dev
libgnutls28-dev
libpq-dev
postgresql-server-dev-14
libical-dev
xsltproc
rsync
libbsd-dev
libgpgme-dev

sudo apt install -y –no-install-recommends
texlive-latex-extra
texlive-fonts-recommended
xmlstarlet
zip
rpm
fakeroot
dpkg
nsis
gnupg
gpgsm
wget
sshpass
openssh-client
socat
snmp
python3
smbclient
python3-lxml
gnutls-bin
xml-twig-tools

curl -f -L https://github.com/greenbone/gvmd/archive/refs/tags/v$GVMD_VERSION.tar.gz -o $SOURCE_DIR/gvmd-$GVMD_VERSION.tar.gz
curl -f -L https://github.com/greenbone/gvmd/releases/download/v$GVMD_VERSION/gvmd-$GVMD_VERSION.tar.gz.asc -o $SOURCE_DIR/gvmd-$GVMD_VERSION.tar.gz.asc

gpg –verify $SOURCE_DIR/gvmd-$GVMD_VERSION.tar.gz.asc $SOURCE_DIR/gvmd-$GVMD_VERSION.tar.gz

tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/gvmd-$GVMD_VERSION.tar.gz

mkdir -p $BUILD_DIR/gvmd && cd $BUILD_DIR/gvmd

cmake $SOURCE_DIR/gvmd-$GVMD_VERSION
-DCMAKE_INSTALL_PREFIX=$INSTALL_PREFIX
-DCMAKE_BUILD_TYPE=Release
-DLOCALSTATEDIR=/var
-DSYSCONFDIR=/etc
-DGVM_DATA_DIR=/var
-DGVMD_RUN_DIR=/run/gvmd
-DOPENVAS_DEFAULT_SOCKET=/run/ospd/ospd-openvas.sock
-DGVM_FEED_LOCK_PATH=/var/lib/gvm/feed-update.lock
-DSYSTEMD_SERVICE_DIR=/lib/systemd/system
-DLOGROTATE_DIR=/etc/logrotate.d
-DPostgreSQL_TYPE_INCLUDE_DIR=/usr/include/postgresql

make -j$(nproc)

make DESTDIR=$INSTALL_DIR install

sudo cp -rv $INSTALL_DIR/* /

配置 pg-gvm

export PG_GVM_VERSION=$GVM_VERSION

sudo apt install -y
libglib2.0-dev
postgresql-server-dev-14
libical-dev

curl -f -L https://github.com/greenbone/pg-gvm/archive/refs/tags/v$PG_GVM_VERSION.tar.gz -o $SOURCE_DIR/pg-gvm-$PG_GVM_VERSION.tar.gz
curl -f -L https://github.com/greenbone/pg-gvm/releases/download/v$PG_GVM_VERSION/pg-gvm-$PG_GVM_VERSION.tar.gz.asc -o $SOURCE_DIR/pg-gvm-$PG_GVM_VERSION.tar.gz.asc

gpg –verify $SOURCE_DIR/pg-gvm-$PG_GVM_VERSION.tar.gz.asc $SOURCE_DIR/pg-gvm-$PG_GVM_VERSION.tar.gz

tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/pg-gvm-$PG_GVM_VERSION.tar.gz

mkdir -p $BUILD_DIR/pg-gvm && cd $BUILD_DIR/pg-gvm

cmake $SOURCE_DIR/pg-gvm-$PG_GVM_VERSION
-DCMAKE_BUILD_TYPE=Release
-DPostgreSQL_TYPE_INCLUDE_DIR=/usr/include/postgresql

make -j$(nproc)

make DESTDIR=$INSTALL_DIR install

sudo cp -rv $INSTALL_DIR/* /

配置 GSA

export GSA_VERSION=$GVM_VERSION

export NODE_VERSION=node_14.x
export KEYRING=/usr/share/keyrings/nodesource.gpg
export DISTRIBUTION=”$(lsb_release -s -c)”

curl -fsSL https://deb.nodesource.com/gpgkey/nodesource.gpg.key | gpg –dearmor | sudo tee “$KEYRING” >/dev/null
gpg –no-default-keyring –keyring “$KEYRING” –list-keys

echo “deb [signed-by=$KEYRING] https://deb.nodesource.com/$NODE_VERSION $DISTRIBUTION main” | sudo tee /etc/apt/sources.list.d/nodesource.list
echo “deb-src [signed-by=$KEYRING] https://deb.nodesource.com/$NODE_VERSION $DISTRIBUTION main” | sudo tee -a /etc/apt/sources.list.d/nodesource.list

sudo apt update
sudo apt install -y nodejs

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo “deb https://dl.yarnpkg.com/debian/ stable main” | sudo tee /etc/apt/sources.list.d/yarn.list

sudo apt update
sudo apt install -y yarn

curl -f -L https://github.com/greenbone/gsa/archive/refs/tags/v$GSA_VERSION.tar.gz -o $SOURCE_DIR/gsa-$GSA_VERSION.tar.gz
curl -f -L https://github.com/greenbone/gsa/releases/download/v$GSA_VERSION/gsa-$GSA_VERSION.tar.gz.asc -o $SOURCE_DIR/gsa-$GSA_VERSION.tar.gz.asc

gpg –verify $SOURCE_DIR/gsa-$GSA_VERSION.tar.gz.asc $SOURCE_DIR/gsa-$GSA_VERSION.tar.gz

tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/gsa-$GSA_VERSION.tar.gz

cd $SOURCE_DIR/gsa-$GSA_VERSION

rm -rf build

yarn #注意这里大概率ui-components报错，可以去package.json里把这行删掉，然后去github上下源码，过程如下：

# 创建依赖目录
mkdir -p ~/source/greenbone/
cd ~/source/greenbone

# 克隆 ui-components 仓库
git clone https://github.com/greenbone/ui-components.git
cd ui-components

# 切换到对应分支（例如 gsa-22.04 兼容的分支）
git checkout master  # 或指定版本分支，如 release-22.04

# 编译并安装到本地
npm install
npm run build
npm link

# 返回gsa目录并创建本地链接
cd ~/source/gsa-22.4.0
npm link @greenbone/ui-components

# 然后再执行
npm i # 这时会跳过ui-components，因为已有本地链接

yarn build

sudo mkdir -p $INSTALL_PREFIX/share/gvm/gsad/web/
sudo cp -r build/* $INSTALL_PREFIX/share/gvm/gsad/web/

配置 GSAD

export GSAD_VERSION=$GVM_VERSION

sudo apt install -y
libmicrohttpd-dev
libxml2-dev
libglib2.0-dev
libgnutls28-dev

curl -f -L https://github.com/greenbone/gsad/archive/refs/tags/v$GSAD_VERSION.tar.gz -o $SOURCE_DIR/gsad-$GSAD_VERSION.tar.gz
curl -f -L https://github.com/greenbone/gsad/releases/download/v$GSAD_VERSION/gsad-$GSAD_VERSION.tar.gz.asc -o $SOURCE_DIR/gsad-$GSAD_VERSION.tar.gz.asc

gpg –verify $SOURCE_DIR/gsad-$GSAD_VERSION.tar.gz.asc $SOURCE_DIR/gsad-$GSAD_VERSION.tar.gz

tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/gsad-$GSAD_VERSION.tar.gz

mkdir -p $BUILD_DIR/gsad && cd $BUILD_DIR/gsad

cmake $SOURCE_DIR/gsad-$GSAD_VERSION
-DCMAKE_INSTALL_PREFIX=$INSTALL_PREFIX
-DCMAKE_BUILD_TYPE=Release
-DSYSCONFDIR=/etc
-DLOCALSTATEDIR=/var
-DGVMD_RUN_DIR=/run/gvmd
-DGSAD_RUN_DIR=/run/gsad
-DLOGROTATE_DIR=/etc/logrotate.d

make -j$(nproc)

make DESTDIR=$INSTALL_DIR install

sudo cp -rv $INSTALL_DIR/* /

配置 openvas-smb

export OPENVAS_SMB_VERSION=22.4.0

sudo apt install -y
gcc-mingw-w64
libgnutls28-dev
libglib2.0-dev
libpopt-dev
libunistring-dev
heimdal-dev
perl-base

curl -f -L https://github.com/greenbone/openvas-smb/archive/refs/tags/v$OPENVAS_SMB_VERSION.tar.gz -o $SOURCE_DIR/openvas-smb-$OPENVAS_SMB_VERSION.tar.gz
curl -f -L https://github.com/greenbone/openvas-smb/releases/download/v$OPENVAS_SMB_VERSION/openvas-smb-$OPENVAS_SMB_VERSION.tar.gz.asc -o $SOURCE_DIR/openvas-smb-$OPENVAS_SMB_VERSION.tar.gz.asc

gpg –verify $SOURCE_DIR/openvas-smb-$OPENVAS_SMB_VERSION.tar.gz.asc $SOURCE_DIR/openvas-smb-$OPENVAS_SMB_VERSION.tar.gz

tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/openvas-smb-$OPENVAS_SMB_VERSION.tar.gz

mkdir -p $BUILD_DIR/openvas-smb && cd $BUILD_DIR/openvas-smb

cmake $SOURCE_DIR/openvas-smb-$OPENVAS_SMB_VERSION
-DCMAKE_INSTALL_PREFIX=$INSTALL_PREFIX
-DCMAKE_BUILD_TYPE=Release

make -j$(nproc)

make DESTDIR=$INSTALL_DIR install

sudo cp -rv $INSTALL_DIR/* /

配置 openvas-scanner

export OPENVAS_SCANNER_VERSION=$GVM_VERSION

sudo apt install -y
bison
libglib2.0-dev
libgnutls28-dev
libgcrypt20-dev
libpcap-dev
libgpgme-dev
libksba-dev
rsync
nmap
libjson-glib-dev
libbsd-dev

sudo apt install -y
python3-impacket
libsnmp-dev

curl -f -L https://github.com/greenbone/openvas-scanner/archive/refs/tags/v$OPENVAS_SCANNER_VERSION.tar.gz -o $SOURCE_DIR/openvas-scanner-$OPENVAS_SCANNER_VERSION.tar.gz
curl -f -L https://github.com/greenbone/openvas-scanner/releases/download/v$OPENVAS_SCANNER_VERSION/openvas-scanner-$OPENVAS_SCANNER_VERSION.tar.gz.asc -o $SOURCE_DIR/openvas-scanner-$OPENVAS_SCANNER_VERSION.tar.gz.asc

gpg –verify $SOURCE_DIR/openvas-scanner-$OPENVAS_SCANNER_VERSION.tar.gz.asc $SOURCE_DIR/openvas-scanner-$OPENVAS_SCANNER_VERSION.tar.gz

tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/openvas-scanner-$OPENVAS_SCANNER_VERSION.tar.gz

mkdir -p $BUILD_DIR/openvas-scanner && cd $BUILD_DIR/openvas-scanner

cmake $SOURCE_DIR/openvas-scanner-$OPENVAS_SCANNER_VERSION
-DCMAKE_INSTALL_PREFIX=$INSTALL_PREFIX
-DCMAKE_BUILD_TYPE=Release
-DSYSCONFDIR=/etc
-DLOCALSTATEDIR=/var
-DOPENVAS_FEED_LOCK_PATH=/var/lib/openvas/feed-update.lock
-DOPENVAS_RUN_DIR=/run/ospd

make -j$(nproc)

make DESTDIR=$INSTALL_DIR install

sudo cp -rv $INSTALL_DIR/* /

配置 ospd-openvas

export OSPD_OPENVAS_VERSION=22.4.2

INSTALL_PREFIX=/usr
sudo apt install -y
python3
python3-pip
python3-setuptools
python3-packaging
python3-wrapt
python3-cffi
python3-psutil
python3-lxml
python3-defusedxml
python3-paramiko
python3-redis
python3-paho-mqtt

curl -f -L https://github.com/greenbone/ospd-openvas/archive/refs/tags/v$OSPD_OPENVAS_VERSION.tar.gz -o $SOURCE_DIR/ospd-openvas-$OSPD_OPENVAS_VERSION.tar.gz
curl -f -L https://github.com/greenbone/ospd-openvas/releases/download/v$OSPD_OPENVAS_VERSION/ospd-openvas-$OSPD_OPENVAS_VERSION.tar.gz.asc -o $SOURCE_DIR/ospd-openvas-$OSPD_OPENVAS_VERSION.tar.gz.asc

gpg –verify $SOURCE_DIR/ospd-openvas-$OSPD_OPENVAS_VERSION.tar.gz.asc $SOURCE_DIR/ospd-openvas-$OSPD_OPENVAS_VERSION.tar.gz

tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/ospd-openvas-$OSPD_OPENVAS_VERSION.tar.gz

cd $SOURCE_DIR/ospd-openvas-$OSPD_OPENVAS_VERSION

python3 -m pip install . –prefix=$INSTALL_PREFIX –root=$INSTALL_DIR –no-warn-script-location

sudo cp -rv $INSTALL_DIR/* /

配置 notus-scanner

export NOTUS_VERSION=22.4.1

INSTALL_PREFIX=/usr
sudo apt install -y
python3
python3-pip
python3-setuptools
python3-paho-mqtt
python3-psutil
python3-gnupg

curl -f -L https://github.com/greenbone/notus-scanner/archive/refs/tags/v$NOTUS_VERSION.tar.gz -o $SOURCE_DIR/notus-scanner-$NOTUS_VERSION.tar.gz
curl -f -L https://github.com/greenbone/notus-scanner/releases/download/v$NOTUS_VERSION/notus-scanner-$NOTUS_VERSION.tar.gz.asc -o $SOURCE_DIR/notus-scanner-$NOTUS_VERSION.tar.gz.asc

gpg –verify $SOURCE_DIR/notus-scanner-$NOTUS_VERSION.tar.gz.asc $SOURCE_DIR/notus-scanner-$NOTUS_VERSION.tar.gz

tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/notus-scanner-$NOTUS_VERSION.tar.gz

cd $SOURCE_DIR/notus-scanner-$NOTUS_VERSION

python3 -m pip install . –prefix=$INSTALL_PREFIX –root=$INSTALL_DIR –no-warn-script-location

sudo cp -rv $INSTALL_DIR/* /

配置 gvm-tools

sudo apt install -y
python3
python3-pip
python3-setuptools
python3-packaging
python3-lxml
python3-defusedxml
python3-paramiko

python3 -m pip install –user gvm-tools

python3 -m pip install –prefix=$INSTALL_PREFIX –root=$INSTALL_DIR –no-warn-script-location gvm-tools

sudo cp -rv $INSTALL_DIR/* /

配置 Redis-Server

sudo apt install -y redis-server

sudo cp $SOURCE_DIR/openvas-scanner-$GVM_VERSION/config/redis-openvas.conf /etc/redis/
sudo chown redis:redis /etc/redis/redis-openvas.conf
echo “db_address = /run/redis-openvas/redis.sock” | sudo tee -a /etc/openvas/openvas.conf

sudo systemctl start server@openvas.service"">redis-server@openvas.service
sudo systemctl enable server@openvas.service"">redis-server@openvas.service

sudo usermod -aG redis gvm

配置 Mosquitto MQTT

sudo apt install -y mosquitto

sudo systemctl start mosquitto.service
sudo systemctl enable mosquitto.service
echo “mqtt_server_uri = localhost:1883” | sudo tee -a /etc/openvas/openvas.conf

配置服务的权限

sudo mkdir -p /var/lib/notus
sudo mkdir -p /run/gvmd

sudo chown -R gvm:gvm /var/lib/gvm
sudo chown -R gvm:gvm /var/lib/openvas
sudo chown -R gvm:gvm /var/lib/notus
sudo chown -R gvm:gvm /var/log/gvm
sudo chown -R gvm:gvm /run/gvmd

sudo chmod -R g+srw /var/lib/gvm
sudo chmod -R g+srw /var/lib/openvas
sudo chmod -R g+srw /var/log/gvm

sudo chown gvm:gvm /usr/local/sbin/gvmd
sudo chmod 6750 /usr/local/sbin/gvmd

sudo chown gvm:gvm /usr/local/bin/greenbone-nvt-sync
sudo chmod 740 /usr/local/sbin/greenbone-feed-sync
sudo chown gvm:gvm /usr/local/sbin/greenbone--sync
sudo chmod 740 /usr/local/sbin/greenbone--sync

export GNUPGHOME=/tmp/openvas-gnupg
mkdir -p $GNUPGHOME

gpg –import /tmp/GBCommunitySigningKey.asc
gpg –import-ownertrust < /tmp/ownertrust.txt

export OPENVAS_GNUPG_HOME=/etc/openvas/gnupg
sudo mkdir -p $OPENVAS_GNUPG_HOME
sudo cp -r /tmp/openvas-gnupg/* $OPENVAS_GNUPG_HOME/
sudo chown -R gvm:gvm $OPENVAS_GNUPG_HOME

现在，键入 sudo visudo 并将以下行放在文件末尾：

allow users of the gvm group run openvas

%gvm ALL = NOPASSWD: /usr/local/sbin/openvas

配置 PostgreSQL（确保在第三个命令:D 将用户 > 的 <name 替换为您的用户名）

sudo apt install -y postgresql

sudo systemctl start postgresql@14-main

sudo chmod og+rX /home /home/<name of your user>

sudo -u postgres bash

createuser -DRS gvm

createdb -O gvm gvmd

exit

sudo -u postgres bash

psql gvmd

create role dba with superuser noinherit;

grant dba to gvm;

exit

配置 GVM 用户名和密码（确保在 <password> 字段中键入强密码）

gvmd –create-user=admin –password=<password>

配置 Feed 导入

gvmd –modify-setting 78eceaec-3385-11ea-b237-28d24461215b –value gvmd --get-users --verbose | grep admin | awk '{print $2}'

为系统守护程序配置服务：

使用

vim $BUILD_DIR/ospd-openvas.service

并粘贴以下行以配置 OSPD-OpenVAS：

[Unit]
Description=OSPd Wrapper for the OpenVAS Scanner (ospd-openvas)
Documentation=man:ospd-openvas(8) man:openvas(8)
After=network.target networking.service server@openvas.service"">redis-server@openvas.service
Wants=server@openvas.service"">redis-server@openvas.service
ConditionKernelCommandLine=!recovery

[Service]
Type=forking
User=gvm
Group=gvm
RuntimeDirectory=ospd
RuntimeDirectoryMode=2775
PIDFile=/run/ospd/ospd-openvas.pid
ExecStart=/usr/local/bin/ospd-openvas –unix-socket /run/ospd/ospd-openvas.sock –pid-file /run/ospd/ospd-openvas.pid –log-file /var/log/gvm/ospd-openvas.log –lock-file-dir /var/lib/openvas –socket-mode 0o770 –mqtt-broker-address localhost –mqtt-broker-port 1883 –notus-feed-dir /var/lib/notus/advisories
SuccessExitStatus=SIGKILL
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target

现在将服务配置复制到系统目录

sudo cp $BUILD_DIR/ospd-openvas.service /etc/systemd/system/

使用

vim $BUILD_DIR/notus-scanner.service

并粘贴以下行以配置 notus-scanner：

[Unit]
Description=Notus Scanner
Documentation=https://github.com/greenbone/notus-scanner
After=mosquitto.service
Wants=mosquitto.service
ConditionKernelCommandLine=!recovery

[Service]
Type=forking
User=gvm
RuntimeDirectory=notus-scanner
RuntimeDirectoryMode=2775
PIDFile=/run/notus-scanner/notus-scanner.pid
ExecStart=/usr/local/bin/notus-scanner –products-directory /var/lib/notus/products –log-file /var/log/gvm/notus-scanner.log
SuccessExitStatus=SIGKILL
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target

现在将服务配置复制到系统目录

sudo cp $BUILD_DIR/notus-scanner.service /etc/systemd/system/

使用打开 gvmd.service 文件

vim $BUILD_DIR/gvmd.service

并粘贴以下行以配置 GVMD：

[Unit]
Description=Greenbone Vulnerability Manager daemon (gvmd)
After=network.target networking.service postgresql.service ospd-openvas.service
Wants=postgresql.service ospd-openvas.service
Documentation=man:gvmd(8)
ConditionKernelCommandLine=!recovery

[Service]
Type=forking
User=gvm
Group=gvm
PIDFile=/run/gvmd/gvmd.pid
RuntimeDirectory=gvmd
RuntimeDirectoryMode=2775
ExecStart=/usr/local/sbin/gvmd –osp-vt-update=/run/ospd/ospd-openvas.sock –listen-group=gvm
Restart=always
TimeoutStopSec=10

[Install]
WantedBy=multi-user.target

现在将服务配置复制到系统目录

sudo cp $BUILD_DIR/gvmd.service /etc/systemd/system/

使用打开 gsad.service 文件

vim $BUILD_DIR/gsad.service

并粘贴以下行以配置 GSAD：

[Unit]
Description=Greenbone Security Assistant daemon (gsad)
Documentation=man:gsad(8) https://www.greenbone.net
After=network.target gvmd.service
Wants=gvmd.service

[Service]
Type=exec
User=gvm
Group=gvm
RuntimeDirectory=gsad
RuntimeDirectoryMode=2775
PIDFile=/run/gsad/gsad.pid
ExecStart=/usr/local/sbin/gsad –foreground –listen=127.0.0.1 –port=9392 –http-only
Restart=always
TimeoutStopSec=10

[Install]
WantedBy=multi-user.target
Alias=greenbone-security-assistant.service

现在将服务配置复制到系统目录

sudo cp $BUILD_DIR/gsad.service /etc/systemd/system/

使用以下命令激活所有服务：

sudo systemctl daemon-reload

使用以下命令启用所有服务，以便每次都不需要手动启动它们：

sudo systemctl enable notus-scanner

sudo systemctl enable ospd-openvas

sudo systemctl enable gvmd

sudo systemctl enable gsad

使用以下命令同步 NVT 源（尽管互联网速度很好，但这可能需要很多时间）。如果你在机构中进行这项设置，请确保要求网络团队为你的系统打开 rsync 端口，因为它很可能会被关闭。Rsync 通常在端口 873 上运行。

sudo -u gvm greenbone-nvt-sync

使用以下命令下载 SCAP、CERT 和 GVMD 数据，确保一一使用这些命令（尽管互联网速度很好，这可能需要很多时间）：

sudo -u gvm greenbone-feed-sync –type SCAP

sudo -u gvm greenbone-feed-sync –type CERT

sudo -u gvm greenbone-feed-sync –type GVMD_DATA

启动所有服务

sudo systemctl start notus-scanner

sudo systemctl start ospd-openvas

sudo systemctl start gvmd

sudo systemctl start gsad

虚拟化技术介绍

Sun, 14 Jul 2024 20:09:20 +0800

虚拟化技术介绍

极简介绍

对于我们想要虚拟化的对象，提供实际资源之上的抽象。应用不同抽象级别将会呈现不同的虚拟化技术。

基于抽象级别的虚拟化技术有两类最为常用：

基于虚拟机(VM)：虚拟化整个操作系统，换句话说是虚拟化完整的ISA
基于容器(Container)

[toc]

Hypervisors

用于虚拟化的特殊软件通称，其本身有两个部分：

Virtual Machine Monitor(VMM)：捕获和模拟特权指令集(仅操作系统内内核可以运行)
Device model：设备模型，用于虚拟化I/O设备

VMM

硬件在绝大多数情况下不能直接在虚拟机上使用，因此需要通过VMM捕获硬件(磁盘、网卡…)的特权指令，并代表虚拟机执行这些指令。其需满足三个属性：

隔离性：将guest(VMs虚拟机)彼此进行隔离
等效性：有没有使用虚拟化，对于硬件角度来说执行表现应当相同；即没有在翻译的情况下在硬件执行(几乎所有的)指令
性能：有与没有虚拟机的情况下性能应做到(几乎)一致，即虚拟机的开销应尽可能的小

功能

不能访问特权级，VMM应截获这些请求并模拟特权级调用
异常处理和中断
大部分cpu指令直接在物理机CPU上运行，仅在陷入某些特权指令才使用虚拟化CPU(运行效率基本与在物理机一致)
I/O的地址映射

内存虚拟化

影子页表
硬件支持EPT

CPU虚拟化

见这篇文章，对虚拟化特权级进行了全面解释。

代码定位见此

全虚拟化与半虚拟化

全虚拟化中，客户OS(guest OS)“不知道”自己运行在虚拟环境中，它的运行状态和在物理机中相同；而半虚拟化状态中，guest OS对虚拟环境做了特化，I/O的系统调用会被hypercalls替换掉。

它们的结构区别如下图所示：

半虚拟化状态中，guest os的驱动程序被称为前端驱动程序，主机的被称为后端驱动程序，这种前后端的实现方式很大的提高了交互效率，具体见virtio

对于I/O虚拟化，参见sriov

Hypervisors介绍

INTEL有两种虚拟化风格：Vt-x和Vt-i

Vt-x：适用于Intel x86 32或64位架构
Vt-i：适用于安腾处理器系列

本节将更为熟悉的Vt-x指令集

VT-x指令集

物理机中，执行顺序是程序指令->CPU指令；
而在虚拟机中，执行顺序是程序指令->虚拟CPU指令->CPU指令。
这将导致指令翻译两次，会造成巨大开销(详见这篇文章)

通过抽象CPU指令到虚拟指令，即对CPU指令扩充一些虚拟专用指令，可以在虚拟机完成：程序指令->CPU指令

对于Vt-x来说，它还做了一些权限分割上的工作，具体可见这篇关于ring -1的回答

细节了解和代码定位，参考这篇博客

KVM创建虚拟机

在用户态中创建虚拟机的过程如下：

创建一个裸VM
映射VM的用户空间内存
创建VCPU/IRQCHIP，并映射vt-x指令集
其他硬件配置：寄存器、FPU、LAPIC等
启动VM

具体信息和代码定位详见KVM官网相关文档

基于vhost的数据交互

这里以一个vhost-net设备的生命周期为例。

该设备初始化时，会为QEMU对应进程创建一个内核线程，专门处理guest I/O，该线程侦听主机端virtqueues上的事件。

事件为传输时，guest上的TX(传输)队列排出(virtio术语叫kick)数据包，线程将该包放到抽头设备(tap)，后继续使用正常底层网络设备(路由、交换机)等进行常规网络包传输工作；接收(RX)同理。

事件注册采用eventfd机制，这是文件描述符，具体功能和机制参见这篇博客。

其他虚拟化尝试

Unikernel

作为虚拟化技术的一种尝试，基础思想就是；仅将应用所需的环境包装到虚拟环境中，即一个虚拟机完成单一的应用功能。好处显然易见——轻量、安全、快速。但是单一的应用和复杂的打包机制也成为制约unikernel不利条件。

其基础概念可以查看官网
与容器的比较可以参考这篇博客

Project-Dune

斯坦福大学设计的一种机制，可以通过虚拟化技术让用户程序跑在ring 0中，即在非特权的上下文中执行特权指令。

原理可用一张图表示：

代码被分为受信任部分和非受信任部分，它们都运行在同一个物理地址上，但受信任的代码所在页被hypervisor bits位标记保护。受信任的代码通过Dune进程(由libdune库提供)运行在ring 0，非受信任的代码运行在ring 3。

详细信息可查阅project-dune官网

novm

在VM中提供了一个文件系统，而非块设备。是一种虚拟机的轻量化实现。

具体可见github项目

容器

Linux容器有三个组成基础：

namesapce：Linux资源的可见性
cgroups：资源配额控制
文件分层系统：容器的文件系统，实现内存和磁盘的共享

Namespace

命名空间是Linux中的一种进程的逻辑隔离技术，即缩小进程的可见性。对于namespace的进程来说，它看不到除自己namespace外的其他资源。

namespace有很多类型：

UTS
PID
Mount
Network
IPC
cgroup
time

其详情介绍可以参考wiki

原理分析和用法可以参考这篇博客，这大哥的博客写的是真好，从实践到原理到源码介绍的非常细致。如果有时间推荐两部分都看一下。

Cgroup

cgroups（Control Group）是一项 Linux 内核功能，用于限制、说明和隔离进程集合的资源使用情况（CPU、内存、磁盘 I/O 等）
有两个版本，v1(2.6.24)和v2(4.5)。

v2的版本介绍可以参考wiki百科和kernel官方文档

v1的版本介绍可以参考kernel官方文档

分层文件系统

文件系统

Linux的设计理念是“万物均文件”，即系统中所有对象均使用文件进行抽象，访问这些对象和访问文件的过程是一致的(包括块文件和非块文件)。

Linux使用虚拟文件系统(VFS)层抽象所有文件系统。所有文件系统均在VFS中注册。其具有以下重要的数据结构：

文件
INODE
目录项
超级块

详细内容可以参考这篇文章，和这个专栏系列中文件系统部分

伪文件系统

对于一些非块文件如procfs，它们可能通过文件接口公开内核的的一些资源，这些文件系统被称为伪文件系统。

可参考论坛回答

分层文件系统简介

在上述Linux文件系统中，有两件事是容器需要但其无法满足的：

内存共享
磁盘空间共享

在分层文件系统中，文件系统被分成多层，每层都是只读文件系统。

这些层在同意主机上的容器之间共享，且inode是相同的，它们将会引用相同操作系统页面进行缓存。

下面将介绍两种Linux中正在使用的分层文件系统。

unionfs(UFS)

unionfs允许管理员将文件在物理上分开，但在逻辑上合并到单个视图中。

合并目录的集合称为联合(黄色部分)，每个物理目录称为分支(蓝色部分)。

每个分支都分配有一个优先级。具有较高优先级的分支会覆盖具有较低优先级的分支。 Unionfs 对目录进行操作。如果一个目录存在于两个底层分支中，则Unionfs目录的内容和属性是两个较低目录的组合。 Unionfs 自动删除任何重复的目录条目，因此用户不会因重复的文件名或目录而感到困惑。如果一个文件存在于两个分支中，则Unionfs文件的内容和属性与高优先级分支中的文件相同，而低优先级分支中的文件被忽略。

需要注意的是，当多个同名文件挂载到同联合中时，默认复制第一个文件中的内容。

测试：

$ ls /Fruits
Tomato hi/
$ ls /Veg
Tomato

$ cat /Fruits/Tomato
I am botanically a fruit.
$ cat /Veg/Tomato
I am horticulturally a veg.

# 联合目录挂载到 Eat
$ mount -t overlay -o dirs=/Fruits:/Veg overlay /Eat

# 查看Tomato的内容
$ cat /Eat/Tomato
I am botanically a fruit.

# 查看目录合并结果
$ ls /Eat

unionfs包括aufs均已过时，现在基本都用overlay或overlay2作为容器的文件系统。

参考如下链接：

祖宗：2004年的Linux期刊
 原理剖析+源码解读
 @knoldus/unionfs-a-file-system-of-a-container-2136cd11a779">直观图片+完整实验

Overlayfs

Linux 3.18内核版本之后，overlayfs被集成进内核。

其作用是将一个目录地内容覆盖到另一个目录上

当前有两个版本：v1和v2
v1有两层:

lower：只读层
upper：读写层

规则：

当进程“读取”文件时，overlayfs文件系统驱动将优先在上层目录upperdir中查找并从该目录中读取文件，找不到则在下层目录lowerdir中查找。
当进程”写入”文件时，overlayfs会将其写入上层目录upperdir。

v2有三层：

base: 基础层，创建时初始化，是只读层
overlay: 提供从基本层的可见性，当基础层文件发生更改，则存储到其下一层
diff: 在overlay做的更改存储于此。基础层的任何文件/目录更改都会将文件从基础层复制到diff层，然后将更改写入diff层

v2示例：

初始化创建

root@instance-1: mkdir base diff overlay workdir 
root@instance-1: echo "test data" > base/test1 
root@instance-1: sudo mount \ > -t overlay \ 
> -o lowerdir=base,upperdir=diff,workdir=workdir \ 
> overlay \ 
> overlay

过程和上一节一致，不做赘述。

修改overlay

root@instance-1:/overlay# touch test2 
root@instance-1:/overlay# ls test1 
test2 
root@instance-1:-/overlay# cd ../diff 
root@instance-1:-/diff# ls 
test2

可见修改的结果在diff中可见

可以动手试试修改文件内容，看在overlay和base中如何变化

参考这篇博客

Dfi：一个面向大规模代码库的过程间价值流分析框架

Fri, 26 May 2023 11:31:38 +0800

解决痛点

由于内存和运行时需求较高，目前的价值流计算方法无法扩展到大型代码库。

价值流分析

价值流分析是数据流分析的一个子集，它有助于静态地分析变量和内存块等程序结构之间的依赖关系。它支持许多关键的程序分析技术，这些技术被广泛用于编译器优化和寻找安全漏洞：指向分析、空指针分析和污点分析。为了有效地操作，这类技术通常需要精确的价值流信息，这些信息具有上下文和流敏感以及过程间性。” <span class="citation" data-citation="%7B%22citationItems%22%3A%5B%7B%22uris%22%3A%5B%22http%3A%2F%2Fzotero.org%2Fusers%2F8438660%2Fitems%2FMZGEWCFE%22%5D%2C%22locator%22%3A%221%22%7D%5D%2C%22properties%22%3A%7B%7D%7D" ztype="zcitation">(<a href="zotero://select/library/items/MZGEWCFE">Hsu 等, 2022, p. 1</a>)

创新点

开发一种新的图结构，采用LLVM IR扩展，多了两个操作，简化指针混淆的建模
由上个方式产生的用于价值流分析的def-use链的轻量级和精确的稀疏表示，包含顶层变量和获取地址的变量
一个通过图可达性求解价值流的算法，该算法的规模几乎与处理的顶点数量成线性关系，需要的内存显著减少，而且显著快于以前的解决方案
基于LLVM IR，可扩展到包含数十万行代码的大型现实项目

DFI 设计与实现

DFI主要包括两个主要组成部分：

主分析引擎
客户端分析

首先，分析引擎基于客户端提供的价值流映射信息计算得到运行过程内的DFT间隔；

其次，过程内的价值流被传递到它们的调用者以支持过程间查询；

最后，客户端分析将受到流和上下文敏感的价值流结果，以解决其领域特定的作用

预处理：修改了两个操作

dfi.store：将更新的存储量用不同的标记存储，使得可以用跟踪标量值相同的方法跟踪强更新的内存依赖dfi.call：为捕获输出参数传输的价值流，DFI将llvm.call替换为dfi.call

程序内（运行过程内）分析：

价值流分析可以归结为一个图可达性问题，其中每个顶点都是程序点上的数据流事实，通过判断两个顶点的可达性来解决价值流分析问题。

核心思想：对于一个给定的价值流分析问题，如果程序中的每一个相关操作都被注释为DFT区间，那么可以通过比较任意两个操作在几乎恒定时间内的区间来判断它们之间的可达性。
为了演示这个概念，图3给出了一个MLIR函数，其中的值用DFT区间进行了标注。例如，值% p和% 1的区间分别为⟨0，5和⟨1，4。这些区间标注在由SSA定义-引用图衍生的生成树上，由从单个SSA值定义到其用途的边组成。假设对图3进行污点分析，% p为污点值。为了判断返回值% 3是否被污染，只需检查其区间⟨2，3 “是否被% p⟨0，5 “所包含。在这种情况下，由于⟨0，5⋅⊇⟨2，3⋅根据我们在2.3节的定义，返回值是污点。事实上，% 1和% 3都是污点，因为它们的区间都在⟨0，5 “的子树内。另一方面，间隔为⟨7，8的% 0不被污染，因为它位于以⟨6，9为根的不同DFT子树中。”
为了计算图3所示的树和相关区间，客户端分析自定义了2.3节中介绍的遍历机制。首先，对于每个函数，客户端分析选择一组根顶点开始遍历。注意，每个函数中的遍历时间戳总是从零开始。其次，对于函数中的每个顶点，通过客户端分析提供一个局部转移函数来指示离开的顶点进行下一次访问。在图3污点分析的背景下，客户端分析选择% a和% p作为遍历根。对于局部传递函数，每类运算的规则如图4所示。以dfi . store规则为例，其中仅当存储值% v被污染时，结果指针% q才被污染。它有效地停止了从% p到% q的DFT遍历，但允许从% v到% q的路径。” <span class="citation" data-citation="%7B%22citationItems%22%3A%5B%7B%22uris%22%3A%5B%22http%3A%2F%2Fzotero.org%2Fusers%2F8438660%2Fitems%2FMZGEWCFE%22%5D%2C%22locator%22%3A%225%22%7D%5D%2C%22properties%22%3A%7B%7D%7D" ztype="zcitation">(<a href="zotero://select/library/items/MZGEWCFE">Hsu 等, 2022, p. 5</a>)

DEF-USE的非树边

非树边的存在抑制了图的可达性在一般SSA的DEF-USE图上的应用，因此，减少非树边是一件很必要的事情。

采用反转图：可以有效避免多参数情况下的函数产生的非树边问题。

增广DFT区间图的可达性：在遇到非树边时复制区间，以此可以使用两个区间之间相似的包含关系确定它们的可达性

区间集Π:
其中每个元素之间至少有一个时间戳，满足：
区间包含关系，若区间中任意子区间（可以是一个元素）对另一区间存在包含关系，则该区间集包含另一区间：
区间合并：两个区间可以通过∪操作合并。在可达性算法中，每个DEF-USE图的顶点v和一个区间集相关联。vi可以达到vj需满足两个区间集存在包含关系，即：
例子

交集运算符（成立前提？）
交集运算符指定价值流如何从不同的程序路径进行组合，例如在控制流合并点。在我们的算法中，我们使用区间集合merge∪作为我们的相遇算子。根据我们之前对∪的定义，合并后的区间集总是对传入的区间集的一个安全近似，从而保证了可靠性。” <span class="citation" data-citation="%7B%22citationItems%22%3A%5B%7B%22uris%22%3A%5B%22http%3A%2F%2Fzotero.org%2Fusers%2F8438660%2Fitems%2FMZGEWCFE%22%5D%2C%22locator%22%3A%226%22%7D%5D%2C%22properties%22%3A%7B%7D%7D" ztype="zcitation">(<a href="zotero://select/library/items/MZGEWCFE">Hsu 等, 2022, p. 6</a>)

程序间过程分析
通过构建一个函数价值流摘要来总结每个函数的价值流。这个价值流摘要被传递到所有它的调用点。由于新引入的被调用方会改变调用方函数内部的价值流，因此该过程将重复执行，直到达到一个固定点。

函数价值流摘要由函数参数和输出结果之间的一组可达关系组成。摘要描述了参数和结果之间的映射，该映射通过参数和结果索引来表示。
结果索引等于dfi.call操作的结果列表中对应的索引。
调用时，原始返回值（若有的话）的索引为0，后面跟着指针参数类型的结果

我们记I ( p )为参数p的参数指标。此外，O ( p )被定义为p的结果指标，如果p是PTf的一部分，PTf是f包含所有指针参数的函数参数的子集。函数f的价值流汇总记为Sf = SRf∪SPf。集合SRf和SPf分别表示从函数参数到返回值和输出参数的映射。Rf和Pf是f返回值和参数的集合，SRf被定义为：

SPf捕获应用于函数f中的指针参数的潜在价值流。它包含指针参数和DFI.call上相应输出结果之间的映射由于指针参数的结果再被调用方中难以定位，因此DFI使用了指针参数和反向根之间的可达性作为近似结果处理。对于任意两个指针参数p0和p1，用和

对SPf进行初始化。如果p0和p1都可达逆根┏，那么就可以把和

这两个可达条件添加到SPf中，令Tf是f的逆根集合，SPf就被定义为：
两个例子
列表3：由于存在包含关系因此a，c可达r，SRf == Sf，为：
列表4：k’和r’分别对应k和r在一个调用点的结果。由于k和r都可达t1，因此SRf：

价值流摘要值的传播：将被调者函数的价值流摘要传播到调用者，以便将上下文敏感的价值流信息添加到调用者函数
得到这些摘要值Sf后，需要将Sf传播到所有调用f的节点。在更高层次（？）上，Sf提供了每个调用f节点所缺的本地价值流映射。通过这些信息可以在调用者函数中添加新的价值流以提高精度。传播包括两步：
第一步：对于Sf中每个vs -> vd，在每个调用函数中执行另一轮的反向DFT遍历。不过不采用客户端分析的假根，而是采用vs的实际参数作为反向根。
第二步：使用第一步的结果在每个调用点上以相反的方向传播
一个例子：
- 第一步：从第八行调用f。在这里使用%s0和%b（实际参数的%v %p）作为反向根进行反向DFT遍历
- 第二步：将第一步得到的%s0和%b的区间集在增广DFT中过渡性地合并到其父节点和祖先节点（如%s3）的区间集合中，直到达到原来的反向根

采用的算法是使用一个基于工作表的算法，递归地改变总结传播给其调用者，直到达到一个固定点：
在算法1中，GetV FSummary ( f )返回函数f的Sf；PropagateSummary( Sf , c)在调用函数c中执行前面介绍的带有被调用者值-流摘要Sf的两阶段传播。 <span class="citation" data-citation="%7B%22citationItems%22%3A%5B%7B%22uris%22%3A%5B%22http%3A%2F%2Fzotero.org%2Fusers%2F8438660%2Fitems%2FMZGEWCFE%22%5D%2C%22locator%22%3A%227%22%7D%5D%2C%22properties%22%3A%7B%7D%7D" ztype="zcitation">(<a href="zotero://select/library/items/MZGEWCFE">Hsu 等, 2022, p. 7</a>)

可达功能的摘要：将传播过程扩展到一个可达函数的摘要。

通过区间集Π vb⊇Π va确定两个值va和vb在同一函数中的可达性，可以计算具有流量和上下文敏感性的程序间的价值流。在这一部分中，将这种能力推广到任意函数中的va和vb。
一个可达函数摘要Ψ ( ε )提供了一个从端点ε到可通行端点集合的映射。端点εif表示函数f的第i个参数。

一个例子：
ε

0

f 

的摘要值为：

对于函数所有的所有参数，Ψ被反复传播到它的所有调用者，并与它们的摘要值合并，直到达到一个固定值，即所有可达函数的摘要值都不发生变化为止。

对于某个可达函数摘要，可以执行一个两阶段的过程来回答不同函数中的va->vb是否是可达的：

计算集合检查对于任意的索引j是否包含函数g的端点ε

j

g

。
只有当前端点ε

j

g 

可以达到vb时，va才能达到vb，即：

评估

回答两个问题：

在大型代码库上的扩展效果如何，如其他的价值流分析工具相比？
DFI中回答图的可达性的效率与每个顶点关联的区间集的大小强相关。在所有顶点上间隔集的大小分布如何？

所有实验在10分钟内完成，使用的物理内存不超过4.5 GB。

TRUSTFLOW：降低DFI内存开销的硬件DFI机制

Fri, 26 May 2023 11:30:33 +0800

一句话概述

设计了低开销细粒度的DFI硬件机制，对软件开销影响度为0%

主要功能

一个旁路的硬件设备，备份内存中的敏感数据，可以跟踪数据流完整性、检测内存漏洞、记录异常，敏感数据被篡改时还原数据。

主要贡献

提出TRUSTFLOW：一个具备针对数据细粒度预防、检测和处理基于内存漏洞的新概念
采用RISC-V架构的TRUSTFLOW的硬件实现，使用Chisel中的Rocket Chip generator生成
扩展RISC-V GNU指令：新增了两条保护内存敏感数据的指令
修改了RISC-V GNU工具链，使得3中的两条指令可以应用于编译器
评估：使用生命关键型应用进行评估

TRUSTFLOW

前提假设：系统上运行的软件包括缓冲区溢出、off-by-one或格式化字符串等漏洞，且软件皆以经过静态认证，且不包含任何恶意软件。

rowhammer和侧信道攻击不计入本实验讨论范围

核心理念：检测攻击的过程应与保护关键系统的敏感数据一样重要

详细设计

添加一块可信内存，TRUSTFLOW提供自定义加载和自定义存储。该内存备份普通内存中的敏感信息（如令牌、返回地址、指针、迭代数据等），该内存中不仅保存敏感信息的地址，还保存敏感信息的值。当普通内存中的敏感数据安全更新时，可信内存也一同更新（保护敏感数据）
使用转译后备缓冲区（TLB）作为信任内存，该内存通过单个时钟实现查找表提供高速搜索功能，该内存速度与L1缓存一致，因此不会产生多余开销
为优化空间使用，TRUSTFLOW会删除属于堆栈中已释放地址的受信任内存条目
新增指令：sws和lws，这两个指令继承经典sw和lw的功能，并可以与可信的转译后备缓冲区TLB（可信内存）交互
- sws rs, imm(rd)：存储一个字并在可信内存中复制一份（特权级指令）
- lws rd, imm(rs)：加载一个字并使用可信内存中的数据检查其完整性（特权级指令）
指令使用时，在存储阶段，管道检测到自定义指令信号(“mem_reg_inst信号“)。然后，增加的逻辑会检索管道中用于处理敏感字(“io_req_bits_addr“,“io_dmem_resp_bit_data“)和敏感地址(“memAddr“)的信号，这些信号需要存储、检测到可信内存或从可信内存中取出。最后，在使用可信内存执行决策性操作之前，管道的最后会检查这些自定义指令的有效性来确保不会将不稳定的数据放入可信内存中。
1. 内存访问阶段
  - 使用“mem_reg_inst”信号检测自定义指令
  - 从ALU输出中检索加载/存储字的地址(“io_req_bits_addr信号“)
  - 对于sws指令，要存储在内存中的字在”mem_reg_rs2”信号中处理
  - 扩展等待回写阶段以确认指令的有效性
2. 回写阶段
  - 在阶段1中使用lws指令内存加载的字由”io_dmem_resp_bit_data”信号中的影子逻辑收集
  - 如果自定义指令在这个阶段有效，那么相应的操作将由影子逻辑继续执行
    - sws：在”mem_reg_rs2”中包含的字与”io_req_bits_addr”中包含的地址将被发送到信任内存(TLB)中
    - lws：将”io_dmem_resp_bit_data”信号中包含的字与影子内存中的”io_req_bits_addr”地址处的字进行比较，若出现差异，则引发数据流异常
可信TLB的输出接口直接连接到核心异常和处理器上的寄存器堆。当发生异常时，操作系统可以记录并报告异常；同时，损坏的数据在写入寄存器堆之前被可信TLB中的健康数据替换。如果管道中内存访问阶段或执行阶段存在危害，则健康数据将从回写阶段转发到内存访问阶段或执行阶段。

编译器支持

自定义指令支持被移植到RISC-V GNU工具链，添加的指令没有用过多代码。预定义部分添加代码如下：

“MASK“值定义了指令中固定的位
“MATCH“用于定义由”MASK”设置的固定位的位值。

可以看到，”MASK”和原先的值是一样的，它们通过不同的”MATCH”进行区分。

基于TRUSTFLOW的安全策略

TRUSTFLOW的策略是灵活的，可以实现影子堆栈和指针完整性

影子堆栈

函数调用时，函数地址放置在调用堆栈和影子对战中；函数返回时，返回地址同时从调用堆栈和影子堆栈弹出，若两个值不同，则检测到内存冲突。下图右侧为使用了TRUSTFLOW实现的影子堆栈：

TRUSTFLOW可以解决影子堆栈经典[setjmp/longjmp](https://zhuanlan.zhihu.com/p/464553050)失败问题。当长跳转时，影子堆栈中的返回地址与调用堆栈的返回地址大概率不匹配；而TRUSTFLOW的设计中，只在重新访问敏感数据时检查数据完整性，而不会出现在返回过程中。

指针完整性

通过篡改函数指针（间接调用）达到破坏控制流是常见做法，TRUSTFLOW可以通过指令级操作完成对函数指针的保护。

其弊端是需要开发者选择敏感指针进行保护，对开发人员专业素养要求很高。

循环监测和通用数据

部分攻击针对循环迭代数据，使程序失常。通过控制循环，攻击者可能会溢出缓冲区或从内存中泄露一些秘密字节。

上图右边使用定制化指令进行数据保护（使用影子内存），可以降低循环中非控制数据攻击的有效性。

评估

影子逻辑所用范围
使用[”very secure pump model”](https://github.com/r3glisss/SecPump)等生命关键软件挑战TRUSTFLOW
软件层面，评估用于2类应用程序的信任内存的百分比

VSPM实验结果

测试环境：存在内存损坏漏洞的VSPM，允许攻击者控制执行流，能够改变关键设备的行为并注射致命剂量给患者。

应用有：4205条指令，89个函数、1000+行C代码

结果：程序正常运行，保护的敏感数据约为0.25KB

不足

空间换时间：所需额外的TLB空间不小
没有良好分析工具：该方法当下只能手动选取敏感节点替换”lws”和”sws”

Referred in 研究生毕设

Linux通用配置相关问题（持续更新）

Fri, 26 May 2023 11:26:08 +0800

apt/dnf/apt自动安装路径

参考这个回答一般而言，Linux不同发行版采用pkg-config功能会自设一个安装路径，使用

pkg-config --variable=pc_path pkg-config

可以查看默认的安装路径，当源码安装依赖后，相关程序无法找到依赖时需要注意路径

踩坑案例

某次编译报错：

其中，tpm2-tss v2.3.2版本的软件是dnf自动安装的，软件需求v2.3.3版本以上，而本机已经安装2.3.3版本，仍然报错，查看pkg-config默认路径

而2.3.3版本安装在/usr/local/lib/pkgconfig中，因此无法索引到2.3.3版。此时我的解决方案是：

删除老版本dnf remove tpm2-tss-devel
复制新版的.pc文件cp -a /usr/local/pkgconfig/*.pc /usr/lib64/pkgconfig/
再次编译，通过

TOOLS

Fri, 26 May 2023 11:23:30 +0800

内核版本：5.19.0
说明：本博客为学习笔记，仅做记录用。

bpf_tracing.h

BPF_PROG

bpf中PROG实现，以宏定义形式给出
源码：tools/lib/bpf/bpf_tracing.h#L425

#define BPF_PROG(name, args...)                            \
name(unsigned long long *ctx);                            \
static __attribute__((always_inline)) typeof(name(0))                \ // 返回值
____##name(unsigned long long *ctx, ##args);                    \  // 实际函数名
typeof(name(0)) name(unsigned long long *ctx)                    \
{                                        \
    _Pragma("GCC diagnostic push")                        \
    _Pragma("GCC diagnostic ignored \"-Wint-conversion\"")            \
    return ____##name(___bpf_ctx_cast(args));                \   // 真正执行内容
    _Pragma("GCC diagnostic pop")                        \
}                                        \
static __attribute__((always_inline)) typeof(name(0))                \
____##name(unsigned long long *ctx, ##args)

PERF & RING BUFFER

Fri, 26 May 2023 10:35:11 +0800

总述

BPF中，内核向用户空间发送数据使用的缓冲区称为PERF缓冲区；在Linux 5.8版本之后，可以使用环形缓冲区RING BUFFER（RB）

RING BUFFER优势

降低内存开销：PERF为每个CPU分配缓存；RB为所有CPU分配一个共享的大缓冲区
1. “大缓冲区”一位置更好容忍数据毛刺
2. 内存使用效率更高
3. 内存拓展性更好，如CPU数量增加时，PERF的buffer跟着翻倍，而RB可能不需要新增那么多内存
保证事件顺序：由于per-CPU特性，如果事件发生间隔非常短且分散在不同CPU中，事件的发送顺序就可能乱掉；RB由于共享同一个缓冲区，就不会有上述问题
减少数据复制：PERF必须先初始化一份事件数据，然后复制到perfbuf，之后发送到用户口空间，因此，数据会被复制两次；RB会首先为数据预留空间，预留成功后可以直接把发送的数据放到RB中，无需像PERF一样多一次将数据复制到局部变量中

PERF和RF主要结构对比

PERF：

struct perf_buffer {
    perf_buffer_event_fn event_cb;
    perf_buffer_sample_fn sample_cb;
    perf_buffer_lost_fn lost_cb;
    void *ctx; /* passed into callbacks */

    size_t page_size;
    size_t mmap_size;
    struct perf_cpu_buf **cpu_bufs;
    struct epoll_event *events;
    int cpu_cnt; /* number of allocated CPU buffers */
    int epoll_fd; /* perf event FD */
    int map_fd; /* BPF_MAP_TYPE_PERF_EVENT_ARRAY BPF map FD */
};

RB:

struct ring_buffer {
    struct epoll_event *events;
    struct ring *rings;
    size_t page_size;
    int epoll_fd;
    int ring_cnt;
};

例程

见该篇博客第三部分

eBPF概述

Fri, 26 May 2023 10:26:33 +0800

起源

1992年论文，其提出了一个由内核直接过滤网络包，减少用户态的无效克隆

伪机器码、BPF指令集、JIT

伪机器码

不能在物理机上直接运行，需要在虚拟机上执行

BPF指令集

是伪机器码，在初期由于BPF功能较少，只用在网络数据包过滤，因此早期的BPF指令集只需要几个库（如tcpdump的实现基于libcap库）就可以将一般的表达式生成BPF指令集；

但随着BPF的发展，指令集的复杂、支持的BPF程序类型增多，就需要编译器了

JIT

just in time的缩写，用于将BPF指令直接编译成机器码，大大提高了执行效率

eBPF介绍

eBPF是extend BPF的简称，也就是扩展的BPF。因此早期的BPF称为cBPF

二者对比

eBPF类型和Map机制

Map机制中，内核和用户共享一块内存，一般由内核存，用户取

所用语言

cBPF是直接写指令，后发展为C语言，通过clang/llvm进行编译为字节码，注入还是要手动

因此出现了python的bcc库和更新的libbpf，其完成了编译、解析ELF、加载BPF代码以及创建map，用户只需要设计bpf代码

工作原理如下：

BPF作用

libbpf支持的hook点（节选）

PVE为虚拟机添加vmdk硬盘

Mon, 07 Nov 2022 17:24:29 +0800

PVE为虚拟机添加vmdk硬盘

pve版本：7.2.1

创建虚拟机

不添加磁盘，使用Seabios

导入磁盘文件

在上传vmdk之后，键入如下指令导入磁盘到镜像中

qm importdisk [vmID] [vmdk] local-lvm --format qcow2

出现如下图所示过程，并在dashboard中对应虚拟机出现磁盘即为成功

挂载磁盘

双击未使用的磁盘，修改其为总线设备

完成后点击添加，完成磁盘挂载。

修改启动顺序

进入选项栏，双击修改引导顺序

首先启用ide0

然后拖拽ide0设备到第一引导设备

启动测试

完成

瑙哥空间

利用Linux NS和cGroups机制简单实现容器进程划分

利用NS和cGroup区分容器进程和非容器进程

核心思路

准备和编译环境

安装依赖:

编译项目:

运行和验证

Ubuntu2204安装OpenVas【译+一些适配上的见解】

allow users of the gvm group run openvas

虚拟化技术介绍

虚拟化技术介绍

极简介绍

Hypervisors

VMM

功能

内存虚拟化

CPU虚拟化

全虚拟化与半虚拟化

Hypervisors介绍

VT-x指令集

KVM创建虚拟机

基于vhost的数据交互

其他虚拟化尝试

Unikernel

Project-Dune

novm

容器

Namespace

Cgroup

分层文件系统

文件系统

伪文件系统

分层文件系统简介

unionfs(UFS)

Overlayfs

初始化创建

修改overlay

Dfi：一个面向大规模代码库的过程间价值流分析框架

解决痛点

价值流分析

创新点

DFI 设计与实现

预处理：修改了两个操作

程序内（运行过程内）分析：

DEF-USE的非树边

采用反转图：可以有效避免多参数情况下的函数产生的非树边问题。

增广DFT区间图的可达性：在遇到非树边时复制区间，以此可以使用两个区间之间相似的包含关系确定它们的可达性

交集运算符<span style="background-color: #ff666680">（成立前提？）</span>

程序间过程分析

价值流摘要值的传播：将被调者函数的价值流摘要传播到调用者，以便将上下文敏感的价值流信息添加到调用者函数

可达功能的摘要：将传播过程扩展到一个可达函数的摘要。

评估

TRUSTFLOW：降低DFI内存开销的硬件DFI机制

一句话概述

主要功能

主要贡献

TRUSTFLOW

编译器支持

基于TRUSTFLOW的安全策略

影子堆栈

指针完整性

循环监测和通用数据

评估

VSPM实验结果

不足

Linux通用配置相关问题（持续更新）

apt/dnf/apt自动安装路径

踩坑案例

TOOLS

bpf_tracing.h

BPF_PROG

PERF & RING BUFFER

总述

RING BUFFER优势

PERF和RF主要结构对比

例程

eBPF概述

起源

伪机器码、BPF指令集、JIT