On 9/9/21 11:16 AM, Mauro Matteo Cascella wrote: > 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.)?
I just posted a suggestion as RFC but forgot to Cc you: "security: Introduce qemu_security_policy_taint() API" https://lore.kernel.org/qemu-devel/[email protected]/ In particular for the ati-vga device: https://lore.kernel.org/qemu-devel/[email protected]/
