On Tue, Sep 7, 2021 at 8:22 AM Philippe Mathieu-Daudé <[email protected]> wrote: > > On 9/7/21 7:38 AM, Philippe Mathieu-Daudé wrote: > > On 9/6/21 9:52 PM, BALATON Zoltan wrote: > >> I don't think assigning a CVE to a bug that is in an experimental and > >> largely unused part and happens when one enables debug code really worth > >> the hassle, this could be handled as a normal bug. As long as the > > > > CVE assignment can happens outside of QEMU community, we try to make it > > clear what is the "security boundary" but researchers filling CVEs > > might not understand it well. > > BTW see commit b317006a3f1 ("docs/secure-coding-practices: Describe how > to use 'null-co' block driver") which is related to your suggestion.
I agree we can avoid assigning CVEs to ati-vga and similar experimental devices that are not intended to be used in production, even if they fall under the virtualization use case. Maybe we can improve the documentation (https://qemu-project.gitlab.io/qemu/system/security.html) to clearly state that some devices are not security supported? Would it be possible/feasible to get a list of such devices? Or maybe the other way around, document the list of devices that are undeniably security supported (e.g., virtio*, *hci, e1000, etc.)? -- Mauro Matteo Cascella Red Hat Product Security PGP-Key ID: BB3410B0
