On Sat, 16 May 2026 at 11:09, Philippe Mathieu-Daudé <[email protected]> wrote: > > On 15/5/26 18:30, Alex Bennée wrote: > > AGENTS.md is the agent agnostic place for placing instructions for > > agents. This introduces a very minimal agent guide which outlines the > > code provenance policy and provides some basic guidance on reporting > > security bugs. > > > > As Gemini doesn't look at AGENTS.md even as a fallback option I've > > included a symlink. > > > > Signed-off-by: Alex Bennée <[email protected]>
> > +## Security Policy (see `docs/system/security.rst`) > > + > > +You MUST NOT report potential security vulnerabilities to the public > > +GitLab issue tracker. They should be reported privately to > > +`[email protected]`. > > + > > +**Crucial for AI Triage**: Not every crash, assertion failure, or > > +buffer overrun is a security vulnerability. Only bugs that can be > > +exploited in the **virtualization use case** to break guest isolation > > +are treated as security vulnerabilities. In brief these are: > > +- **Hardware Accelerators**: e.g. KVM, HVF and others, TCG is explicitly > > excluded. > > HVF isn't withing security boundary: > https://lore.kernel.org/qemu-devel/[email protected]/ > > For the "other accelerators" we should ask confirmation for respective > maintainers. AFAICT only KVM and Xen are expected to be secure; > MSHV, WHPX, nvmm and nitro didn't opted in yet (Cc'ing respective > maintainers). > > Wouldn't it be better to have a document describing the security code > boundary and have the AGENT.md refer to it? We do have such a document: https://qemu-project.gitlab.io/qemu/system/security.html and the AGENTS.md does tell the LLM about it. It puts all the virtualization accelerators within the security use case boundary. Personally I think this is reasonable -- the main reasons for having TCG outside it are (1) the TCG emulation itself is a lot of code and (2) it is a convenient way to rule out an enormous amount of old board and device model code in one go. This applies much less to the hvf, whpx, etc cases as they are using almost exactly the same board/device/core code as KVM. The idea as I understand it here is that by giving a very brief summary of the other document you make sure that the important parts we want to emphasize are in the agent's context and clearly stated. But I'm no expert on how to craft these files... thanks -- PMM
