虚拟化硬件仿真【免费下载链接】qemuOfficial QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.项目地址https://gitcode.com/gh_mirrors/qe/qemu点击查看免费下载导读QEMU 作为大型开源虚拟化项目对 AI 生成内容的贡献有着明确而严格的政策。仓库根目录下的 AGENTS.md 是面向 AI 编码 Agent 的官方行为准则文件它界定了 Agent 可以协助用户的四种场景、禁止参与上游贡献的边界并指引 Agent 遵循 docs/devel/code-provenance.rst 中关于 AI 生成内容的使用政策以及 docs/system/security.rst 中关于安全漏洞分类与报告的规定。读完本文你将掌握QEMU 对 AI 辅助开发的容忍边界与例外情形、DCO 认证与各类贡献标签的规范用法以及什么漏洞才算安全漏洞的权威判定标准与机密报告流程。一、AGENTS.mdQEMU 为 AI Agent 划定的行为边界AGENTS.md 是 QEMU 项目专门为 AI Agent 编写的协作准则全文围绕两条主线展开代码来源认证code provenance与安全漏洞处理security policy。它的存在表明QEMU 并不排斥 AI 工具参与开发流程但对AI 输出能否进入上游代码持有极其审慎的态度。1.1 允许协助的场景AGENTS.md 明确规定Agent 仅在以下四类场景中可协助用户研究 API 或算法researching APIs or algorithms静态分析static analysis调试debugging本地实验local experiments不以上游合入为目的微不足道的非版权性变更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 要求贡献者依据 Developers Certificate of OriginDCO认证其提交内容。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-byQEMU 社区强制要求所有贡献者为补丁提交做来源认证方式是在每个 git commit 末尾追加一行Signed-off-by: YOUR NAME YOUREMAIL这一行声明提交者依照 Developers 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环境用法git新建/修改提交git commit -s自动追加与配置的 git 作者信息匹配的行git format-patchgit format-patch -s在生成的邮件中追加不修改本地提交git批量修正分支git rebase master -x git commit --amend --no-edit -semacs在$HOME/.emacs.d/abbrev_defs中定义缩写如(8sob Signed-off-by: YOUR NAME youremail.addr nil 1)输入8sob后跟空格或回车即可展开vim在$HOME/.vimrc中定义iabbrev如iabbrev 8sob Signed-off-by: YOUR NAME youremail.addr四、其他贡献标签协作链条中的信用标记除强制性的Signed-off-by外QEMU 开发流程中常用以下标签详见 docs/devel/code-provenance.rst 的 Other commit tags 一节Reviewed-by社区成员在邮件列表评审补丁并认为可接受时回复该标签子系统维护者即使同时添加Signed-off-by也应保留Reviewed-byAcked-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.contributorexample.com [Comment rephrased for clarity] Signed-off-by: Mary Maintainer mary.maintainermycorp.test类似的注释机制也用于重启他人放弃的工作——新贡献者应保留原作者Signed-off-by并追加自己的同时注明补丁来源与各自负责的部分。五、安全政策什么才算安全漏洞5.1 AI 分类的关键警告AGENTS.md 特别强调对 AI 进行漏洞分诊triage至关重要的一条是并非每次崩溃crash、断言失败assertion failure或缓冲区溢出都是安全漏洞。只有在虚拟化用例中可被利用来破坏客户机隔离guest isolation的缺陷才被视为安全漏洞。据此涉及以下配置的缺陷通常值得安全评估硬件加速器如 KVM 与 XenTCGTiny 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并使用下表列出的机器类型目标架构受支持的机器类型aarch64virti386、x86_64microvm、xenfv、xenpv、xenpvh、pc、q35s390xs390-ccw-virtioloongarch64virtppc64pseriesriscv32、riscv64virt非虚拟化用例基于 TCG 的纯模拟目前不被视为安全支持范围即使理论上 TCG 与设备模拟代码应达到同等安全要求但历史原因导致许多代码并未按此要求编写。使用非虚拟化用例的用户不得依赖 QEMU 提供客户机隔离或任何安全保证。5.3 安全边界范围哪些场景不算安全缺陷即使缺陷影响虚拟化用例以下情形通常不按完整安全流程处理而作为普通 bughardening bug修复assert/abort若触发路径需要客户机内核权限或 root 账户属于自我造成的拒绝服务只有无特权客户机账户可触发时才可能按安全 bug 处理vhost-user/vfio-user 后端QEMU 与后端进程之间共享内存协同映射进程分离的目的是运维弹性与独立软件供应商支持二者之间不存在安全边界内存分配界限QEMU 的最坏内存用量实际无界主机应通过 OOM killer 等机制防护此类缺陷通常不算安全缺陷客户机行为降级如虚拟 IOMMU 操作有缺陷导致设备隔离减弱若需内核/root 权限触发且仅导致服务降级不算安全缺陷嵌套虚拟化L2 客户机内核可能触发影响 L0 QEMU 进程的缺陷但当前不做安全分类迁移/快照失败只要源虚拟机与 savevm 文件仍可用目标端中止进程不算安全问题迁移流本身在设计原则成立时被假定安全未初始化栈变量构建系统通过-ftrivial-auto-var-initzero为所有栈变量提供隐式零初始化GCC 与 Clang 均支持消除了相关未定义行为此类场景通常不算安全缺陷低严重性影响作为兜底规则影响为低严重性的问题通常不分配 CVE。5.4 安全状态标注.secure 字段与 insecure-typesQEMU 通过在类型上显式标注是否提供安全边界来报告安全状态。只有标注了secure标志的机器类型、加速器与设备类型才有资格获得 CVE 分配。在对象模型中这一标志对应 include/qom/object.h 中TypeInfo结构体的bool secure;字段参见该文件 L494 附近将某个 Object 类的TypeInfo.secure设为true即声明该类型旨在提供安全边界。运行时可通过-compat insecure-types参数控制未声明安全边界的类型的使用它接受三个值值行为accept允许使用任何类型当前及历史默认行为warn使用未显式声明安全的类型时输出警告但仍允许reject使用未显式声明安全的类型时报错并禁止该兼容策略在 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 ConsoleQMP 与 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 流程涉及漏洞则先对照安全边界文档完成分类再按机密流程上报。赞分享虚拟化硬件仿真【免费下载链接】qemuOfficial QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.项目地址https://gitcode.com/gh_mirrors/qe/qemu点击查看免费下载相关推荐Gradle 构建工具的 AI 辅助贡献政策人机协作边界、披露规则与审查实践Gradle 构建工具的 AI 辅助贡献政策人机协作边界、披露规则与审查实践 本篇指南围绕 Gradle 仓库根目录的 AI_POLICY.md https:构建工具开发工具VideoSrt3分钟掌握Windows免费字幕生成神器VideoSrt3分钟掌握Windows免费字幕生成神器 还在为视频字幕制作而烦恼吗手动打字耗时耗力专业软件价格昂贵在线工具又担心隐私泄露今天我要为你后端内容协同存储企业应用Hermes WebUI AGENTS.md 详解AI Agent 协作守则、本地验证流程与安全边界Hermes WebUI AGENTS.md 详解AI Agent 协作守则、本地验证流程与安全边界 本文基于仓库根目录的 AGENTS.md https:/人工智能AI 应用AI Agent交互助手MCP 服务前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考