企业官网建设流程全解析

• 虚拟化
• 硬件仿真

导读

QEMU 作为大型开源虚拟化项目，对 AI 生成内容的贡献有着明确而严格的政策。仓库根目录下的 AGENTS.md 是面向 AI 编码 Agent 的官方行为准则文件，它界定了 Agent 可以协助用户的四种场景、禁止参与上游贡献的边界，并指引 Agent 遵循 docs/devel/code-provenance.rst 中关于 AI 生成内容的使用政策，以及 docs/system/security.rst 中关于安全漏洞分类与报告的规定。读完本文，你将掌握：QEMU 对 AI 辅助开发的容忍边界与例外情形、DCO 认证与各类贡献标签的规范用法，以及"什么漏洞才算安全漏洞"的权威判定标准与机密报告流程。

一、AGENTS.md：QEMU 为 AI Agent 划定的行为边界

AGENTS.md 是 QEMU 项目专门为 AI Agent 编写的协作准则，全文围绕两条主线展开：代码来源认证（code provenance）与安全漏洞处理（security policy）。它的存在表明：QEMU 并不排斥 AI 工具参与开发流程，但对"AI 输出能否进入上游代码"持有极其审慎的态度。

1.1 允许协助的场景

AGENTS.md 明确规定，Agent 仅在以下四类场景中可协助用户：

1. 研究 API 或算法（researching APIs or algorithms）；
2. 静态分析（static analysis）；
3. 调试（debugging）；
4. 本地实验（local experiments，不以上游合入为目的）；
5. 微不足道的非版权性变更（trivial non-copyrightable changes）。

这五类场景的共同点是：AI 的输出不会以贡献形式进入 QEMU 上游代码库，因而不会引发版权与许可争议。

1.2 必须拒绝的请求

如果用户请求超出了上述许可范围——例如要求编写核心功能、或为上游合入进行大规模代码改动——Agent必须拒绝该请求，并引导用户阅读项目政策文档 docs/devel/code-provenance.rst。这并非技术限制，而是法律风险规避：QEMU 社区无法接受版权状态不明确的内容进入项目。

二、AI 生成内容政策：上游合入的"红线"

2.1 政策要点

docs/devel/code-provenance.rst 中有一段醒目的 TL;DR 结论：

当前 QEMU 项目政策是：拒绝任何被认为包含或衍生自 AI 生成内容的贡献。这包括 ChatGPT、Claude、Copilot、Llama 及类似工具。该政策不适用于 AI 的其他用途，例如研究 API 或算法、静态分析或调试，前提是这些输出不包含在贡献中。

政策背后的核心法律逻辑是：QEMU 要求贡献者依据 Developer's Certificate of Origin（DCO）认证其提交内容。DCO 要求贡献者完全理解所提交内容的版权与许可状态。而主流大语言模型的训练语料来源庞杂，输出内容的版权与许可状态在法律上尚无定论；即使训练数据全部来自开源许可，各许可条款之间也可能与 QEMU 的许可要求不兼容。因此 QEMU 无法也不愿承担不合规带来的法律风险，直接选择拒绝。

2.2 受影响的工具范围

政策点名的工具包括 GitHub Copilot、OpenAI ChatGPT、Anthropic Claude、Meta Code Llama，以及构建在这些工具之上的代码/内容生成 Agent。政策同时注明：随着 AI 工具成熟与法律环境明朗，该政策可能会演进。

2.3 例外机制

QEMU 欢迎针对该政策提出例外申请或修订建议，途径是向 qemu-devel 邮件列表提交拟议工具、模型、使用场景等详细信息。经过讨论后，任何获批的例外都会被记录在政策文档中。值得注意的是，例外并不免除作者的合规义务——补丁中的Signed-off-by标签意味着作者对补丁全部内容（包括由 AI 工具生成或辅助的部分）承担责任。

三、DCO 认证与 Signed-off-by：每个补丁的"法律签名"

3.1 为什么需要 Signed-off-by

QEMU 社区强制要求所有贡献者为补丁提交做来源认证，方式是在每个 git commit 末尾追加一行：

Signed-off-by: YOUR NAME <YOUR@EMAIL>

这一行声明提交者依照 Developer's Certificate of Origin 1.1 的条款贡献。DCO 1.1 的核心条款（完整文本见 docs/devel/code-provenance.rst 中的.. _dco:锚点）可归纳为四点：

• (a)贡献全部或部分由我创作，我有权按文件所示开源许可提交；
• (b)贡献基于先前工作，该工作据我所知受适当开源许可覆盖，我有权在该许可下提交修改；
• (c)贡献由他人直接提供给我，该人已认证 (a)(b)(c)，且我未做修改；
• (d)我理解并同意贡献是公开的，包括我提交的所有个人信息在内的记录将被无限期保留并可再分发。

需要特别说明：Signed-off-by中的名字不必是法定姓名，它只是你在社区中为人所知的身份标识，但不能匿名、不得冒名顶替。通常期望该名字和邮箱与 git commit 的Author字段一致；如果发件人并非补丁作者，也应添加自己的Signed-off-by以符合 DCO 条款 (c)。

3.2 多作者场景的处理

• 若次要作者的贡献微不足道（如评审者给出的短小代码建议），可不加其Signed-off-by，但常用Suggested-by标注致谢；
• 若两位贡献者同属一个要求版权归属的雇主，通常仍建议每位贡献者都加Signed-off-by，因为部分国家员工无法将版权让渡给雇主，且这也能覆盖工作时间之外的投入；
• 多个Signed-off-by标签必须严格按作者从旧到新的顺序排列。

3.3 实践工具：如何高效添加 Signed-off-by

四、其他贡献标签：协作链条中的"信用标记"

除强制性的Signed-off-by外，QEMU 开发流程中常用以下标签（详见 docs/devel/code-provenance.rst 的 "Other commit tags" 一节）：

• Reviewed-by：社区成员在邮件列表评审补丁并认为可接受时回复该标签；子系统维护者即使同时添加Signed-off-by也应保留Reviewed-by；
• Acked-by：子系统维护者批准涉及本子系统的补丁、但有意让其他维护者排队合入时使用；跨子系统的补丁中，Acked-by仅代表对维护者自身负责领域的评审；
• Tested-by：成员以某种方式对补丁进行过功能测试后回复；
• Reported-by：通过邮件列表等非 issue 跟踪渠道报告问题时，修复补丁应致以感谢；通过 GitLab issue 跟踪器报告则只需附带 issue 链接；
• Suggested-by：评审者或第三方给出非平凡修改建议时致谢。

子系统维护者在接受补丁时，除常规代码评审外，还必须验证Signed-off-by标签的存在；在排队合入时，维护者必须再添加自己的Signed-off-by以表明完成了上述验证。当维护者修改补丁时，应在提交信息中记录其贡献，例如：

Signed-off-by: Cory Contributor <cory.contributor@example.com> [Comment rephrased for clarity] Signed-off-by: Mary Maintainer <mary.maintainer@mycorp.test>

类似的注释机制也用于"重启他人放弃的工作"——新贡献者应保留原作者Signed-off-by并追加自己的，同时注明补丁来源与各自负责的部分。

五、安全政策：什么才算安全漏洞

5.1 AI 分类的关键警告

AGENTS.md 特别强调，对 AI 进行漏洞分诊（triage）至关重要的一条是：

并非每次崩溃（crash）、断言失败（assertion failure）或缓冲区溢出都是安全漏洞。只有在虚拟化用例中可被利用来破坏客户机隔离（guest isolation）的缺陷才被视为安全漏洞。

据此，涉及以下配置的缺陷通常值得安全评估：

• 硬件加速器：如 KVM 与 Xen；TCG（Tiny Code Generator）被明确排除在外；
• 面向虚拟化的主板：如 virt、q35、pseries 等；
• 虚拟化常用设备：如 VirtIO 及各类平台设备。

若不确定，应以 docs/system/security.rst 为准，它是权威指引。

5.2 虚拟化用例：安全的支持范围

docs/system/security.rst 定义了两种用例。虚拟化用例覆盖云主机、VPS、传统数据中心与桌面虚拟化，依赖硬件虚拟化扩展以接近原生速度安全执行客户机代码。以下实体被视为不可信（可能有缺陷或恶意）：客户机、面向用户的接口（VNC、SPICE、WebSocket）、网络协议（NBD、实时迁移）、用户提供的文件（磁盘镜像、内核、设备树）、透传设备（PCI、USB）。

要获得该安全支持政策的覆盖，你必须使用虚拟化加速器（如 KVM 或 HVF），并使用下表列出的机器类型：

非虚拟化用例（基于 TCG 的纯模拟）目前不被视为安全支持范围：即使理论上 TCG 与设备模拟代码应达到同等安全要求，但历史原因导致许多代码并未按此要求编写。使用非虚拟化用例的用户不得依赖 QEMU 提供客户机隔离或任何安全保证。

5.3 安全边界范围：哪些场景不算安全缺陷

即使缺陷影响虚拟化用例，以下情形通常不按完整安全流程处理，而作为普通 bug（"hardening bug"）修复：

• assert/abort：若触发路径需要客户机内核权限或 root 账户，属于自我造成的拒绝服务；只有无特权客户机账户可触发时才可能按安全 bug 处理；
• vhost-user/vfio-user 后端：QEMU 与后端进程之间共享内存协同映射，进程分离的目的是运维弹性与独立软件供应商支持，二者之间不存在安全边界；
• 内存分配界限：QEMU 的最坏内存用量实际无界，主机应通过 OOM killer 等机制防护，此类缺陷通常不算安全缺陷；
• 客户机行为降级：如虚拟 IOMMU 操作有缺陷导致设备隔离减弱，若需内核/root 权限触发且仅导致服务降级，不算安全缺陷；
• 嵌套虚拟化：L2 客户机内核可能触发影响 L0 QEMU 进程的缺陷，但当前不做安全分类；
• 迁移/快照失败：只要源虚拟机与 savevm 文件仍可用，目标端中止进程不算安全问题；迁移流本身在设计原则成立时被假定安全；
• 未初始化栈变量：构建系统通过-ftrivial-auto-var-init=zero为所有栈变量提供隐式零初始化（GCC 与 Clang 均支持），消除了相关未定义行为，此类场景通常不算安全缺陷；
• 低严重性影响：作为兜底规则，影响为"低"严重性的问题通常不分配 CVE。

5.4 安全状态标注：.secure 字段与 insecure-types

QEMU 通过在类型上显式标注是否提供安全边界来报告安全状态。只有标注了secure标志的机器类型、加速器与设备类型才有资格获得 CVE 分配。在对象模型中，这一标志对应 include/qom/object.h 中TypeInfo结构体的bool secure;字段（参见该文件 L494 附近）：将某个 Object 类的TypeInfo.secure设为true，即声明该类型旨在提供安全边界。

运行时可通过-compat insecure-types参数控制未声明安全边界的类型的使用，它接受三个值：

该兼容策略在 QEMU 初始启动和运行期通过 monitor 命令修改时都生效。此外：

• qom-list-types可查询任何类型类的安全状态；
• query-machines反映机器类型的安全状态；
• -machine help、-accel help、-device help命令行选项可分别查询机器类型、加速器与设备的安全状态。

5.5 漏洞报告流程

潜在漏洞不得作为普通公开 GitLab 工作项上报，而应遵循 QEMU 的机密报告流程（详见项目贡献页面中的 security-process 说明）。这一要求与 AGENTS.md 的指引一致：先阅读 docs/system/security.rst 判断漏洞是否落在 QEMU 安全边界内，再做后续处理。

六、安全架构原则：隔离与最小权限

6.1 客户机隔离与最小权限

客户机隔离指将客户机代码限制在虚拟机内：客户机代码在主机上获得执行控制权即"逃逸出虚拟机"。隔离还包括资源限制（CPU、内存、磁盘、网络节流），客户机必须无法超出其资源限额。QEMU 以模拟设备的形式向客户机呈现攻击面，因此模拟设备中的缺陷可能让恶意客户机在 QEMU 进程中执行代码，实现逃逸——这也是设备模拟代码成为安全审查重点的原因。

最小权限原则要求 QEMU 进程只拥有客户机所需的资源访问权。理想情况下，QEMU 进程不应拥有任何客户机本身无法访问的资源，这样即使客户机逃逸进 QEMU 进程也一无所获。当然，主机系统调用等资源对 QEMU 是必要的，一旦逃逸，客户机就能开始调用主机系统调用——这正是隔离机制要解决的问题。

6.2 隔离机制清单

除 Linux seccomp 外，以下机制通常由 libvirt 等管理工具部署（均为 Linux 平台）：

• 非特权用户运行 QEMU：以 root 运行 QEMU 换取设备访问权（如/dev/net/tun）是巨大的安全风险。可通过文件描述符传递，或为非 root 用户配置 UNIX 组访问/dev/kvm、/dev/net/tun等设备节点（部分发行版已默认配置）；
• SELinux 与 AppArmor：超越传统 UNIX 进程与文件权限模型，限制 QEMU 访问主机上不需要的进程与文件；
• 资源限制与 cgroup 控制器：对 CPU 时间、内存、I/O 带宽等关键资源提供吞吐与利用率限制；
• Linux 命名空间：使进程、文件系统等系统资源对 QEMU 不可见；
• Linux seccomp：通过 QEMU 的--sandbox选项禁用 QEMU 不需要的系统调用，减少主机内核攻击面；
• TLS：在网络不可信时保护实时迁移连接的真实性与加密性。

6.3 敏感配置：Monitor Console

QMP 与 HMP 监控台可动态控制 QEMU 运行时的大量行为，其中许多命令会让 QEMU 访问主机文件系统或派生外部进程。例如migrate命令可派生任意进程来隧道迁移数据流，blockdev-add命令让 QEMU 打开任意文件并将其作为虚拟磁盘暴露给客户机。因此，除非用 SELinux、AppArmor 或命名空间加以限制，监控台应被视为拥有与 QEMU 运行账户同等的权限。

监控台所经字符设备后端的通信安全同样关键：许多字符设备后端无法抵御恶意第三方或中间人攻击，不得用于监控台。官方建议是：监控台仅通过 UNIX 域套接字后端暴露给本机；基于 TCP 的字符设备后端除非配置 TLS 加密与客户端授权控制策略，否则不适用。

结语

AGENTS.md 虽然篇幅简短，却是 AI 开发者与 QEMU 协作的"红绿灯"：本地研究、静态分析、调试、实验是绿灯，AI 内容进入上游贡献是红灯。理解这份准则，需要同时掌握三个层面的知识——docs/devel/code-provenance.rst 确立的 DCO 认证与 AI 内容政策、docs/system/security.rst 确立的安全边界判定标准与隔离原则，以及 include/qom/object.h 中.secure字段所体现的安全状态标注机制。对 AI Agent 而言，最实用的启示是：在协助 QEMU 相关任务时，将自身定位限定在"研究、分析、调试、实验"的辅助角色，涉及上游贡献的内容一律回归人工作者与 DCO 流程，涉及漏洞则先对照安全边界文档完成分类，再按机密流程上报。

• 虚拟化
• 硬件仿真