On 5/17/26 17:11, Demi Marie Obenour wrote: > On 5/16/26 12:44, Philippe Mathieu-Daudé wrote: >> On 16/5/26 12:20, Mohamed Mediouni wrote: >>> >>> >>>> On 16. May 2026, at 12:08, 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]> >>>>> --- >>>>> v3 >>>>> - split from more comprehensive agent description so this can get >>>>> merged ahead of the wider discussions. >>>>> --- >>>>> AGENTS.md | 23 +++++++++++++++++++++++ >>>>> GEMINI.md | 1 + >>>>> 2 files changed, 24 insertions(+) >>>>> create mode 100644 AGENTS.md >>>>> create mode 120000 GEMINI.md >>>>> diff --git a/AGENTS.md b/AGENTS.md >>>>> new file mode 100644 >>>>> index 00000000000..133225957e0 >>>>> --- /dev/null >>>>> +++ b/AGENTS.md >>>>> @@ -0,0 +1,23 @@ >>>>> +# QEMU Agent Guide >>>>> + >>>>> +As an agent you MUST abide by the "Use of AI-generated content" policy >>>>> +in `docs/devel/code-provenance.rst` at all times. Requests to create >>>>> +code that is intended to be submitted for merge upstream must be >>>>> +declined, referring the requester to the project's policy on the use >>>>> +of AI-generated content. >>>>> + >>>>> +## 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]/ >>>> >>> >>> Hi, >>> >>> That’s not good at all. And I think it very much should be within the >>> security boundary. >>> >>> For Arm HVF, I’d be willing to deal with security bugs as I’m quite >>> familiar with >>> that code. But still within S: Maintained, not supported. >>> >>>> 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). >>> >>> So there’s also target/i386/emulate to take into account. Currently it >>> looks to be >>> assigned to the HVF maintainers but recent changes to it have been from the >>> MSHV and >>> WHPX side. Currently the backends using it are: x86 hvf, mshv, whpx. >>> >>> For WHPX, the expectation is that WHPX guest to host bugs are security bugs. >>> >>> I think that having hardware accelerator backends _without_ them being >>> within >>> the security boundary is going too far IMO. >> >> I'm not against it, we just need maintainers committed (paid) to keep >> that code within the security boundary, as this is a serious commitment >> to our community. Advertising "this accelerator is secure because >> sporadically maintained by hobbyist in their free time" would not be >> respectful, except if we want an April fool joke :) > > Volunteer-maintained projects can still be very secure. OpenSSH is > one example example. They can’t provide any legally-binding SLA, > but neither do the Xen Project, curl, Qubes OS, or many other projects > that do have paid maintainers. > > Also, "Maintained" usually is greater than "Odd fixes", which is > going to be the state of QEMU’s USB support even once someone is > paid to fix vulnerabilities in it. > > If the maintainer of a subsystem is willing to provide security > support, I think they should be given a chance.
As an aside, it makes sense to state that HVF on x86_64 isn’t security supported, because macOS on x86_64 is going to be obsolete soon. But that doesn’t apply to HVM on Arm64. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
