importriri/arch-hypervisor-lab

# Arch Linux Hypervisor 实验室 一台笔记本电脑，四个相互隔离的虚拟机，以及在它们之间传递的一块 GPU。 本仓库记录了整个构建过程：配置、启动配置文件，以及我在此过程中遇到的每一个 bug。 ## 你将构建什么 ``` ┌──────────────────────────────────────────────────────────────────┐ │ HOST — Arch Linux (hypervisor-01) │ │ TTY only · systemd-boot · Btrfs+LUKS2 · nftables │ │ iGPU → TTY display · Sway (minimal, for Looking Glass) │ ├──────────────┬──────────────┬──────────────┬─────────────────────┤ │ 🟢 CLEAN │ 🟠 DIRTY │ 🔴 DEV/3D │ 🟡 MALWARE LAB │ │ Gaming │ Gaming │ Work │ Static & dynamic │ │ verified │ mods │ software │ malware analysis │ │ 10.10.1.0 │ 10.10.2.0 │ 10.10.3.0 │ 10.10.4.0 ISOLATED │ ├──────────────┴──────────────┴──────────────┴─────────────────────┤ │ dGPU — one VM at a time via VFIO · Looking Glass │ │ GPU handoff protocol between domains │ └──────────────────────────────────────────────────────────────────┘ ``` 宿主机没有桌面环境。 Sway 仅作为最小化的 Wayland compositor 安装，用于运行 Looking Glass 客户端。 ## 我是如何构建它的 三个阶段。每个阶段都可以独立复现。 **1. 基础安装 → [arch-bootstrap](https://github.com/importriri/arch-bootstrap)** — 🚧 *进行中* 一个从头编写并测试的 bash 安装程序：LUKS2、Btrfs subvolumes、 systemd-boot、带有自定义密钥的 Secure Boot、`linux-hardened`、zram。 从分区到 Secure Boot 签名的每个阶段——外加一个专用于 VM 存储的可选第二块加密磁盘——都已经编写完成，并正按里程碑逐步发布。三个测试层为其提供保障：单元测试（真实的函数、模拟的工具）、真实的 LUKS2 header 检查，以及在 loop 设备上进行的完整分区→挂载 pipeline。剩下的是真机硬件验证。 实时的路线图位于该仓库的 README 中。 **2. 配置 → Ansible roles** — 🚧 *进行中* 基础安装之后的所有内容：网络 domains（nftables）、libvirt VM、 VFIO/GPU passthrough、GPU 交接 hooks、宿主机加固、恶意软件实验室。 编写为可复用的 roles，因此整台机器可以通过一条命令重建。 位于其独立的仓库中： [privatestack-ansible](https://github.com/importriri/privatestack-ansible) — 其 README 中的 brick catalog 记录了已落地的内容。 **3. 实验室 → 本仓库** 随着每个组件上线并在真实硬件上得到验证，配置和文档将发布于此。 目前的工作正集中在**阶段 1 和 2**。 ## 前置条件 - 一台带有专用 NVIDIA GPU 的笔记本电脑（Optimus/hybrid 模式） - 在 BIOS 中启用了 VT-d (IOMMU) 的 Intel CPU - 愿意从零开始安装 Arch Linux ## 特定于笔记本电脑的 bug —— 大多数指南未涵盖 **症状：** 在带有 GPU passthrough 的 VM 启动时，系统立即完全卡死。 **原因：** 笔记本电脑固件强制执行的激进 PCIe 端口电源管理。 **修复：** 在 systemd-boot VFIO kernel 参数中设置 `pcie_port_pm=off`（以及可选的 `pcie_aspm=off`）。 **寻找该问题花费的时间：** 约 2 个月。当时没有可用的 AI 工具。 在台式机上，相同的电源管理系列通常会在失败前在 `dmesg` 中自行报告（`Unable to change power state from D3cold to D0`）； 而在这台笔记本电脑上，系统会在写入任何日志之前就卡死。针对笔记本电脑/Optimus 的情况在指南中仍然缺失。 → 完整文档：[`problems/gpu-freeze-power-management.md`](problems/gpu-freeze-power-management.md) ## 仓库结构 ``` arch-hypervisor-lab/ ├── README.md ├── SETUP.md # how to reproduce the lab, stage by stage ├── problems/ # bugs encountered and solved — written as they happen ├── configs/ │ ├── network-domains.md # the four network segments, nftables design │ ├── boot/ # systemd-boot profiles (VFIO entry included) │ ├── libvirt/ # VM XML definitions │ ├── hooks/ # GPU switch scripts │ └── malware-lab/ # REMnux/INetSim configuration └── screenshots/ # proof it works ``` ## 关键词 `KVM laptop` `VFIO laptop` `GPU passthrough laptop` `NVIDIA Optimus passthrough` `pcie_port_pm laptop fix` `KVM freeze laptop` `four domains hypervisor` `Windows VM KVM` `gaming VM Linux` `systemd-boot VFIO` `Arch Linux hypervisor` `Looking Glass KVM` `malware lab KVM` `TTY hypervisor`

标签：Arch Linux, DAST, GPU直通, Linux运维, 应用安全, 恶意软件分析, 系统提示词, 系统配置, 虚拟化, 身份验证强制