Re: [RFC PATCH v3 01/11] AGENTS.md: introduce a very basic guide for AI agents

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 4187 bytes --]

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é <philmd@linaro.org> 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 <alex.bennee@linaro.org>
>>>> ---
>>>> 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
>>>> +`qemu-security@nongnu.org`.
>>>> +
>>>> +**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/abAcaahy_FsBonZ7@redhat.com/
>>>
>>
>> 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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]