On Mon, Nov 02, 2026 at 08:01:41AM +0100, Markus Armbruster wrote: > Daniel P. Berrangé <[email protected]> writes: > > > The description of virtualization vs non-virtualization use > > cases is a crude approximation of the security characteristics > > of QEMU devices. > > > > Document how QEMU can be probed to obtain information on the > > security status of type classes, and how policies can be set > > to inform or control their usage. > > > > Reviewed-by: Marc-André Lureau <[email protected]> > > Signed-off-by: Daniel P. Berrangé <[email protected]> > > --- > > docs/system/security.rst | 36 ++++++++++++++++++++++++++++++++++++ > > 1 file changed, 36 insertions(+) > > > > diff --git a/docs/system/security.rst b/docs/system/security.rst > > index 8c42d1a6d8..75e39caede 100644 > > --- a/docs/system/security.rst > > +++ b/docs/system/security.rst > > @@ -158,6 +158,42 @@ an issue as a normal bug. > > usually not justify handling as security bugs, nor assignment > > of CVEs. They will be fixed as routine bugs when time allows. > > > > +Security status reporting > > +''''''''''''''''''''''''' > > + > > +The QEMU project annotates types to explicitly state whether they are > > +considered to provide a security boundary or not. For machine, accelerator > > +and device types, only those annotated with the "secure" flag will be > > +eligible for CVE assignment. Annotations will be extended to other backend > > +and object types over time, to make their security status explicit. > > + > > +It is possible to control or identify the usage of types that do not offer > > +an explicit security boundary using the ``insecure-types`` parameter to the > > +``-compat`` argument, which accepts three values: > > + > > + * accept: usage of any type will be permitted. This is the current > > + and historical default behaviour > > + * warn: usage of types not explicitly declared secure will result > > + in a warning message, but still be permitted. > > + * reject: usage of types not explicitly declared secure will result > > + in an error message, and will not be permitted. > > + > > +The compatibility policy will be honoured both at initial startup of > > +QEMU and during any runtime alterations made with monitor commands. > > + > > +The status of any type class can be queried at runtime using the > > +``qom-list-types`` command, whose returned information will flag any > > +types declared as secure. The ``query-machines`` command will also > > +reflect this same information for machine types. > > Yes, member @secure of qom-list-type's return type ObjectTypeInfo and > query-machine's return type MachineInfo. However, nothing appears to be > marked secure: > > --> {"execute": "qom-list-types", "arguments": {"secure": true}} > <-- {"return": []} > > I did not expect this after reading the documentation. Am I confused? > > If not, what's the plan for the release?
I'm sending a PULL for this today: https://lists.gnu.org/archive/html/qemu-devel/2026-10/msg07775.html and if a few more acks arrive for this: https://lists.gnu.org/archive/html/qemu-devel/2026-10/threads.html i'll send a PULL for that too. Since it is only marking an annotation I think we can do this even if past soft-freeze, as the patches are not a functional behaviour change, just metadata. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
